??? 05/28/09 21:29 Read: times |
#165688 - it's much less for DATA Responding to: ???'s previous message |
Matthias Arndt said:
Actualyl I don't think that memory allocation is so tight for CMON51. It banks all monitor data to XRAM for user applications so I think it should do well with the full 256bytes available. I didn't investigate how does the actual monitor work, just looked at the listings. But as long as there's no memory qualifier, SDCC puts declared data into memory space based on the memory model set in command line, which is by default the direct-addressable DATA space. And that's much less than 256 bytes - it's the lower 128 bytes less registers bit data, overlayed data (which is just another form of local/automatic data) and maybe also something else I forgot. JW |
Topic | Author | Date |
SDCC Linker problem with CMON51 | 01/01/70 00:00 | |
a wild, wild guess | 01/01/70 00:00 | |
I already tried a typecast | 01/01/70 00:00 | |
Why not take this to the SDCC forum? | 01/01/70 00:00 | |
Already considered this... | 01/01/70 00:00 | |
another possibility which is easy to check if ... | 01/01/70 00:00 | |
I assume so... | 01/01/70 00:00 | |
findings | 01/01/70 00:00 | |
findings2 | 01/01/70 00:00 | |
Temporary fix | 01/01/70 00:00 | |
back to the drawing board... | 01/01/70 00:00 | |
it's much less for DATA | 01/01/70 00:00 | |
fix for --funsigned-char | 01/01/70 00:00 | |
I'd like to but... | 01/01/70 00:00 | |
how to patch | 01/01/70 00:00 | |
Patch worked but SDCC doesn't compile anymore... | 01/01/70 00:00 | |
HOW doesn't compile? | 01/01/70 00:00 | |
Buffer cut | 01/01/70 00:00 | |
not enough direct-addressable memory | 01/01/70 00:00 | |
Nice idea but.... | 01/01/70 00:00 | |
I can try with the versions I have here... | 01/01/70 00:00 | |
Sure, why not | 01/01/70 00:00 | |
Solution found | 01/01/70 00:00 | |
SDCC Linker problem with CMON51![]() | 01/01/70 00:00 |