From Multimedia Futures, a sister publication
Is Sun’s idea of producing Java-specific processor an excellent or a terrible idea? Chris Rowen, the director of Silicon Graphic’s European Core Technology Group thinks a the strategy is problematic in a number of ways. Although SGI is a competitor of Sun Microsystems, Rowen’s points are more than sour grapes. He argues that not only is Java a terrible architecture to try and implement in Silicon, he also points out that the strategy of closely linking programming languages to processors has been tried before with little success. On the technical side here are his objections: 1. Very very little Java code exists in the world today, and even on a dedicated Internet machine, much much more time will be spent running the kernel, the window interface, the graphics subsystem, the network protocols and basic HTML interpretation. A Java processor will actually be a detriment in these circumstances, compared to a an optimized, high-volume, raw- performance-driven RISC. 2. Java is a good software architecture, but a TERRIBLE processor architecture – much worse than x86. To implement Java in hardware (with hardware objects, garbage collection, byte- coded instructions) takes computer architecture back 16 years, to Intel’s ill-fated 432 project. They will find it very hard indeed to build truly fast processors to execute Java directly. 3.The one clear architectural advantage of the Java byte-code format is that it is very compact – clearly a good thing in a model where you download software on each use. Once however, you get that code into local memory, or into cache, it become much more desirable to expand it into a format, a la RISC, which is much easier for the processor to decode and execute, especially since code in the inner loops will get executed millions of times before being discarded and downloaded again. Any hardware strategy that significantly increases the instruction decode time or complexity to save a bit of static code density, is not a good long-term tradeoff. The whole effort, Rowen says, reminds him of projects in the late 70’s and early 80’s to put LISP on a chip (MIT) or Berkeley’s attempt to build SmallTalk-specific processors. Rowen’s contention is that the industry has already decided once against the approach and will probably do so again: the computer architecture community ultimately concluded that compiler technology moves too fast, that software patterns have too much tendency to evolve, and that underlying VLSI technology moves to fast for anyone to successfully freeze the relationship between the programming language and the chip implementation. While he acknowledges that it some hardware support might be desirable to accelerate some of the nastier memory management questions that come from Java’s security, memory management and garbage collection schemes, these memory management features, however, are largely independent of the user-level instruction set, and might easily be incorporated into most existing, simpler processor definitions (RISC or x86) he says. Rowen’s lucid demolition-job came in response to our question, When Silicon Graphics decided to license Java, did it know that Sun had a Java processor up its sleeve? to which he answers that he, at least did not know about Sun’s specific plans: If I had known, it would not have affected a decision I would make. This is a pretty natural position to take, since I think that Java processors, at least for the next few years, will be a non-event,. Finally, for those in the MIPs camp seeking solace, Rowen suggests that the silicon Java project could bleed valuable skills and focus from Sun’s Sparc operation. Let battle commence.
Content from our partners
