Related articles |
---|
Requirements for Just-in-time Compilation jp@demonseed.net (jason petrone) (2001-04-22) |
Re: Requirements for Just-in-time Compilation at150bogomips@aol.com (2001-04-26) |
Re: Requirements for Just-in-time Compilation ralph@inputplus.demon.co.uk (2001-04-26) |
Re: Requirements for Just-in-time Compilation vbdis@aol.com (2001-04-26) |
Re: Requirements for Just-in-time Compilation jp@demonseed.net (jason petrone) (2001-04-29) |
Re: Requirements for Just-in-time Compilation Brian.Inglis@SystematicSw.ab.ca (2001-04-30) |
From: | ralph@inputplus.demon.co.uk (Ralph Corderoy) |
Newsgroups: | comp.compilers |
Date: | 26 Apr 2001 21:09:20 -0400 |
Organization: | InputPlus Ltd. |
References: | 01-04-120 |
Keywords: | practice |
Posted-Date: | 26 Apr 2001 21:09:20 EDT |
Hi,
> 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?
http://www.eecs.harvard.edu/~nr/toolkit/
> 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,
no?
> 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.
Ralph.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.