home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / compiler / 1294 < prev    next >
Encoding:
Text File  |  1992-07-30  |  3.0 KB  |  75 lines
  1. Newsgroups: comp.compilers
  2. Path: sparky!uunet!think.com!spdcc!iecc!compilers-sender
  3. From: macrakis@osf.org (Stavros Macrakis)
  4. Subject: Re: Software address translation - request for info
  5. Reply-To: macrakis@osf.org (Stavros Macrakis)
  6. Organization: OSF Research Institute
  7. Date: Thu, 30 Jul 1992 21:38:56 GMT
  8. Approved: compilers@iecc.cambridge.ma.us
  9. Message-ID: <92-07-115@comp.compilers>
  10. Keywords: architecture
  11. References: <92-07-104@comp.compilers>
  12. Sender: compilers-sender@iecc.cambridge.ma.us
  13. Lines: 60
  14.  
  15. phjk@doc.imperial.ac.uk (Paul H J Kelly) writes:
  16.  
  17.    We need a way of applying a non-trivial mapping to every data address
  18.    issued by a C program....:
  19.  
  20.     1) Post-process the assembler and intercept all loads and store
  21.        instructions.
  22.  
  23. A bad idea because you lose all the compiler's common-subexpression
  24. elimination and arithmetic simplifications (which should buy you a lot in
  25. this case).  But probably the easiest and most reliable on a load-store
  26. (RISC) architecture (where you don't have to decompile addressing modes
  27. etc.).  Don't forget computed jump addresses.
  28.  
  29.     2) modify the back end of a retargetable compiler (e.g. gcc) to
  30.        generate C instead of assembler, so we can then redefine
  31.        a couple of macros used in the generated C to change the mapping,
  32.  
  33. Huh?  Why generate C?  Anyway, doesn't work in general because the
  34. compiler may generate loads and stores that aren't visible to the user
  35. (e.g. register saving over procedure calls).  On the other hand, if you
  36. can avoid doing address translation on stack addresses, perhaps this will
  37. work.
  38.  
  39.     3) Write a front-end preprocessor, which modifies the C concrete or
  40.        abstract syntax to introduce the mapping,
  41.  
  42. Same problem as solution (2).  If what you really want is this address
  43. mapping facility ONLY on (so-called) static variables, then the best
  44. solution is probably this preprocessor.  In fact, you may be able to
  45. rewrite the static variables as macros (depending on what you do with
  46. them).
  47.  
  48.     4) Run standard binary as emitted by the C compiler, under a
  49.        simulator (e.g. spim) - then modify spim to perform address 
  50.        translation.
  51.  
  52. This will work fine, but will be very slow of course.
  53.  
  54. By the way, don't forget that ALL your libraries (including invisible ones
  55. like will also need to be recompiled or rewritten (if assembler).
  56.  
  57. Some other solutions:
  58.  
  59. 5) Do a transformation at intermediate-language level.  Again, you run the
  60. risk of `invisible' compiler operations coming in later (depending on the
  61. exact operation of the compiler and what you're doing about the stack).
  62.  
  63. 6) Rewrite the back end.  Probably the best solution....
  64.  
  65. By the way, you mention that addresses might change during execution.  In
  66. that case, your address calculations have to be done `safely' and can't be
  67. optimized away.  Probably solution (1) is best in this case, but you still
  68. need some way of guaranteeing that the address doesn't change halfway
  69. through an address calculation....
  70.  
  71.     -s
  72. -- 
  73. Send compilers articles to compilers@iecc.cambridge.ma.us or
  74. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  75.