Hi Wysardry,
Thanks for considering Cross-Lib even though you have not tried it, yet.
I have not tried it on MinGW. It could work “out of the box”. I will try it and see if it works and if it doesn’t, I can try to make it work.
In the future, I plan to also package everything in a Docker container so that you can use it without any dependencies (except for an environment that can handle Docker).
Cross-Lib’s minimum requirements are:
POSIX-like environment
Makefile
Some C compilers and/or cross-compilers (even just native gcc would be enough to do something)
Strongly recommended:
Python is necessary if you want to use it with the “xl” script. Otherwise you could still build the projects with longer Makefile commands.
With just gcc and no other compiler you can build the projects natively (currently only for the PC console with ASCII graphics). If you install some cross-compilers such as CC65, Z88DK, CMOC, etc. you can do more interesting things like building for a vintage 8-bit system.
For example if your environment only has Makefile, gcc and Python, you should be able to run the following commands from the “src” directory:
“xl horde” → builds a PC native version of Cross Horde
“xl snake” → builds a PC native version of Cross Snake
If you install CC65 (by just unzipping the Windows Snapshot or from source):
“xl horde c64” → builds Cross Horde for the Commodore 64
“xl snake atari” → builds Cross Snake for the Atari 8-bit
I second Lars. FORTH was engineered for exactly this class of processors. C was available back then too, but C compilers tend to emit bloated code for an 8-bit uP. You’ll fill up your address space fast.
I disagree, 8 bit micros handle 8 bits, with some 16 bit operations to make life easy.
C and other Langages use 8 and 16 bit data for the ‘small’ versions, and needs stack addressing.
There is no bloat, as it just takes more code for 16 bits, in any language as you now deal with 2
bytes of data. Virtual machines worked well as a byte opcode could handle a simple stack based language. Western digital had chip set that could handle Pascal’s P-code, until Pascal started to
change P-code with every new revision of the language.
At that time small versions of Pascal and C, could self compile the 8 bit machines.
Need floating point data, buy a Pee-ceee.
Ben.
I had been playing with the idea of writing a PL/M compiler (maybe with a bit more C-like syntax), especially for generating WASM binaries. However, the very forte of PL/M, namely the ability to address individual registers and memory in a high-level language, is also a major drawback when it comes to cross-platform code. Provided how different the various architectures are regarding their count and use of registers (just compare Z80 and 6502) I really don’t know an answer. I guess, you’d want something that is heavily relying on library abstractions and where code would merely accounting for high-level business logic. But this wouldn’t be that 8-bit like, where the fun and challenge is all about staying close to the hardware.
But, if you are limiting your target platforms to a single CPU architecture and are just abstracting I/O, something like PL/M may be a viable approach. (There’s a reason it was used for CP/M.)
PL/M most likely ran on a PDP-10. It was the cloud of the 70’s. The CP/M sites have all the details.
Self hosting was novel idea even for 16 bit machines.
Ben,
@oldben a lot depends on the processor and task. I can routinely beat SDCC by quite a margin on Z80 and similarly for a lot of 8bit compilers and processors (except 6809). On the other hand I won’t easily beat an ARM64 or x86_64 compiler except where I can use assumptions the compiler is forbidden from making.