The new abolute code allocation

[Steven Borley]

Maarten,

I guess I'm aiming this question mostly at you, but I hope it is of global interest and I don't mind who replies.

In a followup to a bug report (1572067) Maarten recently wrote...

"Currently absolute variables in code memory are not
allocated when no initializer is used: SDCC creates an equ.
If you do use an initializer it is allocated in .area CABS
(ABS,CODE)."

Maarten, I was wondering if you could expand on this a little as I am having difficulty with this...

unsigned char __code __at(0xD00) good = 'g';
unsigned char __code __at(0xE00) bad;
void main(void)
{
}

When compiling with snapshot #4409 I get...
$ sdcc test.c
test.c:2: error 99: variable 'bad' declared in code space must have initialiser
test.c:2: error 99: variable 'bad' declared in code space must have initialiser
test.c:5: error 103: code not generated for 'main' due to previous errors

For your comment I was expecting the 2nd line to compile. (and why two identical error reports?)

If I omit line 2 it does compile and in my .asm file I get, as expected...
    .area CSEG    (CODE)
    .area CONST   (CODE)
    .area XINIT   (CODE)
    .area CABS    (ABS,CODE)
    .org 0x0D00
_good:
    .db #0x67

Whereas an older snapshot (#) just gave...
    .area CSEG    (CODE)
    .area CONST   (CODE)
_good    =    0x0d00
    .area XINIT   (CODE)

From you comment this was what I was expecting to get from my 2nd line of the above code...
    .area CSEG    (CODE)
    .area CONST   (CODE)
_bad        =    0x0e00
    .area XINIT   (CODE)

Regards,
Steven

[Maarten Brock]

Hi Steven,

Yes, that was what I had in mind, but I goofed. Indeed SDCC still wants an initialiser for every variable in code memory or otherwise generates the error. It used to REQUIRE the initialiser and then throw it away, now it's used as you can see.

I'll see if I can disable the check for the second case.

Maarten

[Maarten Brock]

Fixed in #4410.

[Steven Borley]

Maarten,

Thanks. Nicely done :-)

For anyone following this thread, I now get this with the code I previously posted...
    .area CSEG    (CODE)
    .area CONST   (CODE)
_bad    =    0x0e00
    .area XINIT   (CODE)
    .area CABS    (ABS,CODE)
    .org 0x0D00
_good:
    .db #0x67

(thus bad is now poorly named!)

It is even possible to do things like this...

short __code __at(0xd00) number = 1026;
char __code __at(0xd00) msb;
char __code __at(0xd01) lsb;

I'm not saying you should, just that it is possible ;-)

Regards,
Steven