Found a paper from David too...
http://www.research.ibm.com/people/d/dgrove/papers/cgo05.html
On 6/6/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Hi Rob,
>
> > From: Robert Lougher <[EMAIL PROTECTED]>
> > Date: Mon, 6 Jun 2005 14:58:45 +0100
>
> > > > One thing to
> > > > note is that a th
Hi Rob,
> From: Robert Lougher <[EMAIL PROTECTED]>
> Date: Mon, 6 Jun 2005 14:58:45 +0100
> > > One thing to
> > > note is that a threaded interpreter would see something like a 2-4x
> > > expansion over "normal" bytecodes when it converts from bytecodes to its
> > > internal form (arrays of func
Hi,
On 6/6/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Hi Dave,
>
> > From: David P Grove <[EMAIL PROTECTED]>
> >
> > One thing to
> > note is that a threaded interpreter would see something like a 2-4x
> > expansion over "normal" bytecodes when it converts from bytecodes to its
> > intern
Hi Dave,
> From: David P Grove <[EMAIL PROTECTED]>
> [EMAIL PROTECTED] wrote on 06/05/2005 10:48:29 PM:
>
> > - The machine code concatinating technique consumes much memory.
> > In my experience, generated machine code is about 10 times larger
> > than the original instructions in Java bytec
[EMAIL PROTECTED] wrote on 06/05/2005 10:48:29 PM:
> - The machine code concatinating technique consumes much memory.
> In my experience, generated machine code is about 10 times larger
> than the original instructions in Java bytecode.
>
> In the paper, the authors have not mentioned memory
Hi Steve and all,
| The approach of using C Compiler generated code rather than writing a
| full compiler appeals to me:
| http://www.csc.uvic.ca/~csc586a/papers/ertlgregg04.pdf
> From: Steve Blackburn <[EMAIL PROTECTED]>
> Date: Tue, 24 May 2005 21:08:05 +1000
> >>They automatically build thems
[EMAIL PROTECTED] wrote:
They automatically build themselves
simple JIT backends (by extracting fragments produced by the ahead of
time compiler). This sounds like a great way to achieve portability
while achiving better performance than a conventional interpreter.
I guess it's a bit bet
From: Steve Blackburn <[EMAIL PROTECTED]>
> > [EMAIL PROTECTED] wrote:
> >
> >> The approach of using C Compiler generated code rather than writing a
> >> full compiler appeals to me:
> >> http://www.csc.uvic.ca/~csc586a/papers/ertlgregg04.pdf
> >>
> >> I am curious on how well the approach perfor
Subject: Re: Other interesting papers and research
Other interesting things that can be achieved are some sorts of high
performance "tunning" aspects, which are very interesting, and using gcc
power might be more interesting than redoing it from scratch, either, at
t
Other interesting things that can be achieved are some sorts of high
performance "tunning" aspects, which are very interesting, and using gcc
power might be more interesting than redoing it from scratch, either, at
the begining of current project, or maybe forever.
An adequate "bundle" of gcc an
Archie Cobbs wrote:
[EMAIL PROTECTED] wrote:
The approach of using C Compiler generated code rather than writing a
full compiler appeals to me:
http://www.csc.uvic.ca/~csc586a/papers/ertlgregg04.pdf
I am curious on how well the approach performs compared to existing
JITs.
I'm admittedly bi
[EMAIL PROTECTED] wrote:
The approach of using C Compiler generated code rather than writing a
full compiler appeals to me:
http://www.csc.uvic.ca/~csc586a/papers/ertlgregg04.pdf
I am curious on how well the approach performs compared to existing JITs.
I'm admittedly biased, but the approach o
Thanks to the JAM post:
http://www.csc.uvic.ca/~csc586a/papers/index.html
in particular this:
http://www.csc.uvic.ca/~csc586a/papers/ertlgregg04.pdf
The approach of using C Compiler generated code rather than writing a
full compiler appeals to me:
http://www.csc.uvic.ca/~csc586a/papers/ertlgre
13 matches
Mail list logo
