----- Ursprüngliche Nachricht ----- Von: Chris Liechti Gesendet am: 20 Okt 2010 02:43:32
Am 19.10.2010 12:14, schrieb JMGross: >> Well, there IS an application where PIC is required (even if it can >> be solved using non-PIC code as well): If you need to place >> functions in RAM, but don't want to place them there permanently (by >> putting them into the data segment and hoping they will be there >> untouched ever after PUC). A prominent example is a flashing >> function, which is copied from flash to ram when needed. > in such cases, it's also a possibility to create a linker file and > compile the function separately for a location in RAM. then embed the > binary as byte array in the application. Sure, then it is linked to a certain (fixed) RAM location. And the procedure to handle it is not 'straight' and requires special handling in the build/flash process. It's a workaround, though. > however if you plan to move code at runtime, you have to ensure a few > other things than just position independent assembler for a function: > - you probably can not use any global variables. at least moving them by > the same offset as the code won't work. using absolute addresses would > keep the variables working, but do you really need the same variables > when the code runs from RAM and when it runs from Flash? Depends. If they are global, they are global and therefore a fixed address. The compiler dosn't make relative addressing of global variables anyway. Maybe the function (e.g. the flash function) needs the data from a buffer previously filled by the othe rcode in flash, or some other precalculated parameters or whatever. moving the address of variable because the code moved makes only sense if the data is local to the moved code and not used by the other fixed code. And then, why not allocating it on the stack? That's done everyday and works well, and continues to do so for fixed and moved code. No problem here. >- such a function also must not make calls to any other code that is not >moved. this includes support code that the compiler adds (libc, libgcc). >tha's important in the case of moving a function to RAM so that it can >erase the Flash for a software upgrade. compiling separately and >embedding as array like mentioned above helps in this case. Why not? Surely not with a normal function call, but the MSP supports indirect and indirect-indexed calls. This is already used when calling through fucntion pointers. A macro can be used to do it. No problem here too. Just a bit tweaking. >you would not want to have the entire application in position >independent code, as the MSP430 instruction set has no direct support to >do this very efficient. one of the issues is the "call" instruction >which takes the target address as absolute address in the form of an >immediate value. or in a register or indirect over a register or indexed by a register... Sure, the default compiler code generates immediate calls, but just changing the function call a bit (using function pointers) does the trick and is not much less efficient, if done right. Sure, the code cannot be written without any changes, but the changes are simple and easily done. ----- Ursprüngliche Nachricht ----- Von: Frédéric Sureau Gesendet am: 20 Okt 2010 03:18:26 > The fact that the CALL instruction is not able to use relative > addressing is a pretty big issue. Thanks for that precision. Not really. It requires a register or a global variable and then the call can be indirect, indexed or whatever. e.g. load the offset into a register and make the call indexed to the current location (PC). Works fine. Only a very small impact. The impact on using the MSP430X instruction compared to the old 430 instruction set is larger. JMGross ------------------------------------------------------------------------------ Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev _______________________________________________ Mspgcc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mspgcc-users ------------------------------------------------------------------------------ Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev _______________________________________________ Mspgcc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mspgcc-users
