From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Sat, 18 Dec 2004 12:24:16 -0500 From: Karl Magdsick To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] native dis status In-Reply-To: <20041218144827.GB17518@ionkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41C43188.6000405@0x960.net> <20041218144827.GB17518@ionkov.net> Topicbox-Message-UUID: 1aa51810-eace-11e9-9e20-41e7f4b1d025 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) >