Hello

Yes, and quite alot of them.
I think some are used to access DMA-related memory - but I see a couple of placements at 0x0c and such.

Some are indeed declared in header files.

Christian "BC" Svensson
Codelead Systems - http://www.codelead.se


On Sun, Jul 19, 2009 at 8:25 AM, Maarten Brock <sourceforge.brock@dse.nl> wrote:
Search for the keyword "at" that is used to absolutely locate variables.

Btw. the old linker did not have a means to indicate memory overlap.

> Hello.
>
> This may sound ridiculous but I'm not the original programmer and I have
> absolutely no idea if the program does use located bits. Can you give an
> example of how such code would look like?
>
> Basically I'm trying to mimic the original firmware using the newer
> compiler
> in hope that it will produce an output that works as well as the old
> firmware does. Maybe pack-iram has nothing to do with it, but it's an
> obvious thing I noted that is different.
>
> Greetings,
>
> Christian "BC" Svensson
> Codelead Systems - http://www.codelead.se
>
>
> On Sat, Jul 18, 2009 at 10:57 PM, Maarten Brock
> <sourceforge.brock@dse.nl>wrote:
>
>> Hi,
>>
>> Are you using absolutely located bits? And are they declared in multiple
>> source files (possibly through a .h file)?
>>
>> And why don't you like what --pack-iram gives?
>>
>> Maarten
>>
>>
>> > Hello.
>> >
>> > I'm trying to port an application to SDCC 2.9.0 from SDCC 2.3.8.
>> > Compiling using the old Makefile that is included works after adding a
>> > couple of #defines to correct some renamed registers.
>> > The firmware causes the unit to crash upon start in what looks like
>> memory
>> > corruption (e.g. characters like "[" are changed to "Ŕ").
>> >
>> > I have an old memory map that looks like this:
>> > Direct Internal RAM:
>> >    Name             Start    End      Size     Max
>> >    ---------------- -------- -------- -------- --------
>> >    REG_BANK_0       0x00     0x07         8        8
>> >    REG_BANK_1       0x08                  0        8
>> >    REG_BANK_2       0x10                  0        8
>> >    REG_BANK_3       0x18                  0        8
>> >    BSEG_BYTES       0x20     0x20         1       16
>> >    DATA             0x21     0x62        66      128
>> >    ---------------- -------- -------- -------- --------
>> >    TOTAL:           0x00     0x62        75      128
>> >
>> > Stack starts at: 0x63 (sp set to 0x62) with 157 bytes available
>> >
>> > Other memory:
>> >    Name             Start    End      Size     Max
>> >    ---------------- -------- -------- -------- --------
>> >    INDIRECT RAM     0x80                  0      128
>> >    EXTERNAL RAM     0x0000   0x07bb    1980    65536
>> >    ROM/EPROM/FLASH  0x0000   0xef90   61329    65536
>> >
>> > This made me conclude I need the --no-pack-iram option since my map
>> > generated by SDCC 2.9.0 is nowhere close to that.
>> > I'm hoping to be able to use the packing functionality later but for
>> now
>> > I've chosen to disable it.
>> > Adding the --no-pack-iram option makes the map look more reasonable -
>> it's
>> > correct in everything but the BSEG_BYTES segment is 2 bytes instead of
>> 1.
>> > This causes this error to arise:
>> >
>> > ?ASlink-Error-Internal memory overlap starting at 0x21.
>> >
>> > Is there a known change needed for this kind of error?
>> > Any help would be appreciated.
>> >
>> > Greetings,
>> >
>> > Christian "BC" Svensson
>> > Codelead Systems - http://www.codelead.se
>> >


------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user