I was wondering if anybody already tried to use a "C++ to C" convertor and then compile the code with a Z80 C compiler?
I have this in mind for a while now but have not really searched for the way to convert C++ to C (doesn't GCC or LLVM allow that?).
try yourself ;-) and look of how much inefficient and big code size is.
I didnt understand "file-pointer magic variable ($$)"?
Some assemblers have a variable similar to $, which returns the current output file address rather than the current compile address.
And the only need I see on the assembler side is bigger variables
the low 16bit used the usual way, while about the upper bits the assembler doesnt know the use
Well, guess that makes sense, I can just encode stuff in the upper 16 bits of the ORG address. In Glass all variables are 32-bit, so if I remove the out of bounds check (which I don’t do for regular values either), that would go a ways. Feels a bit hackish still (as-in the compiler won’t complain if I try to jump to it) but maybe a good start, once I use it maybe some more fancy idea will emerge.
Feels a bit hackish still (as-in the compiler won’t complain if I try to jump to it)
what bugs can a FFFF border catch.
in a mapper code one can get problems above 0x3fff
except it is thought to be executed in page 2, then the problem is above 0xbfff
when it is 64k stuff, then the problem is above HIMEM.
the FFFF didnt really warn things anyways, nothing is lost when labels can be above FFFF.
one could warn a JP or CALL to a label that has a HI HI byte different than the current code.
but only if it has the same top 2 bits in H. because with a jump to another page, who knows what is in the mapper register.
but. a library function that has only relative jumps can execute in any page. very handy.
the assembler cant even know the top 2 bits of the program counter!
so it could make false warnings when the function makes a CALL.