[9fans] native dis status

[9fans] native dis status

[Patrick Kristiansen]

What is the current status of native plan 9 dis?
Is anybody working on it?

I have downloaded it and played a little with it. One of the only 
graphical program I could run was tetris, but I couldn't play because it 
doesn't respond to pressing keys.
(No, i'm not only interrested in playing tetris on plan 9, but I would 
be glad to see charon natively on plan9)

Re: [9fans] native dis status

[Latchesar Ionkov]

I am not aware of anybody working on it. The version on Andrey's site is
slightly older than the one I have. With the latest one you can really play
tetris :) In addition to working mouse and keyboard input, it implements the
Inferno #P device (without debug at the moment) as Plan9 fileserver. So sh
is also working.

When I started my plan was to make dis compatible enough to run charon
without major changes in it, or the wm* code. That would require
implementing at least #P and #s, probably other Inferno devices too. Right
now I am not sure if it is worth the extra work for keeping the
compatibility. It might be easier to implement the (most) #P functionality
as a module, implementing some simpler form of wm on top of rio, and
modifying charon to work with it.

I didn't play with dis for the last six months, and I don't know when I'll
start playing with it again. Probably when I decide which path to take --
implementing Inferno devices as Plan9 fs, or getting rid of the dependency
on them.

Thanks,
	Lucho

On Sat, Dec 18, 2004 at 02:32:56PM +0100, Patrick Kristiansen said:
> What is the current status of native plan 9 dis?
> Is anybody working on it?
> 
> I have downloaded it and played a little with it. One of the only 
> graphical program I could run was tetris, but I couldn't play because it 
> doesn't respond to pressing keys.
> (No, i'm not only interrested in playing tetris on plan 9, but I would 
> be glad to see charon natively on plan9)

Re: [9fans] native dis status

[Karl Magdsick]

What is the source code license for Dis?

(On a side note, is stand-alone Inferno available for free download
anywhere?  ... Preferably for MIPS-64... but x86 will due.)  I don't
suppose there is a build of the current Plan 9 for big-endian MIPS-64
hiding in a closet somewhere... I have an SGI Indy hiding on my closet
floor.

Has anyone seen a compiler to compile Java source code to Dis VM code?
 It would be interesting to see the speed differences.

[Stop reading here if you're not interested in virtual machine internals.]

I read an interesting paper written by a group of researchers that
took the Jikes RVM (IBM's open-source JIT Java VM) and added
functionality to allow it to JIT-compile both Java bytecode (refered
to in the paper as Java Virtual Machine Language, or JVML) class files
and SafeTSA (a type of Static Single Assignment representation that
still supports all of Java's type safety) class files.  They also
wrote their own compiler to compile Java source code to SafeTSA class
files.  They were even able to run programs that contained a mixture
of the two class file types.  They then compiled the Java Grande
standard benchmark suite into both JVML and SafeTSA.

The SafeTSA versions of the benchmarks showed performance increases
ranging from -16% to +250%, averaging 33% performance gain.  The
performance losses were due to not modifying the standard Jikes RVM
JIT later stages.  The Jikes RVM's linear scan register allocation
scheme interected poorly with the low-level intermediate language spit
out by the SafeTSA-specific JIT stages.  Had the researchers been
willing to tweak the later stages of the standard Jikes RVM JIT, they
would likely have seen the SafeTSA benchmarks all run at least as fast
as the JVML benchmarks.  They also showed a 19% reduction in time 
spent in the JIT compiler.

In any case, this research backs up the statements made in the Dis
design paper about stack-machine-based bytecodes (which can be thought
of as using 2 registers... the top 2 elements of the stack) being
inherently less well suited to JIT compiling than memory-machine-based
bytecodes (which effectively have an infinite number of registers...
or at least the entire memory space full of registers) such as those
used by Dis.  SafeTSA and other SSA representations effectively have
an infinite number of registers and could be thought of as very
restricted memory-machine-based representations.

Anyway, I hate to see people write off virtual machines based on the
performance of intermediate languages that were originally intended to
be able to be interpreted on 8-bit micropossors embedded in toasters
and refrigerators.  Dis and Parrot are the only VMs I'm aware of that
are designed from the beginning to be JIT compiled on more capable
hardware.  (Microsoft's .NET CLR grew out of MS's significant
investement in Java/J++ before the courts told them that they could
not "embrace and extend"/haijack Java.  The technology got a
significant facelift, but underneath, it's still technology designed
to sqeeze speed out of a code representation designed for toasters and
refrigerators.)


-Karl

On Sat, 18 Dec 2004 09:48:27 -0500, Latchesar Ionkov <lucho@gmx.net> wrote:
> I am not aware of anybody working on it. The version on Andrey's site is
> slightly older than the one I have. With the latest one you can really play
> tetris :) In addition to working mouse and keyboard input, it implements the
> Inferno #P device (without debug at the moment) as Plan9 fileserver. So sh
> is also working.
> 
> When I started my plan was to make dis compatible enough to run charon
> without major changes in it, or the wm* code. That would require
> implementing at least #P and #s, probably other Inferno devices too. Right
> now I am not sure if it is worth the extra work for keeping the
> compatibility. It might be easier to implement the (most) #P functionality
> as a module, implementing some simpler form of wm on top of rio, and
> modifying charon to work with it.
> 
> I didn't play with dis for the last six months, and I don't know when I'll
> start playing with it again. Probably when I decide which path to take --
> implementing Inferno devices as Plan9 fs, or getting rid of the dependency
> on them.
> 
> Thanks,
>         Lucho
> 
> On Sat, Dec 18, 2004 at 02:32:56PM +0100, Patrick Kristiansen said:
> > What is the current status of native plan 9 dis?
> > Is anybody working on it?
> >
> > I have downloaded it and played a little with it. One of the only
> > graphical program I could run was tetris, but I couldn't play because it
> > doesn't respond to pressing keys.
> > (No, i'm not only interrested in playing tetris on plan 9, but I would
> > be glad to see charon natively on plan9)
>

Re: [9fans] native dis status

[Christopher Nielsen]

When I asked you about it, my intent was to start
actively working on it. I haven't had a chance to get
started yet, but I still intend to push the ball
forward.

Can you make available the newer version?

I can throw it up in my directory on sources and use
that as a repository for folks that want to work on
it.

On Sat, Dec 18, 2004 at 09:48:27AM -0500, Latchesar Ionkov wrote:
> I am not aware of anybody working on it. The version on Andrey's site is
> slightly older than the one I have. With the latest one you can really play
> tetris :) In addition to working mouse and keyboard input, it implements the
> Inferno #P device (without debug at the moment) as Plan9 fileserver. So sh
> is also working.
> 
> When I started my plan was to make dis compatible enough to run charon
> without major changes in it, or the wm* code. That would require
> implementing at least #P and #s, probably other Inferno devices too. Right
> now I am not sure if it is worth the extra work for keeping the
> compatibility. It might be easier to implement the (most) #P functionality
> as a module, implementing some simpler form of wm on top of rio, and
> modifying charon to work with it.
> 
> I didn't play with dis for the last six months, and I don't know when I'll
> start playing with it again. Probably when I decide which path to take --
> implementing Inferno devices as Plan9 fs, or getting rid of the dependency
> on them.
> 
> Thanks,
> 	Lucho
> 
> On Sat, Dec 18, 2004 at 02:32:56PM +0100, Patrick Kristiansen said:
> > What is the current status of native plan 9 dis?
> > Is anybody working on it?
> > 
> > I have downloaded it and played a little with it. One of the only 
> > graphical program I could run was tetris, but I couldn't play because it 
> > doesn't respond to pressing keys.
> > (No, i'm not only interrested in playing tetris on plan 9, but I would 
> > be glad to see charon natively on plan9)
> 

-- 
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] native dis status

[Christopher Nielsen]

Your comments on stack-machine-based bytecodes reminds
me of a conversation I had about java with a professor
during the .com boom in the Bay Area. His opinion was
that using a stack machine was inane, and he thought
there was at least a masters thesis in it for anyone
that re-implemented the jvm as a register machine.

Limbo is a better language, and as much as I have
actually had to code in java, I still find it
cumbersome and in-elegant.

On Sat, Dec 18, 2004 at 12:24:16PM -0500, Karl Magdsick wrote:
> What is the source code license for Dis?
> 
> (On a side note, is stand-alone Inferno available for free download
> anywhere?  ... Preferably for MIPS-64... but x86 will due.)  I don't
> suppose there is a build of the current Plan 9 for big-endian MIPS-64
> hiding in a closet somewhere... I have an SGI Indy hiding on my closet
> floor.
> 
> Has anyone seen a compiler to compile Java source code to Dis VM code?
>  It would be interesting to see the speed differences.
> 
> [Stop reading here if you're not interested in virtual machine internals.]
> 
> I read an interesting paper written by a group of researchers that
> took the Jikes RVM (IBM's open-source JIT Java VM) and added
> functionality to allow it to JIT-compile both Java bytecode (refered
> to in the paper as Java Virtual Machine Language, or JVML) class files
> and SafeTSA (a type of Static Single Assignment representation that
> still supports all of Java's type safety) class files.  They also
> wrote their own compiler to compile Java source code to SafeTSA class
> files.  They were even able to run programs that contained a mixture
> of the two class file types.  They then compiled the Java Grande
> standard benchmark suite into both JVML and SafeTSA.
> 
> The SafeTSA versions of the benchmarks showed performance increases
> ranging from -16% to +250%, averaging 33% performance gain.  The
> performance losses were due to not modifying the standard Jikes RVM
> JIT later stages.  The Jikes RVM's linear scan register allocation
> scheme interected poorly with the low-level intermediate language spit
> out by the SafeTSA-specific JIT stages.  Had the researchers been
> willing to tweak the later stages of the standard Jikes RVM JIT, they
> would likely have seen the SafeTSA benchmarks all run at least as fast
> as the JVML benchmarks.  They also showed a 19% reduction in time 
> spent in the JIT compiler.
> 
> In any case, this research backs up the statements made in the Dis
> design paper about stack-machine-based bytecodes (which can be thought
> of as using 2 registers... the top 2 elements of the stack) being
> inherently less well suited to JIT compiling than memory-machine-based
> bytecodes (which effectively have an infinite number of registers...
> or at least the entire memory space full of registers) such as those
> used by Dis.  SafeTSA and other SSA representations effectively have
> an infinite number of registers and could be thought of as very
> restricted memory-machine-based representations.
> 
> Anyway, I hate to see people write off virtual machines based on the
> performance of intermediate languages that were originally intended to
> be able to be interpreted on 8-bit micropossors embedded in toasters
> and refrigerators.  Dis and Parrot are the only VMs I'm aware of that
> are designed from the beginning to be JIT compiled on more capable
> hardware.  (Microsoft's .NET CLR grew out of MS's significant
> investement in Java/J++ before the courts told them that they could
> not "embrace and extend"/haijack Java.  The technology got a
> significant facelift, but underneath, it's still technology designed
> to sqeeze speed out of a code representation designed for toasters and
> refrigerators.)
> 
> 
> -Karl
> 
> On Sat, 18 Dec 2004 09:48:27 -0500, Latchesar Ionkov <lucho@gmx.net> wrote:
> > I am not aware of anybody working on it. The version on Andrey's site is
> > slightly older than the one I have. With the latest one you can really play
> > tetris :) In addition to working mouse and keyboard input, it implements the
> > Inferno #P device (without debug at the moment) as Plan9 fileserver. So sh
> > is also working.
> > 
> > When I started my plan was to make dis compatible enough to run charon
> > without major changes in it, or the wm* code. That would require
> > implementing at least #P and #s, probably other Inferno devices too. Right
> > now I am not sure if it is worth the extra work for keeping the
> > compatibility. It might be easier to implement the (most) #P functionality
> > as a module, implementing some simpler form of wm on top of rio, and
> > modifying charon to work with it.
> > 
> > I didn't play with dis for the last six months, and I don't know when I'll
> > start playing with it again. Probably when I decide which path to take --
> > implementing Inferno devices as Plan9 fs, or getting rid of the dependency
> > on them.
> > 
> > Thanks,
> >         Lucho
> > 
> > On Sat, Dec 18, 2004 at 02:32:56PM +0100, Patrick Kristiansen said:
> > > What is the current status of native plan 9 dis?
> > > Is anybody working on it?
> > >
> > > I have downloaded it and played a little with it. One of the only
> > > graphical program I could run was tetris, but I couldn't play because it
> > > doesn't respond to pressing keys.
> > > (No, i'm not only interrested in playing tetris on plan 9, but I would
> > > be glad to see charon natively on plan9)
> >
> 

-- 
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin