Z88dk: Spectrum Next - naming consistency

[feilipu]

The Spectrum Next naming is all over the shop. When new Spectrum Next users arrive, it will confuse them, like it confuses me.

An example command

zcc +test -v -clib=zxn -lmath32_zxn -Cc-mz80-zxn -Cc-fp-mode=ieee -custom-copt-rules=~/Z80/z88dk/lib/zxn_rules.1 -pragma-define:CLIB_32BIT_FLOATS=1 -DPRINTF n-body.c
z88dk-ticks -w 60 -mz80-zxn a.bin

has three pronunciations, seemingly randomly chosen. The hyphen z80-zxn, the underscore z80_zxn, and the blank zxn.

Perhaps it is my fault for using an underscore in math32, (and I can fix that) but I think this hyphen/underscore thing is a bit of an issue. The math32 linkage should by rights be -lmath32-z80-zxn, but of course that's too long.

The Spectrum Next CPU has grown far beyond the Z80 ISA (and also beyond the Z180), to the extent that I'd moot it is no longer just a variant of Z80 (any more or less than the Z180 is a variant).

• Q1. Wouldn't it be good to drop the annoying underscore/hyphen and just call the processor _zxn_ or _z80next_ or _z80n_ or similar?

Over the next years, because of the probable success of the Spectrum Next, there may be additional platforms using the z80-zxn processor ISA, so the processor and platform should become distinct things.

• Q2. Wouldn't it be better to have the Spectrum Next use a non-cyptic platform specific name? Like _zxnext_ or _specnext_ or similar?

  • Q3. Wouldn't it be good to get this right, before the Spectrum Next is shipped to literally thousands of people?

[suborb]

I agree there’s a bit of confusion between target and cpu architecture and due to laziness I’ve made shortcuts on the test target which is probably the cause of it.

Changing the name of the target from zxn will break the samples that Alvin has deployed on forums etc

Which leaves us with sorting out the architecture. For the +test target that’s easily done, along with fixing the library name - I think I’m probably the only person who uses +test so I just have to type a few extra characters.

For +zxn usage the library name won’t matter, so should be _z80-zxn - we can define the —math32 alias to pull in the correct library. Similarly for any other targets that might use that architecture.

Unlike the z180/rabbit the z80-zxn is a fully compatible superset of z80 instructions so the name is ok, if ugly. Though I do like z80n. Users shouldn’t need to type it too much (if at all) since it should be embedded in .cfg files.

[feilipu]

Perhaps just going though consequentially and making sure zxn refers only to the target, and z80-zxn refers only to the architecture would help?

And making sure there are no underscores in architecture or libraries, only hyphens...

For example, I'd rename the math library to math32-z80-zxn.
The clib would become -clib=z80-zxn.
The rules would become /Z80/z88dk/lib/z80-zxn_rules.1

Thoughts?
Is that a plan?

__EDIT__. the hyphen applied consequently looks ugly.
Plus 1 vote to have _z80n_ as the architecture.

[suborb]

Yes, that's what I meant - the target zxn and the architecture whatever we choose.

I think the maths library would become math32_z80-zxn.lib - using the '_' to separate out the variants - certainly that's the "convention" for the ixiy libraries.

But yes, I'm happier with z80n

[feilipu]

• [x] check with @aralbrec @zx70 @pauloscustodio for unforeseen issues with z80n as the architecture
• [x] create a z80n branch
• [x] change all the things - #1228
• [x] commit it before the big shipment day for Sectrum Next

[zx70]

I quickly read the thread on mobile phone. I'd answer yes to Q1.
I also propose Q4 : ask for a next to each z88dk and zsdcc project participant :D

[Xalior]

I wish there was enough spare devkits for that @zx70 <3

[zx70]

Don't take me too seriously, I'm just following an old Italian made sentence: "asking comes for free"

[Xalior]

In Scotland we say “If you don’t ask, you don’t get.” <3

[aralbrec]

@feilipu Where are you getting this command line from? The compile lines for the zxn target are very simple. The z80n cpu is automatically chosen when compiling with a zxn target and the necessary option to z80asm is passed along without the user knowing.

A typical complete compile line for a project with many files and compile time options set is:

zcc +zxn -v -startup=30 -clib=sdcc_iy -SO3 --max-allocs-per-node200000 --opt-code-size @zproject.lst -o run -pragma-include:zpragma.inc -subtype=dot-n -Cz"--clean" -create-app

The +zxn is setting all the right switches including choosing the z80n cpu for the assembler. The startup is choosing the stdio configuration. Then the compiler and optimization settings are set. The @zproject.lst is a list of files in the project. The pragma-include is setting compile time options. The subtype is choosing output type. In this case a dot command but it could be any output type and this includes ones that put code into all the memory banks.

The correct version of a math library should also be chosen automatically so that "-lm" (etc) are automatically redirected to z80, z180, z80n, rabbit, etc types if there are variations. This sort of thing has been done by zcc (and is done by zcc) as it processes the command line.

Maybe the difficulty is in getting the classic library to set off all the right switches to get a generic compile. But in the newlib, it's all automatic. There are several large projects compiled for the zxn already and the compiles themselves are straightforward.

[suborb]

That's an expansion of a compilation for the test target running in this case on z80n. The "short" command line is:

zcc +test [file.c] -clib=zxn -DPRINTF --math32 -lmath32_zxn

Where --math32 maps to (via the .cfg file) -Cc-fp-mode=ieee -pragma-define:CLIB_32BIT_FLOATS=1 -lmath32. And -clib=zxn adds these options -mz80-zxn -Cc-mz80-zxn -Cc-standard-escape-chars -ltest_clib -custom-copt-rules=DESTDIR/lib/zxn_rules.2

The test target is a little unusual in that it supports all the available CPUs so you need to be a bit more explicit regarding "optional libraries" such as the desired maths library. For regular single architecture targets it all works out automatically in classic as well.

[aralbrec]

Ok. +test is a special case - for actual projects you wouldn't actually use +test to produce output.
z80n is fine as a cpu target name. In newlib the generic compiles are by cpu type so they would be +z80, +z180, +z80n (does not exist), etc. I personally prefer to have all the arcane switches automatically set by the tools. Programs compiled using these targets can be run on ticks as well - the only thing missing are drivers that write output to the console terminal that +test is providing.

Actually any target machine can generate code for address 0 and be run in ticks. The difference is the generic targets exclude all the architecture specific portions of the library so you get a truly generic bit of code that could run on any such z80/z180/etc system. That means no drivers for input or output including +test ticks console drivers.

[feilipu]

Ok. Rainy day here.
I'll have a go (since I raised it).

EDIT. I think it is done in #1228.
FURTHER EDIT. Tested using +test target and gets same answers as previous #1224

[feilipu]

Closed with #1228.