#46 Allocate unused reg banks even when bit vars exist

closed
nobody
None
5
2004-01-21
2003-11-20
No

Hi.

There seem to be a problem (almost a bug, actually,
given that we have only 256 bytes of data to use, it
is more severe than some bugs are:) that the unused
register banks are allocated for data only if there
is no bit variables defined.
It is very inefficient to use "char" instead of "bit",
but loosing 24 bytes is even worse, so I have to use
"char" when "bit" is enough.

The following example demonstrates the problem:
---
char a[20];
bit b;

int main()
{
return a[0];
}
---

The .mem file contains the following:
---
DATA 0x21 0x34 20 128
---------------- -------- -------- -------- --------
TOTAL: 0x00 0x34 29 128

Stack starts at: 0x35 (sp set to 0x34) with 203 bytes
available
---

But should I remove the "bit b;" line, and the .mem
file contains:
---
DATA 0x08 0x1b 20 128
---------------- -------- -------- -------- --------
TOTAL: 0x00 0x1b 28 128

Stack starts at: 0x1c (sp set to 0x1b) with 228 bytes
available
---

Very annoying. My current work-around is to do a
manual data storing using an "at" keyword to fill
the gap of 24 bytes.
Can this please be improved?
I hope I am not missing something obvious and it is
not the matter of some command-line option, or is it?

Discussion

  • Stas Sergeev

    Stas Sergeev - 2003-11-20

    test case

     
  • Jesus Calvino-Fraga

    Logged In: YES
    user_id=603650

    I am currently working on that. This feature has been
    requested so many times that it can not be ignored anymore.
    It is mostly working, but the map and mem files are a mess.
    (Before commiting any changes everything has to be working
    fine). Also there is the issue of backward compatibility I
    haven't thought about much yet...

    Jesus

     
  • Stas Sergeev

    Stas Sergeev - 2003-11-21

    Logged In: YES
    user_id=501371

    Hi.

    > I am currently working on that.
    Sounds encouraging, thanks for your efforts.

    > This feature has been
    > requested so many times
    At least not among the currently-opened RFEs:)
    But I haven't checked the mailing-lists, that's the
    problem.

    > Also there is the issue of backward compatibility I
    > haven't thought about much yet...
    Hmm, just wondering what can that be. Are there any
    programs that rely on that particular memory layout?

    Anyway, that would really help to have that feature
    working, so keep it up! Good to know that it is nearing.

     
  • Maarten Brock

    Maarten Brock - 2003-12-22

    Logged In: YES
    user_id=888171

    To Stas,

    You asked if there were more RFE's you requested, that I filed
    already and here's my answer: Yes, we have a winner! It's
    this one. (compared to the "daunting task" in RFE 837937)

    But there's no need to delete this one since Jesus mentions in
    this thread he's working on it. So, let's wait and see.

    Greetings,
    Maarten

     
  • Stas Sergeev

    Stas Sergeev - 2003-12-22

    Logged In: YES
    user_id=501371

    > this one. (compared to the "daunting task" in
    > RFE 837937)
    Hey, you put 2 separate problems in a single RFE, and
    there is *nothing* in the summary that could hint (me)
    about the second part, so don't blame me on that one:)

    > At least not among the currently-opened RFEs:)
    OK, that was wrong. Sorry.

     
  • Jesus Calvino-Fraga

    Logged In: YES
    user_id=603650

    Just commited to CVS a linker with the option to pack
    variables in internal RAM as much as possible. For now call
    sdcc when compiling/linking using for example

    sdcc -Wl-Y[stack_size] myfile.c

    The result may look like this:

    Internal RAM layout:
    0 1 2 3 4 5 6 7 8 9 A B C D E F
    0x00:|0|0|0|0|0|0|0|0|b|b|b|b|c|c|c|d|
    0x10:|d|d|d|d|d|d|d|f|3|3|3|3|3|3|3|3|
    0x20:|B|B|a|a|a|a|a|a|a|a|a|a|a|a|a|a|
    0x30:|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|
    0x40:|a|a|e|e|e|e|e|e|e|e|g|g|g|g|h|h|
    0x50:|h|h|h|h|h|h|h|h|h|h|h|h|h|h|h|h|
    0x60:|Q|Q|Q|Q|Q|Q|Q|I|I|I|I|I|I|I|I|I|
    0x70:|I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|
    0x80:|I|I|I|I|I|S|S|S|S|S|S|S|S|S|S|S|
    0x90:|S|S|S|S|S|S|S|S|S|S|S|S|S| | | |
    0xa0:| | | | | | | | | | | | | | | | |
    0xb0:| | | | | | | | | | | | | | | | |
    0xc0:| | | | | | | | | | | | | | | | |
    0xd0:| | | | | | | | | | | | | | | | |
    0xe0:| | | | | | | | | | | | | | | | |
    0xf0:| | | | | | | | | | | | | | | | |
    0-3:Reg Banks, a-z:Data, B:Bits, Q:Overlay, I:iData, S:Stack

    Stack starts at: 0x85 (sp set to 0x84)

    Other memory:
    Name Start End Size Max
    ---------------- -------- -------- -------- --------
    EXTERNAL RAM 0x0000 0x0306 775 65536
    ROM/EPROM/FLASH 0x0000 0x7975 31094 65536

     
  • Stas Sergeev

    Stas Sergeev - 2004-01-21
    • status: open --> closed
     
  • Stas Sergeev

    Stas Sergeev - 2004-01-21

    Logged In: YES
    user_id=501371

    Thanks, looks like a very nice addition. Also solves another
    RFE about a stack location.
    I think I should close that RFE.
    The only thing that looks a bit confusing is that the vars
    marked "idata" can now be placed in data and vice-versa.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks