yup, I am aware and using that command line option: --sdcccall 0. Very kind of the SDCC guys to add it to allow for backwards compatibility, but it seems they missed some things.
I am double checking, but so far I am pretty sure those are bugs.
When I converted my MSXgl library to use the new calling convention, I followed these steps:
-- I got SDCC 4.1.12 with the 4.1.11 standard libs (the last ones compiled with sdcccall 0) and compiled my lib with the --sdcccall 0
parameter. This allowed me to check that apart from the change of calling convention, there was no other incompatibility with this new version (which was the case because it compiled without any problem and all my test-cases were functional). Previously I was using version 4.0.0.
-- Then, I got a full SDCC 4.1.12 version (with libs in sdcccall 1) and I put by hand the __sdcccall(0)
directive on all my functions with inline assembler that the change of call convension could break. I then compiled and tested with --sdcccall 1
and again, I had no problems.
-- Finally, I started to convert my inline assembler functions and removed the __sdcccall(0)
as I updated them (I still have a few to convert by the way).
Right, so you also found issues with the standard library?
It's not really an "issue".
4.1.12 lib is compiled with --sdcccall 1
so you can only use it if you also compile your code with --sdcccall 1
.
I asked Philipp Klaus Krause why they didn't provided both version of the library.
Here is his answer:
« SDCC 4.1.12 comes with the new lib only. Shipping two versions of the library didn't seem worth the effort, as we didn't expect many users. We expected the main use of --sdccall 0 to be for z88dk (who ship their own library and don't use the one that comes with sdcc). »
Here is his answer:
« SDCC 4.1.12 comes with the new lib only. Shipping two versions of the library didn't seem worth the effort, as we didn't expect many users. We expected the main use of --sdccall 0 to be for z88dk (who ship their own library and don't use the one that comes with sdcc). »
Right, so --sdcccall 0 is not intended to keep backwards compatibility, is just for z88dk. In general they just broke backwards compatibility. Good that this is clear now!
In the same way, I expect the other "bugs" I am finding to be "not really issues" because they are deliberate backwards compatibility breaks and is a waste of time to try to upgrade version. Just rewrite everything!
awesome.
I think that you should definitely have a look at samsaga2's solution for building megaroms
https://github.com/samsaga2/sdcc_megarom
The files have been updated to SDCC V.1.12 and a makefile for windows has been added.
Moreover, samsaga2's solution for including binary data in banks is very direct, just add to the C file to be included in the bank this
static void data() __naked { __asm .incbin "tile0.bin" __endasm; }
That is actually a nice trick, I guess then you can access the data using a variable by casting the function pointer?
Yes, in C you can cast it to the data type you need or use it in ASM because it becomes a global label
In ASM, from other banks or from the common area, you can also refer to its bank number by b_XXXX where XXXX is the name of the function.
E.g. for the data above, this is the direct value of the bank in witch the label _data is
ld a,#b_data ; bank number in A ld hl,#_data ; address in HL
BTW, I found some free cycles between IRQs and I could update the megalinker to provide support for the latest SDCC object format:
https://github.com/MartinezTorres/megalinker
I know that there are a lot of new possibilities to support banking in SDCC, but I still like my own where I have manual control of segment loading and page mapping. So this megalinker is still an option if anyone fancies.
It is tested on the: msx_karts with SDCC V4.1.1.14, and it works nicely. The new calling convention of SDCC is amazing!
I think that you should definitely have a look at samsaga2's solution for building megaroms
https://github.com/samsaga2/sdcc_megarom
The files have been updated to SDCC V.1.12 and a makefile for windows has been added.
Seems like everyone picks up existing libraries for C to make their own without sorting out what's inside.