|melting ice technology? email@example.com (1992-07-01)|
|Re: melting ice technology? firstname.lastname@example.org (Raphael Manfredi) (1992-07-02)|
|Re: melting ice technology? email@example.com (1992-07-06)|
|From:||firstname.lastname@example.org (Cliff Click)|
|Date:||Mon, 6 Jul 1992 16:12:37 GMT|
>Stephane Barbey wrote in comp.compilers:
>>What is the "melting ice" compiling technology ? Could someone post any
>>info/bibliography on that subject ?
>The "melting ice" technology is something we have developped here at ISE
>for our Eiffel 3 compiler. Briefly, here is how it works:
...nifty discussion deleted...
We used something similar in developing a Postscript clone. We had LOTS
of EPROM space (just drop the fonts out during development) but limited
RAM space (needed RAM for bitmaps, executing Postscript, etc).
So we burned the source code, compiled executable, editor and compiler
into the EPROM on the RIP (Raster Image Processor - 68K based + weirdo
During development we could edit source for a module on the RIP, compile
new code for just that module, and link it with the EPROM'd executables
for everything else. We kept in RAM just the edited module and it's
executable image. When we got low on RAM space, we burned all the changes
into a new set of EPROMs.
Linking was done by making all the subroutine calls go through an extra
jump table stored in RAM; i.e. An EPROM'd subroutine call really called
the jump table, which then jumped to the actually address. After
compiling some code to a new address, you patched it's new address into
the jump table. Voila! Linking is done.
This made for very quick turnaround times (compile a single module &
re-link took << 1 sec); then the code could be re-run immediately.
Crashed the RIP? No problem - hit the reset button, and be back in the
editor in < 1 sec.
Naturally, we stripped out the indirect jump table, editor, compiler, and
source code in systems that shipped :-).
Return to the
Search the comp.compilers archives again.