Re: Software address translation - request for info

phjk@doc.imperial.ac.uk (Paul H J Kelly) writes:


      We need a way of applying a non-trivial mapping to every data address
      issued by a C program....:


        1) Post-process the assembler and intercept all loads and store
              instructions.


A bad idea because you lose all the compiler's common-subexpression
elimination and arithmetic simplifications (which should buy you a lot in
this case). But probably the easiest and most reliable on a load-store
(RISC) architecture (where you don't have to decompile addressing modes
etc.). Don't forget computed jump addresses.


        2) modify the back end of a retargetable compiler (e.g. gcc) to
              generate C instead of assembler, so we can then redefine
              a couple of macros used in the generated C to change the mapping,


Huh? Why generate C? Anyway, doesn't work in general because the
compiler may generate loads and stores that aren't visible to the user
(e.g. register saving over procedure calls). On the other hand, if you
can avoid doing address translation on stack addresses, perhaps this will
work.


        3) Write a front-end preprocessor, which modifies the C concrete or
              abstract syntax to introduce the mapping,


Same problem as solution (2). If what you really want is this address
mapping facility ONLY on (so-called) static variables, then the best
solution is probably this preprocessor. In fact, you may be able to
rewrite the static variables as macros (depending on what you do with
them).


        4) Run standard binary as emitted by the C compiler, under a
              simulator (e.g. spim) - then modify spim to perform address
              translation.


This will work fine, but will be very slow of course.


By the way, don't forget that ALL your libraries (including invisible ones
like will also need to be recompiled or rewritten (if assembler).


Some other solutions:


5) Do a transformation at intermediate-language level. Again, you run the
risk of `invisible' compiler operations coming in later (depending on the
exact operation of the compiler and what you're doing about the stack).


6) Rewrite the back end. Probably the best solution....


By the way, you mention that addresses might change during execution. In
that case, your address calculations have to be done `safely' and can't be
optimized away. Probably solution (1) is best in this case, but you still
need some way of guaranteeing that the address doesn't change halfway
through an address calculation....


-s
--

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