* [9fans] native dis status @ 2004-12-18 13:32 Patrick Kristiansen 2004-12-18 14:48 ` Latchesar Ionkov 0 siblings, 1 reply; 5+ messages in thread From: Patrick Kristiansen @ 2004-12-18 13:32 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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) ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [9fans] native dis status 2004-12-18 13:32 [9fans] native dis status Patrick Kristiansen @ 2004-12-18 14:48 ` Latchesar Ionkov 2004-12-18 17:24 ` Karl Magdsick 2004-12-18 23:28 ` Christopher Nielsen 0 siblings, 2 replies; 5+ messages in thread From: Latchesar Ionkov @ 2004-12-18 14:48 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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) ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [9fans] native dis status 2004-12-18 14:48 ` Latchesar Ionkov @ 2004-12-18 17:24 ` Karl Magdsick 2004-12-18 23:38 ` Christopher Nielsen 2004-12-18 23:28 ` Christopher Nielsen 1 sibling, 1 reply; 5+ messages in thread From: Karl Magdsick @ 2004-12-18 17:24 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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) > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [9fans] native dis status 2004-12-18 17:24 ` Karl Magdsick @ 2004-12-18 23:38 ` Christopher Nielsen 0 siblings, 0 replies; 5+ messages in thread From: Christopher Nielsen @ 2004-12-18 23:38 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [9fans] native dis status 2004-12-18 14:48 ` Latchesar Ionkov 2004-12-18 17:24 ` Karl Magdsick @ 2004-12-18 23:28 ` Christopher Nielsen 1 sibling, 0 replies; 5+ messages in thread From: Christopher Nielsen @ 2004-12-18 23:28 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2004-12-18 23:38 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-12-18 13:32 [9fans] native dis status Patrick Kristiansen 2004-12-18 14:48 ` Latchesar Ionkov 2004-12-18 17:24 ` Karl Magdsick 2004-12-18 23:38 ` Christopher Nielsen 2004-12-18 23:28 ` Christopher Nielsen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).