A good balanced solution between an available complete interpreter like MSX-Basic and "a big-programming-effort" new compiler written from scratch, is to write a transpiler, why not.
Also, a good library to manage objects, pools, garbage collection, etc. could implement a Java like virtual machine (more simple, of course). Some parts of the TMS are already organized like a VM, think about sprites, or the interrupt system.
On the C64 side people have had some success with compiling to x86 assembly and convert to 6502 assembly.
CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17”
You need to put some of the x86 registers in memory and stuff and decide how to handle in/out instructions, but otherwise it should be fairly straightforward.
Just a brainstorm caused by the above post:
What if a compiler would be build that creates machine code from the C++ source. That code would be messy and slow right? but then there is another tool that takes this code and optimizes it and cleans it so that it runs reasonably fast. The assembler optimizer allready exsists so it should be possible. If the same kind of tool could do conversion and cleaning of x86 opcodes?
8086 addressing is not raw (uses segment registers CS, DS, SS, and ES which then shifted 4 bits to left and added to addressing register to bring the full 20 bit address) so it might be real PITA to convert 8086 asm to z80 - while other stuff like some command's relative addressing etc could be handled with less pain but making resulting code slow (thus one 8086 command will be translated to a chunk of z80 commands most of time and also will need stack operations to store intermediate data). not sure if it worth the effort though
I think the x86-6502 converter does a lot of assumtions.
It is pretty safe to assume that something compiled for a z80 memory space will never try to reach outside of the 64k space, and if it does it is perfectly fine to let the conversion fail.
They probably also don't support instructions that the compiler rarely outputs for code that is aimed at an 8-bit platform like fpu or simd operations.
My guess is that they just looked at what compiler produced for some common cases and supported just that specifically.
Either way, if there is a working example for 6502 you can't really get away with saying "x86 and z80 are too different to make it feasible."
Jan Wilmans of the nowind team also had an idea a few years ago to translate assembly code as output by a C++ compiler to Z80. He focused on less complex CPU than x86, like MIPS or ARM. Not sure how far he got.
Just a brainstorm caused by the above post:
What if a compiler would be build that creates machine code from the C++ source. That code would be messy and slow right? but then there is another tool that takes this code and optimizes it and cleans it so that it runs reasonably fast. The assembler optimizer allready exsists so it should be possible. If the same kind of tool could do conversion and cleaning of x86 opcodes?
It is not about asm code efficiency, a C++ object has destructor, constructor, copy and other methods, and each class has quite some extra stuff to perform that, on a modern cpu that has plenty performance and memory that overhead is peanuts, for z80 and 64KB it weights quite a lot... No ASM optimizer will work around the extra functionality, perhaps just make it a little less resource hungry, but still hungry
Jan Wilmans of the nowind team also had an idea a few years ago to translate assembly code as output by a C++ compiler to Z80. He focused on less complex CPU than x86, like MIPS or ARM. Not sure how far he got.
I just found this one llvm-z80
I believe this could be the way to go actually to implement which languages compile to llvm
It is not about asm code efficiency, a C++ object has destructor, constructor, copy and other methods, and each class has quite some extra stuff to perform that
The youtube clip I posted clearly shows that that isn't necessarily true.
8086 addressing is not raw (uses segment registers CS, DS, SS, and ES which then shifted 4 bits to left and added to addressing register to bring the full 20 bit address) so it might be real PITA to convert 8086 asm to z80 - while other stuff like some command's relative addressing etc could be handled with less pain but making resulting code slow (thus one 8086 command will be translated to a chunk of z80 commands most of time and also will need stack operations to store intermediate data). not sure if it worth the effort though
Exactly. The same apply to 6502 . they have done a kind of POC.
It would be funny how they manage to translate some instructions like :
REP STOSW
any segmented addresses
relative jumps (bigger size if i remember correctly)
LEA instructions........
plus the instrisic complexity of c++ vs C make the code bigger....
Just to mention one. C++ can do copy constructors which you cannot emulate by simply doing a bit copy (LDIR).
There are also template and t. specialization.... which consume a lot of code
there is virtual dispatching...... naaaaah.