|Requirements for Just-in-time Compilation email@example.com (jason petrone) (2001-04-22)|
|Re: Requirements for Just-in-time Compilation firstname.lastname@example.org (2001-04-26)|
|Re: Requirements for Just-in-time Compilation email@example.com (2001-04-26)|
|Re: Requirements for Just-in-time Compilation firstname.lastname@example.org (2001-04-26)|
|Re: Requirements for Just-in-time Compilation email@example.com (jason petrone) (2001-04-29)|
|Re: Requirements for Just-in-time Compilation Brian.Inglis@SystematicSw.ab.ca (2001-04-30)|
|From:||firstname.lastname@example.org (Ralph Corderoy)|
|Date:||26 Apr 2001 21:09:20 -0400|
|Posted-Date:||26 Apr 2001 21:09:20 EDT|
> Since speed of compilation is an issue, should the compiler also do
> machine code generation?
Yes, an external assembler pass would be too slow. Is anyone using the
New Jersey Machine-Code Toolkit as part of a JIT or dynarec?
> Also, is making such a compiler retargetable a lofty goal? It seems
> to me that supporting multiple architectures would require making
> extra passes, and would slow things down.
Why extra passes? A different backend would be used per architecture,
> I've been reading papers and source code, but I still feel that I am
> lacking a clear understanding of the real issues involved in writing
> such a compiler.
Some more for you to read could be found at www.dynarec.com. They're
interested in dynamic re-compilation where machine instructions from
one architecture are converted on the fly to another. Sometimes an
intermediate format is used.
Return to the
Search the comp.compilers archives again.