Experimental hack to hopefully allow WonderSwan toolchain to co-exist with MS-DOS cross toolchain etc.

[tkchia]

Hello @asiekierka,

Currently, as you know, (my fork of) gcc-ia16 directly supports building programs for the MS-DOS and ELKS target platforms.

I have now implemented a (still experimental) -mr=runtime option in gcc-ia16 (tkchia/gcc-ia16@7b96289), which will hopefully allow it to support other target runtime environments — such as your WonderSwan target — in a more pluggable fashion.

Basically, if you say -mr=foo, the ia16-elf-gcc driver program will now try to look for a spec file named rt-specs/r-foo.spec under an install-prefix/ia16-elf/lib/ subdirectory. The spec file can then control how ia16-elf-gcc invokes the actual compiler passes, looks for include files and libraries, etc.

This is all still very preliminary and amenable to change (though I hope not too much needs changing). 🙂

(Incidentally, it seems that the "standard" GNU way of porting the GNU toolchain to a new target runtime, is to

• introduce a new cpu-vendor-os target triplet, and
• rebuild the entire toolchain (!) to target the new triplet.

This would effectively mean having whole different sets of programs for ia16-pc-msdos-gcc, ia16-pc-elks-gcc, ia16-bandai-wswan-gcc, etc.)

Thank you!

[asiekierka]

Hey,

I'm happy you've added this. It will make the Makefiles cleaner (moving a lot of the hardcoded, platform-specific CFLAGS magic to a spec file) and the overall architecture easier to understand (in my opinion). However:

• I might sometimes rely on custom gcc-ia16 patches which are not upstreamed yet - like when I introduced the NEC V30MZ pull request a bit early, or as part of my (currently on hold, it's quite difficult and I maintain many projects) attempts to update to GCC 12.x.
• I still have many custom steps in the build system which may not be easy to integrate into a spec file - like swanlink, which wraps the linker to allow compiling for a WonderSwan (due to the way I use the bank mapping system of the WonderSwan, it makes the most sense to allocate the program binary at the top of the address space - from 0xFFFF0 downwards - in my current design), or mkfent, which turns binary files into WonderWitch-compatible metadata-attached files.

As such, I hope it is understandable that this issue may have a lower priority than other parts of the project (packaging binaries, further work on the standard libraries, etc).

I also don't think it will change much in terms of co-existing - if I'm using custom gcc-ia16 patches, my build still differs from upstream; conversely, if I'm not, you can still use gcc-ia16 binaries from build-ia16, as all of the magic currently happened in the CFLAGS/LDFLAGS area.

Thank you!

[tkchia]

Hello @asiekierka,

As such, I hope it is understandable that this issue may have a lower priority than other parts of the project (packaging binaries, further work on the standard libraries, etc).

Well, if and when you decide it is useful, just use it. Or not. 🙂

• I still have many custom steps in the build system which may not be easy to integrate into a spec file - like swanlink, which wraps the linker to allow compiling for a WonderSwan

Actually, there are a few spec string variables — such as post_link and self_spec — which might be able to help with that. See gcc/gcc.c. 😉 They are not documented in the GCC info file for some reason, but they are there.

Thank you!

[asiekierka]

As the Wonderful toolchain currently somewhat neatly installs itself in /opt/wonderful, arranges the equivalent of specs files via Makefile includes, and ships its own compilers/tooling, this remains a fairly low-priority task - nonetheless, I am keeping this issue open and archived.