z88dk: source code reorganization

[aralbrec]

z88dk's source code organization has been growing a bit like a weed over the past decade and needs some attention to restore a cleanly organized code base.

As part of that I'd like to move the new c library out of the basement (z88dk/libsrc/_DEVELOPMENT) and into a parallel footing with the classic c library in z88dk/. We can also take the opportunity to get rid of unused bits or reorganize the source code tree in the classic c library and perhaps come up with a way to share more of the code between the new c library and the classic c library. Although some things are different between the two, there is no need for two stdlib implementations, for example.

I think it would be a good idea to think ahead a little bit to what else might be added and how it should fit into the directory structure. There are three things that may come in in the long run:

• I'm thinking about standalone operating systems for z80 systems. Things like Fuzix or CPM. Fuzix has its own git repository but it's looking like it would not be possible to cleanly add z88dk as z80/z180 compiler into the code base. The reason is z88dk is a much lower level compiler that contains a lot of assembly language and its c libraries contain a lot of specialized prototypes to communicate assembly language level attributes like call linkage, register preservation and so on. These headers do not look anything like what is shared in Fuzix between the 65xx/68xx/z80/68k/etc c compilers. I'm also seeing that there may need to be substantial changes made within the Fuzix code base to take full advantage of z88dk which would be disturbing to the existing ports.

• In the faraway long term, there is the possibility of using LLVM to compile languages other than C using z88dk. In that case these other languages might need different runtime libraries that would be conceptually at the same level as the new or classic c libraries.

• I'd like to look at properly supporting z80-derived chips like z180, ez80, rabbit and so on. How should that fit in?

[aralbrec]

Something to look at during the source code reorganization has to do with _LIB being unnecessary and revisiting the possibility of mixing object files generated by sdcc and sccz80: #9

[suborb]

lib/ is a bit of a mess with headers from many different targets co-mingled.

We should be able to create a directory per target that has the .def and crt0.asm files within it.

[suborb]

Re Fuzix. I think we can treat Fuzix as just another target for z88dk. The core libc has the same functionality afterall - it just needs appropriate device drivers.

Given that the kernel doesn't really use libc the only benefit of using z88dk to compile it would be some of the optimisations that have been added, but these may well be picked up upstream by sdcc in anycase.

Again, this might be part of the re-org though, properly locating machine specific headers into a machine directory and auto adding -I{include}/{machine} to the config files to provide an effectively flattened header space.

[suborb]

A few weeks ago I sorted out lib - creating an arch (for CPUs) and target (for machines) directory structure.

target has this structure:

target/[machine]/def - constant files for the target
target/[machine]/classic - crt files for classic

Which would allow newlib crts to sit alongside at the same level.

[zx70]

This seems to be an interesting way to begin experimenting with the eZ80:
https://github.com/CE-Programming/CEmu

The pre-built version for Windows is 64bit which I can't test at the moment, but reading the project description it looks promising.