Menu
▾
▴
#87 idata before stack, char idata array[0x81];
currently the stack segment is located _before_ the
idata segment.
I don't like this, as this f.e. means that you have to
specify --idata-loc
if the needed idata memory exceeds 128 bytes.
As both segments access the same memory area it
shouldn't matter
which one is allocated first. BUT the size of the idata
segment is known whereas the size of the stack segment
is not.
So it seems a good ideal to place the idata segment
before the stack segment?
Logged In: YES
user_id=888171
Unless I'm mistaken, this is already what --pack-iram does.
Have you tried it?
Maarten
Logged In: NO
Yes, I occasionally used it and it does the right thing:)
So why should I ask for this again?
I was looking at the file sdcc/device/lib/_ltoa.c
where the first function defines: char buffer[32] which
defaults to the precious DATA memory space.
I would have wanted to change that definition to
#ifdef SDCC_MODEL_SMALL
char idata buffer[32]
#else
char buffer[32]
#endif
to use less valuable idata memory. As I see it this would be
OK for 256 (data+idata) byte devices but would break for the
128 (data+idata) byte devices (because --idata-loc defaults
to 0x80).
Any file that uses arrays in data memory could be a
candidate for a change like the one above. In fact it might
even make sense for SDCC (in small memory model) to
automatically put arrays without explicit memory specifier
into idata (instead of data) memory!?
I maybe had better asked: Any chance that the memory map of
--pack-iram will become the default memory mapping?
Logged In: YES
user_id=888171
--pack-iram is now the default. Use --no-pack-iram if you still
need the old behaviour.