bengalack

Thank you. Some quick tests look promising!

I thought I was "lucky" when I saw that openmsx debugger would be able to read and print IEEE754 floats, because I had read somewhere that SDCC uses IEEE754. Which, when I read the proper manual, is not the case. SDCC uses something "somewhat similar to IEEE". Is there a known way to convert SDCC floats IEEE754?

I was thinking along those lines too, but I ditched the idea when I thought that: then SDCC 4.2 should not have worked (but it did). But hmm... I see now that SDCC 4.2 does NOT have the cc1 file in /bin at all. And now it works! Obviously wsl must have its own cc1.exe which was started. THANKS! Things are rolling again :)

I suddenly got this today (using sdcc 4.5): C:\source\repos\viott_main\viott>sdcc -c -mz80 --opt-code-speed vdptest.c -o objs\vdptest.rel cc1.exe: error: unrecognized command-line option '--obj-ext=.rel' -:0: warning 190: ISO C forbids an empty translation unit subprocess error 1 It was working fine two days ago. In the mean time, I think the only thing I've done to the system (win10) is to install wsl (windows subsystem for linux). 4.5 reinstall did not help. But switching back to my 4.2.2 install...

Oh oh! This fixes everything. Thank you so much! Everything fell into place now. -Following the ordering I wrote in the crt! Happy chap here now! As for the bug itself... We see from the forum thread, as well as this bug, that there are lots of ideas of how to improve this "area". This bug does not really describe anything about that, so it should prolly be closed and replaced by a proper task.

I wish I could use what you suggest. But I actually tried this yesterday with my real world example, and as I'm not too fluent in these tools, I met a roadblock when my app.c was using a bunch of other library functions (like printf and misc others). The linker stopped because these/something was missing. So more steps are needed (sdcc lib files somehow?). These steps where just automagically happening when I put the c-file together with the linking step. (not at my home computer right now, so I...

Thank you for pointing out this one. But in this case, I had already planned to have all my _CODEin page 1 as non-banked. The segment will stay there through the lifespan of the application. That is why it is strange that the compiler moved some code away from the rest of my code and after DATA (eating up my precious ram above 0xC000, it just seemed out of my control. But that is also why I asked, to get hints about how to steer away from this magical move :)

Thanks for helping out Janko! I was asked to file a bug, so I did with a small example, and I attached zip file there: https://sourceforge.net/p/sdcc/bugs/3819/ It is not 100% identical to my real world case, as that application is pretty big and with too much "noise" (it used to be built with '--data-loc 0' as it was previously made for MSXDOS, and that just worked out of the box, that's why the program got big before I stumbled across this issue). I have found that I can manually set these segments...