Re: [avr-libc-dev] [task #3693] Add new devices: mega640-1280-1281-2560-2561

[Björn Haase]

Darcy Watkins wrote on Freitag, 16. September 2005 17:59 :
> Hi,
>
> I have a few comments (or perhaps rambling).
>
> I peeked at the wiki and notice that your proposed approach is to retain 16
> bit pointers but require functions to be on double word boundaries.
It is also my opinion that this is the best solution and, btw. , also the 
solution that is easiest and fastest to be implement, IMO.

I agree with Marek in that it would be best to insert the jump stubs by the 
linker: When using the linker one could avoid jump stubs for functions that 
the address is never taken of. This also would be the cleanest solution IMO.

When inserting jump stubs for all of the functions and when disabling the 
-mcall-prologue option for the >256k devices, one could, however, implement 
jump stubs as part of the prologue sequence. What one would be doing is:

Change the function prologue such that after the usual function entry label 
definition it 
1.) first inserts a jump to a function entry label that is the same as the 
usual label, however with a _upper_ prefix . 
2.) then inserts a ".section .upper_text" directive such that the following 
instructions (main body) will end up at a different section 
called .upper_text.
3.) define a second function entry label that corresponds to the usual one 
with a "_upper_" prefix before starting to emit the first of the prologue 
instruction.

Next thing to be done would be to make the call insn automatically add the 
_upper_ prefix before the label to call.

Remaining thing would be to make sure that one is linking all the text section 
within the lower 128k 

I think that I'll post a patch tomorrow that also implements RTL prologues 
instead of text. In only have to find a way for the prologue generator how 
the function entry label is called.

> Special care will be needed to avoid repeating the same type of bug as
> below that causes me grief while debugging my ATmega128 firmware that is
> greater than 64k bytes.
>
> [Bug target/19087] Overflowed address in dwarf debug line information
> ...
> The other problem I ran into while checking into bug 19087 was that when I
> patched and built up a set of tools to use 32 bit DWARF address
> representation (and Torleif provided me with some beta 32 bit DWARF parsers
> for AVRStudio), the 800000 style offsets used for data memory (and EEPROM),
> instead of being stripped off by rollover, were now present which caused
> other problems in AVR Studio.  Regardless of whatever is implemented, it
> will be necessary to adjust the section addresses at the last minute before
> generating the DWARF file for debugging.
This is, IMO, something that *really* should be managed by Thorleif. One could 
change the asm output for the dwarf2 lables easily by masking away the most 
significant byte during assembly time by adding a logical and with 
0x00FFFFFFL. This, however, would not be the bestsolution IMO, since I think 
it to be a good approach to contain the information on the memory space in 
the address itself. Mainly for possible future versions of gcc that include 
native support for harvard architectures.

I agree that one posssibly should change the size of the dwarf pointers to 4 
byte. One would need to sync this change with Atmel.

> Another challenge is that ISR vectors will have to be properly fixed up at
> link time.  There will need to be provision in the linker to fixup the
> extended jump / call instructions as the top half versus bottom half info
> won't be known until link time.
I don't see a difficulty there as long as we are using a call instruction or a 
jump instruction for entering the ISR.

> I think that we should "conceptually" view the program memory address space
> as 24 bits (even though we will only use 18 bits) and work in this realm
> for all the tools and then adjust addresses to the alternate formats at the
> very last minute.  It may prove best to use 24 bit pointers for runtime
> program memory references and allow optimization in the compiler and/or
> linker to use less expensive means whenever possible for compile and link
> time program memory references.
I think that this might be very difficult to implement.

> Regardless of the method used, a 24 bit (or at least an 18 bit)
> "conceptual" address space will be needed for DWARF debug information to
> prevent all debug information above 64k from overlaying the first 64k, (or
> other similar types of bugs).
As mentioned, my suggestion would be: Use 32 bit and teach the debugging tools 
to use the MSB as a marker in which memory space to look for the data.

> My guess is that the first task to get access to the first 128k of the
> ATmega256x devices will have the same limitations as with the ATmega128
> since it will mainly just deal with the 3 bytes on the stack.
Possibly. Depends a bit on Atmel and how difficult this would be to implement. 
As part of a temporary workaround one could use the automatic masking.

Yours,

Bjoern.