Re: [9fans] native dis status

[Christopher Nielsen <cnielsen@pobox.com>]

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