Z88dk: (newlib) rc2014 link subtype I/O routines

[feilipu]

The RC2014 has a number of underlying loader or O/S options, all with different in_key routines.

Currently there seems to be no way to discriminate for the correct routine, when the respective subtype is required.

The subtypes are:

• BASIC
• CPM
• HBIOS

Its easy to discriminate for the include, through a definition, but I can't see an easy way to get just the correct functions built, and then linked, because there is only one generic make option file list used.

Could all the options be built, and then at link time just ensure the correct objects are provided?
I don't know how that would work at link time though?

eg to build for sccz80

@input/basic/input_sccz80.lst
@input/cpm/input_sccz80.lst
@input/hbios/input_sccz80.lst

[suborb]

There's a few ways of doing this at the moment:

1. Create a separate library the contains only the OS specific code and supply that library on the SUBTYPE line in the .cfg file
2. Use a variant of -pragma-redirect to point the "name" routines to qualified routines (eg defc in_key = in_key_BASIC, defc in_key = in_key_HBIOS in the crt0)
3. Similar to 2, but just include the files into the crt0 file - the same way printf is handled.

I fell like 1. is much cleaner and allows any "common" library routine to be overloaded (later libraries on the command line are searched for routines first by z80asm) - it's the method used by classic +cpm to provide machine specific gencon, graphics etc - it will be possible to combine both sdcc and sccz80 routines in a single library since their entry points are different (similar way to how classic does it) which reduces the linking options a little.

Two has the downside of #692 where the routine will always be present even if it's not used and 3 obviously has the same drawback.

[feilipu]

It wouldn't be too hard to do something like a maths library then, and take Option 1.

But that would mean 3 additional libraries just for the RC2014 target, with perhaps 40 lines of assembly each cluttering up the ~/_DEVELOPMENT/target/ directory. There's already too many maths libraries in there now (that aren't true targets). I guess it was ok when it was just math48 to worry about in the directory.

Its possibly time to split the newlib in to ~/_DEVELOPMENT/lib/ and ~/_DEVELOPMENT/target/ directories?

Currently the ~/lib/ directory is just for third party libraries, so that would have to be relocated, and then if third party libraries were relocated then z88dk-libraries needs adjusted.

[suborb]

I suspect a little reorg might become necessary.

These little libraries shouldn't be "targets" in the true sense, so don't belong in the top level makefile, but probably ought to be built by a future makefile in target/rc2014. The code should probably live down there as well rather than at the top level input/ directory.

I'm not keen on updating that batch file though if we make the change.

I've not taken a look at the lib folder yet so I'll comment on that when I get a chance

[suborb]

I've added some makefile gunk in branch feature/1568_newlib_linklibs to scan target/${TARGET}/library/ for extra lst files.

We can have extra library files for:

• sccz80 target/zx/library/zxfoo_sccz80.lst creates lib/sccz80/zxfoo_sccz80.lib
• sdcc_ix target/zx/library/zxfoo_sdcc_ix.lst creates lib/sdcc_ix/zxfoo_sdcc_ix.lib
• sdcc_iy target/zx/library/zxfoo_sdcc_iy.lst creates lib/sdcc_iy/zxfoo_sdcc_iy.lib
• asm target/zx/library/zxfoo_asm.lst creates lib/asm/zxfoo_asm.lib

If the concept works I'll try to remove the extra "type" qualifier.

Ironically, I can do makefiles but not batch files, so we might be best off deleting the batch file.