Z80Babel: C++, D, Rust, Zig and Fortran

right! so it just a problem with the output syntax of the generated code not being compatible with the gnu assembler. With the patch provided in https://github.com/codebje/ez80-toolchain the whole toolchain actually does work!

Thanks a lot for the pointer Giangiacomo!

so, I was a bit curious how I would imagine near-perfect C compiler output for the sieve_c_1, and wrote it in hand-assembly...

I'm almost done with it, just cleaning up remaining kinks and testing it, and did check the repo, and there is now actually "HAND_CODED_ASM" added to the repo, and it's
a) surprisingly close to what I have, although slightly different
b) not 100% correct...

I will post my version when I will finish the cleanup, so I will just post issues I see with the HAND_CODED variant:

- for work_size=1 it will erase whole memory and crash (ldir with bc=0).
- for work buffer perfectly aligned to end of 64ki address space the `work+work_size` will be 0x10000, causing the routine to never detect end of for loops (BC=0x10000&0xFFFF==0)
(I don't know how MSX memory map looks, but on ZX the RAM is at 0x4000..0xFFFF, so having work buffer at end is acceptable).
- similarly having work_size of odd value and and work+work_size resulting to 0xFFFF will make _begin_loop_1 infinite, as the +=2 will wrap address to 0x0000 and that's < 0xFFFF.
- the inner loop could also wrap around infinitely for work buffer too near the end of RAM when work[i] is legal, but work+i+i+i wraps around address space (`add hl,de` ahead of "; de 2 * i " comment)
- and again after work[j]=1 the `add hl,de` is unprotected and may wrap-around and cause infinite loop

(and I know, because I have a bit different logic, but ended up crashing the ZX emulator in first versions because of these issues... before making the tests mathematically correct).

Hopefully I will manage to cleanup my version today and post it, it caught me a bit by surprise how difficult it is to write this thing correctly with reasonably simple code. Anyway, that's the "what C compiler hypothetically can output" attempt, then I will try one more doing real hand-assembly, with all the dirty assumptions and shortcuts which are not part of the original C code and can't be derived from it, so somewhat cheating... just for some comparison. But my current attempt is like ~100 bytes long, which seems to be still far ahead judging by the older info captured in screenshots. (I didn't run latest version of test, as I don't have z88dk and other tools installed, and not wanting to set it all up, so I'm just following the source and committed results. )

Sorry to hear about your computer, I hope you can recover everything!

But omg, you want to test a deep learning framework on a z80! lol! Well, maybe you can do inference of an already trained tiny model, could be fun! Many giant models these days use bfloat16 for the activations (at least in language, not sure in vision, but you'll know that better than me ). So, once trained, probably 16bit floating points are fine on a z80 too But training is probably a no-no hahaha

uh, toying with it too long... so here is my C-like hand written asm for sieve: https://gist.github.com/ped7g/c55bfa0d55ca13ce029549636cdd1de5
(syntax is official Zilog + sjasmplus directives, so may need patching to z88dk z80asm - I'm not familiar with those non-official syntax tools, but I guess that shouldn't be difficult to fix ... also the ABI is custom-tailored and to call it from C it would need some wrapper function transforming arguments to expected registers and preserve whatever has to be preserved).

What means "C-like asm": I tried hard to use only information which can be machine-derived from original `sieve_c_1` C source, ie. hypothetically ideal compiler could produce the code from the C source (unless I slipped somewhere and used some human-derived guess :) ), and the code respects all value types, so it should work correctly even when you put 63ki work buffer onto it on some hypothetical platform with full 64ki of RAM free.

BTW the "primes" and "work" buffer can overlap (work starting at primes+2) to maximise the number of primes returned.

I'm now thinking about writing "real" asm version with all kinds of human assumptions and shortcuts, having extra constraints for caller, optimised solely for performance and probably using work buffer in different way (only odd numbers), for further comparison. But it feels the performance gain will be not that huge, the current code feels decent and I don't see too many extra tricks possible.

BTW2: this is surprisingly similar to asm version currently included in z80_babel, except that one can bug out for some input values as mentioned in my previous reply, my version should be more robust and so more compiler-like. I think my version may be somewhat slower due to extra checks of validity of pointers, but maybe not, some of the arithmetic is more streamlined, so maybe it will be almost on par.

And this is version 2, not trying to imitate hypothetical C compiler, but just going for something what I would write in asm-only project: https://gist.github.com/ped7g/1602d2e165850b55f6a52749d9811544

It departs in algorithm from sieve_c_1 by using work buffer for odd numbers only (so it can check twice as many numbers with same work_size).

With 1024 bytes buffer it does produce 309 primes (like C routine with 2048 buffer in z80_babel test run), and it takes about 46ms at ZX Spectrum at 3.5MHz (would be probably slightly slower on MSX due to extra T states on some instructions, probably like 50-55ms), code is 138 bytes.

And in direct comparison with my previous C-like version, when tuning the work_size to fit single frame in emulator (20ms), the first version can produce first 95 primes, second version can produce first 150 primes, so about +57% speed up.

Unfortunately it's using hard-coded buffers and constants, so this one would be harder to incorporate into babel project, I made it more to satisfy my own curiosity than to worry about fitting it as test case (but the first version on previous link should be reasonable easy to add to project, if somebody wants to).

And my personal curiosity (to compare with C compilers) is satisfied now, so I'm done with this (will keep an eye on this thread for few days in case there are some questions or comments). Cheers.