Related articles |
---|
On-the-fly compilation from VM code to machine code joe@erix.ericsson.se (1994-08-24) |
Re: On-the-fly compilation from VM code to machine code thomasl@groucho.csd.uu.se (1994-08-26) |
Re: On-the-fly compilation from VM code to machine code danhicks@aol.com (1994-08-27) |
Re: On-the-fly compilation from VM code to machine code hbaker@netcom.com (1994-09-07) |
Re: On-the-fly compilation from VM code to machine code engler@AMSTERDAM.LCS.MIT.EDU (1994-09-07) |
Re: On-the-fly compilation from VM code to machine code hoelzle@xenon.stanford.edu (1994-09-14) |
Re: On-the-fly compilation from VM code to machine code danhicks@aol.com (1994-09-09) |
Re: On-the-fly compilation from VM code to machine code pardo@cs.washington.edu (1994-09-16) |
Newsgroups: | comp.compilers |
From: | danhicks@aol.com (DanHicks) |
Keywords: | interpreter, optimize |
Organization: | America Online, Inc. (1-800-827-6364) |
References: | 94-09-007 |
Date: | Fri, 9 Sep 1994 02:24:04 GMT |
(Dawson R. Engler) writes:
>>>>>>>
> The problem with this is that you can't optimize RISC code "on the fly".
> The efficiency of the code generated would be little better than what
>you could do with an interpreter.
I'm not sure what this means. You certainly can generate
optimized
RISC code "on the fly", and the result is substantially better than what
you could do with an interpreter. See a paper that Todd Proebsting and
I wrote:
<<<<<<<
The problem is that RISC code optimization is so time-consuming. Without
register allocation and scheduling RISC processors run at vastly reduced
speed (perhaps 1/10 of optimal). One can sometimes do a passable job of
register allocation with a relatively clumsy but efficient algorithm
(though loops would suffer greatly), but scheduling is more difficult and
time-consuming. And, of course, the time-consuming nature of all of this
conflicts with the desire to do it "on the fly" -- you end up spending
much more time compiling than executing.
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.