Re: Prediction of local code modifications

On Apr 8, 5:06 pm, Tim Frink <plfr...@yahoo.de> wrote:
> On Fri, 04 Apr 2008 18:23:56 -0400, George Neuner wrote:
>
> > It's been a while since I've done any DSP programming and I don't know
> > what chip you're using, but if your compiler can generate position
> > independent code, it will simplify your task greatly.
>
> I'm new to compilers but in my opinion the generation of position
> independent code is not possible for my DSP having problems with
> all these different misalignment issues. Or do you see a possibility
> to produce "stable" code which is not that sensitive to the position
> of the code fragments?


Hi Tim,


Sorry for the long delay - I've been traveling and haven't kept up.


Without PI code, you can't move code around without "relocating" it -
finding all the internal addresses references and patching them to
work at the new location. Properly relocated code will be "stable" by
your meaning, but it will take some work on your part to achieve it.


Most compilers targeting older DSPs produce a.out or COFF format
executables, which don't have relocation information (tables showing
the locations of addresses that need fixing if the code is moved from
its default address). Compilers for newer chips may produce an
executable that includes relocation tables (ELF, DWARF, etc.), but the
tables may be blank because the target is a DSP rather than a CPU.


Even if your compiler produces the information, you won't have access
to it at runtime - the tables will have been stripped by the program
loader, or if the code was ROM'd, they will not have been included.


You'll have to write your own relocator, working from assembly
listings and link maps. You need to identify all the internal static
data references and jump/branch targets, put together a fixup table
that contains pairs of offsets - e.g., to a jump instruction operand
and to the jump target - and write a little routine that copies the
code segment to its new location and then patches it using the fixup
table.


So if your code looks like


.code
    0x1000:
.start
          :
    0x1031: mov 0x11C2, reg0
    0x1034: jmp 0x1050
          :
    0x1120: jmp 0x10A2
          :
.end
.data
    0x11C0: word 0xCAFE, 0xBABE


you'll have a fixup table like:


    0x1000, 0x1C0 // location, length of code
    0x11C0, 0x004 // location, length of data
    0x032, 0x1C2 // fix location, target
    0x035, 0x050
    0x121, 0x0A2


When you copy the code to 0x8000, you go to 0x8000+0x035 and change
the jump target to 0x8000+0x050 ... and so on until all the addresses
have been fixed. If you move data as well, you need to fix any
references to it.


You'll need to figure out where the local static data lives. When you
write something like:


    int myfunc( ... )
    {
    int (*func[])( ... ) = { func1, func2, ... };
    char *name = "myfunc";
          :
    }


the pointer array and the string may end up packed with the globals or
may be placed in a private data segment depending on placement
directives, compiler options and the output executable format. If
they are in a private data segment, they may be placed adjacent to the
code in memory and you may wish to move them along with it. It's
easier if you don't move data because then you only need to handle
jumps, but you might want to if the difference in memory speeds is an
issue.


It sounds more complicated than it is - the main issue is figuring out
the relocation tables in the first place because they will have to be
bound into your relocator code. You may be able to get the compiler
to help you through debug options or by getting the relocation info
from an executable that has it.


Hope this helps.
George
IP is comcast net. User is gneuner2

Return to the comp.compilers page.
Search the comp.compilers archives again.