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. 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 What I observe is that the line number info for the code greater than 64k is associated with code in the bottom 64k after a 16 bit rollover. To work around this, you have to keep the debugged application in the bottom 64k and then anything in the top 64k should have debug info stripped (usually libraries, etc). With the ATmega256x, references to program memory for data access will be 18 bits, the word addressing pointers used for function calls and indirect calls will effectively be 17 bits. These all need to be properly mapped to/from 16 bit double word boundary pointers. 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. For indirect calls, it will be necessary to take the 16 bit value, extract the one bit used to determine top versus bottom half, adjust the rest of the vector, and then make the call using the appropriate instruction as determined by the extracted bit. Now for program memory stored data (assuming the same 4 byte alignment scheme), it is similar except that now you use 2 bits for the RAMPZ and adjust the remaining 14 bits. 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. 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). 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. 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. I suppose it may be possible to implement an indirect jump hack by pushing a three byte fake "return" address on the stack and then invoking the "return" instruction to do the jump. A scary hack but it may work. For an indirect call hack, you would have to push the real return address and then the fake return address and then use "return" to the called routine at the fake return address. Then it would use a normal "return" to the real return location when done. Regards, Darcy -------------------------------------------------------------- Darcy L. Watkins email: [EMAIL PROTECTED] Senior Software Developer++ phone: (604) 455-2000 TASC Systems, Inc. fax: (604) 888-2712 9415 - 202 Street, web: http://www.tascsystems.com Langley B.C. Canada V1M 4B5 -------------------------------------------------------------- -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Uwe Fechner Sent: Friday, September 16, 2005 6:53 AM To: [EMAIL PROTECTED]; Eric Weddington; Marek Michalkiewicz; Anatoly Sokolov; Uwe Fechner; [email protected] Subject: [avr-libc-dev] [task #3693] Add new devices: mega640-1280-1281-2560-2561 Follow-up Comment #8, task #3693 (project avr-libc): I created a wiki page to log the effort in implementing support for AT mega2560/AT mega2561. Look at: http://www.kieltech.de/uweswiki/ATmega2560_5fsupport I tried to break the main task into subtasks, to make it easier to start. _______________________________________________________ Reply to this item at: <http://savannah.nongnu.org/task/?func=detailitem&item_id=3693> _______________________________________________ Nachricht geschickt von/durch Savannah http://savannah.nongnu.org/ _______________________________________________ AVR-libc-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-libc-dev _______________________________________________ AVR-libc-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
