On Tue, Feb 26, 2002 at 11:15:59AM -0800, Hong Zhang wrote:
> > >The KVM of Java includes pre-verify info, which serves similar purpose.
> The
> > >reason behind is Java bytecode verification is (kind of) NP-complete. By
> > >using pre-verify info, the problem can be reduced to linear in most case
> >The KVM of Java includes pre-verify info, which serves similar purpose.
The
> >reason behind is Java bytecode verification is (kind of) NP-complete. By
> >using pre-verify info, the problem can be reduced to linear in most case.
(No one
> >prove it mathmatically, but you got the idea.)
>
> Hmm
I have been concerned with the current parrot design for some time.
I don't see the clear direction for parrot.
If a vm is designed for JIT, it can be very simple on opcode system.
To real compilers, there is no difference between opcodes and regular
function calls. The compiler can inline the
At 10:30 AM -0800 2/26/02, Hong Zhang wrote:
> > >That's (potentially) an awfully big table. But maybe I'm missing the
>point.
>> >If we're not trusting the bytecode to be safe, and this table is part of
>the
>> >bytecode, how do we know the table is safe?
>>
>> We vet the table at load time
> >That's (potentially) an awfully big table. But maybe I'm missing the
point.
> >If we're not trusting the bytecode to be safe, and this table is part of
the
> >bytecode, how do we know the table is safe?
>
> We vet the table at load time to make sure it's safe. That way we
> avoid the cost of
At 8:47 PM -0500 2/23/02, Bryan C. Warnock wrote:
>On Saturday 23 February 2002 20:31, Dan Sugalski wrote:
>> Well, what I was thinking was we could have a section that marked all
>> the legitimate jump destinations. We could then vet this destination
>> table at load time for safe interpreters
On Saturday 23 February 2002 20:31, Dan Sugalski wrote:
> Well, what I was thinking was we could have a section that marked all
> the legitimate jump destinations. We could then vet this destination
> table at load time for safe interpreters to make sure that the
> destinations really were proper
At 6:59 PM -0500 2/23/02, Bryan C. Warnock wrote:
>On Saturday 23 February 2002 13:12, Dan Sugalski wrote:
>> We also need a PDD for the bytecode file format.
>
>Halfway converted. Er, quarterway, maybe.
Cool.
> > I also want all the potential jump destinations to be marked
>> somewhere for
On Sat, 2002-02-23 at 13:12, Dan Sugalski wrote:
> At 12:22 PM -0500 2/23/02, Melvin Smith wrote:
> >At 11:53 AM 2/23/2002 +, Simon Cozens wrote:
> >>I was very lucky recently to attend a talk by Ganesh Sittampalam
> >>introducing Microsoft .NET and the Common Language Runtime. A lot of
> >>wh
On Saturday 23 February 2002 13:12, Dan Sugalski wrote:
> We also need a PDD for the bytecode file format.
Halfway converted. Er, quarterway, maybe.
> I also want all the potential jump destinations to be marked
> somewhere for the safe mode interpreter, which is another section in
> the byteco
At 12:22 PM -0500 2/23/02, Melvin Smith wrote:
>At 11:53 AM 2/23/2002 +, Simon Cozens wrote:
>>I was very lucky recently to attend a talk by Ganesh Sittampalam
>>introducing Microsoft .NET and the Common Language Runtime. A lot of
>>what CLR is trying to do is quite similar to what we're doing
At 11:53 AM 2/23/2002 +, Simon Cozens wrote:
>I was very lucky recently to attend a talk by Ganesh Sittampalam
>introducing Microsoft .NET and the Common Language Runtime. A lot of
>what CLR is trying to do is quite similar to what we're doing with
>Parrot, so I thought it would be a good idea
I was very lucky recently to attend a talk by Ganesh Sittampalam
introducing Microsoft .NET and the Common Language Runtime. A lot of
what CLR is trying to do is quite similar to what we're doing with
Parrot, so I thought it would be a good idea to briefly recap what's
going on with CLR.
The CLR
13 matches
Mail list logo