Did not read the whole thread, and my question is more about SDCC itself than libraries.
Writing my first C problem in it revealed that I have duplicate space for variables: one "to be" located in the perceived ROM, and another empty space "would be" a RAM part which is changeable. See very good explanation here.
This will grow program severely (as I have a set of ASCII strings), and requires startup code to copy (initialize) variables.
The obvious workaround would be to match areas called INITIALIZER and INITIALIZED and treat them as the same area. But how to do it?
Or I want to keep unitialized space outside of the program (let's say just after the code and const data) so that area would not be a part of the executable file. But anyway in this case the architecture is a waste of the memory space.
Any better suggestions?
Another issue I find when including crt0_msxdos.rel object code: first two instructions are CALL to sonewhere, and second is JP to small code setting a variable. And the first CALL calls are full of RST38 - it is the GSINIT area. There seem to be the RET at the end, but what is the purpose of spending time and code space on a hundred of RSTs? And where's variable initialization code?
I used to use MSX-C in the past, and that was an easy experience. The library I used that time was called UCLIB (united C library), and included all the routines for text, video and audio.
Edit: sounds like the same issue as DamendAngel reported several replies earlier in this thread. And it was two weeks ago!
I have already invested significant amount of time into writing libraries for the TCP/IP UNAPI support, and now can not properly set up the test bench for them. Who is responsbile for answering these quetions and resolving the issues?
Eugeny,
If you declare your strings that will not change as const you will not run into this issue.
Now, about global variables, simply do not initialize those variables at declaration, and everything should be fine, sdcc won't create that duplicate... (and if you are using Konamiman crt0, it doesn't copy the initializers anyway)
If you can rationalize your code so your globals are initialized by main or other function, and for your constant values like strings, initializing those as CONST, you shouldn't bump into this... At least this was the workaround I've found for my sdcc programs at this moment.
did you try to declare the variable as const?
You are right, if I declare const I must get them hardcoded into the ROM-type areas. The issue goes beyond that: all pre-initialized variables go into RAM-type area, and must be copied on startup (and this does NOT happen, albeit I include crt0_msxdos.rel). Of course as workaround I can initialize all variables at the start of the main(), but you guess how much unneeded extra code it will cause.
I will do it differently: I will write my own asm library for variable initialization, and will not use crt0 any more.
No, can not do it for simple reason - do not know how to figure out data size to relocate, and acquire start and end pointers in the asm code (no "extern" or "extrn" declaration in assember code).
I sent email to Nestor as he seems to be the person responsible for crt0_msxdos.rel object file.
I am shutting down my implementation activities on the UNAPI library for SDCC.
There is a workaround which is keeping your crt0msx_msxdos.rel/crt0msx_msxdos_advanced.rel as the last one in the command line. In my case, however, I edited crt0msx_msxdos.s this way:
_heap_top:: .dw 0 .area _GSINIT gsinit:
This ensures that gsinit will be anchored to the _GSINIT area, regardless of the rel placement order. It is working, but I don't know if
- This somehow has a negative/undesired effect;
- Not adding crt0msx_msxdos.rel/crt0msx_msxdos_advanced.rel as the last rel has a negative/undesired effect.
Could any of you clarify if my solution is/isn't the best approach to solve this case (and if it is, register my suggestion as a possible update for next versions of Fusion-C)?
Thanks in advance,
This code skips shit compiler puts into the _GSINIT section with crt0 jumping directly to RET instruction. But C variables remain unitialized.
The real problem here is that SDCC compiler, for some reason, does NOT put variable initialization code into GSINIT section.
I checked one of the executables from the examples/ section provided with the Fusion-C archive, and it is affected by this issue executing arbitrary opcodes in the GSINIT section until it (hopefully) reaches RET at its end.
I think I do not have issues with initialisers with SDCC, not sure about Fusion-C libraries.
I had to add this to the crt-msx code which should work for both ROM and MSX-DOS:
.globl l__INITIALIZED .globl l__INITIALIZER .globl s__INITIALIZED .globl s__INITIALIZER
.area _GSINIT
gsinit::
ld bc, #l__INITIALIZED
ld a, b
or a, c
jr z, gsinit_next
ld de, #s__INITIALIZED
ld hl, #s__INITIALIZER
ldir
gsinit_next:
.area _GSFINAL
ret
I had to add this to the crt-msx code
This is a solution (also seen in original crt0 code). Thank you.
Not sure why this code was removed in the first place for Fusion-C file.
Not sure why this code was removed in the first place for Fusion-C file.
it was not removed for Fusion-C.
The Konamiman 's crt0 exists since 2004 and the one from T.HARA since 2007.
Perhaps the reason was problems with the SDCC version in 2004 - 2007 ?
and it has never been updated for newer SDCC ' s version.
If you guys, are saying to me there is no problem or side effect in adding Initialization routine inside the crt0, I will add it to the updated version of Fusion-c