6 ms·

I really liked this comment (by khoth): "And once we have standardised bytecode, the next logical step would presumably be to improve performance by creating CP

I really liked this comment (by khoth): "And once we have standardised bytecode, the next logical step would presumably be to improve performance by creating CPUs that can execute it directly. In 20 years we'll all be back where we started."

AndrewDucker 16y ago
I believe some work went on to produce a Java-running chip at one point. It proved better to compile down to whatever suited the chip best.
- iwr 16y ago
  In that sense, Intel is just making CPUs on top of x86 bytecode that runs natively. I wonder if a little extra firmware can eliminate the need for an OS altogether.
  - ori_b 16y ago
    If by "a little extra firmware", you mean "calling the OS firmware, and burning it into the CPU", then yes.
- gvb 16y ago
  There have been several JVM (without the "V") created[1]. None of them really caught on other than the ARM Jazelle[2], which isn't really a JM, it is more of a JVM accelerator: it has support for direct execution of many of the JVM opcodes. After investing lots of time and money into creating a JM, the companies were chagrined to find a general purpose processor with a good JVM (especially with JIT) could run circles around a direct-execution processor. [1] http://en.wikipedia.org/wiki/Java_processor http://en.wikipedia.org/wiki/Java_processor [2] http://en.wikipedia.org/wiki/Jazelle http://en.wikipedia.org/wiki/Jazelle
  - tiles 16y ago
    And that makes an excellent case for why JavaScript should simply be the bytecode of the future. x86 is gaudy and unsuited for many tasks--but it's where most of the speed innovation happens, thus it's the best platform for compiling other languages too. I'll propose an alternative, fix JavaScript by adding APIs like ByteArrays and shorts and a proper int to the language. Over time, JS could become an excellent IL. We can standardize on intermediate bytecode, but like all things in web adoption, it will probably be the path of least resistance that works. (Who would ever give HTML graphic, multimedia, and threading abilities?)
  - rquirk 16y ago
    I find it mildly amusing that the Android phone I use, an HTC Magic, has hardware acceleration for Java built in. Talk about a white elephant.
- mvgoogler 16y ago
  I think you're thinking of Azul (http://www.azulsystems.com/products/vega/arch http://www.azulsystems.com/products/vega/arch). They've been slowly withering away for the past couple of years (at least judging by the number of cars in their parking lot - I work in the building they are in). They just announced a cloud-based product based on their systems, so maybe there's still some life there.
  - wmf 16y ago
    Azul's Vega isn't really a Java processor; it's a generic RISC with a hardware-assisted read barrier.
praptak 16y ago
Everything old is new again: http://en.wikipedia.org/wiki/Lisp_machine http://en.wikipedia.org/wiki/Lisp_machine
stcredzero 16y ago
In 20 years we'll all be back where we started. Only if people forget the past. If the past is any indication, people will forget. What were we talking about again?
akeefer 16y ago
Talk to Cliff Click (or sift through his blog http://www.azulsystems.com/blogs/cliff http://www.azulsystems.com/blogs/cliff) and he will quickly disabuse you of the notion that having bytecode instructions in a processor is a good idea. For optimal performance you want a generic RISC-type processor with good hardware performance for critical things like read-barriers that the bytecode might require; you really don't want to design a processor that directly executes Java bytecode. There's a whole hell of a lot of optimization that gets done in the JIT layer besides just translating bytecode to machine code, and you want all that stuff to get done in software rather than trying to build it into your processor. Once you've done all that stuff, emitting actual assembly code isn't really the hard part, so you might as well just design a processor that you can make fast, give it a simple general-purpose instruction set, target that instruction set in your JIT, and then add a few special goodies as you need them for things that are really, really hard to do fast without specialized hardware support.

AndrewDucker 16y ago

I believe some work went on to produce a Java-running chip at one point. It proved better to compile down to whatever suited the chip best.

iwr 16y ago
In that sense, Intel is just making CPUs on top of x86 bytecode that runs natively. I wonder if a little extra firmware can eliminate the need for an OS altogether.
- ori_b 16y ago
  If by "a little extra firmware", you mean "calling the OS firmware, and burning it into the CPU", then yes.
gvb 16y ago
There have been several JVM (without the "V") created[1]. None of them really caught on other than the ARM Jazelle[2], which isn't really a JM, it is more of a JVM accelerator: it has support for direct execution of many of the JVM opcodes. After investing lots of time and money into creating a JM, the companies were chagrined to find a general purpose processor with a good JVM (especially with JIT) could run circles around a direct-execution processor. [1] http://en.wikipedia.org/wiki/Java_processor http://en.wikipedia.org/wiki/Java_processor [2] http://en.wikipedia.org/wiki/Jazelle http://en.wikipedia.org/wiki/Jazelle
- tiles 16y ago
  And that makes an excellent case for why JavaScript should simply be the bytecode of the future. x86 is gaudy and unsuited for many tasks--but it's where most of the speed innovation happens, thus it's the best platform for compiling other languages too. I'll propose an alternative, fix JavaScript by adding APIs like ByteArrays and shorts and a proper int to the language. Over time, JS could become an excellent IL. We can standardize on intermediate bytecode, but like all things in web adoption, it will probably be the path of least resistance that works. (Who would ever give HTML graphic, multimedia, and threading abilities?)
- rquirk 16y ago
  I find it mildly amusing that the Android phone I use, an HTC Magic, has hardware acceleration for Java built in. Talk about a white elephant.
mvgoogler 16y ago
I think you're thinking of Azul (http://www.azulsystems.com/products/vega/arch http://www.azulsystems.com/products/vega/arch). They've been slowly withering away for the past couple of years (at least judging by the number of cars in their parking lot - I work in the building they are in). They just announced a cloud-based product based on their systems, so maybe there's still some life there.
- wmf 16y ago
  Azul's Vega isn't really a Java processor; it's a generic RISC with a hardware-assisted read barrier.

praptak 16y ago

Everything old is new again: http://en.wikipedia.org/wiki/Lisp_machine http://en.wikipedia.org/wiki/Lisp_machine

stcredzero 16y ago

In 20 years we'll all be back where we started. Only if people forget the past. If the past is any indication, people will forget. What were we talking about again?

akeefer 16y ago

Talk to Cliff Click (or sift through his blog http://www.azulsystems.com/blogs/cliff http://www.azulsystems.com/blogs/cliff) and he will quickly disabuse you of the notion that having bytecode instructions in a processor is a good idea. For optimal performance you want a generic RISC-type processor with good hardware performance for critical things like read-barriers that the bytecode might require; you really don't want to design a processor that directly executes Java bytecode. There's a whole hell of a lot of optimization that gets done in the JIT layer besides just translating bytecode to machine code, and you want all that stuff to get done in software rather than trying to build it into your processor. Once you've done all that stuff, emitting actual assembly code isn't really the hard part, so you might as well just design a processor that you can make fast, give it a simple general-purpose instruction set, target that instruction set in your JIT, and then add a few special goodies as you need them for things that are really, really hard to do fast without specialized hardware support.