From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sat, 18 Dec 2004 15:38:09 -0800 From: Christopher Nielsen To: 9fans@cse.psu.edu Subject: Re: [9fans] native dis status Message-ID: <20041218233809.GF44345@cassie.foobarbaz.net> References: <41C43188.6000405@0x960.net> <20041218144827.GB17518@ionkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i Topicbox-Message-UUID: 1ab80114-eace-11e9-9e20-41e7f4b1d025 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 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