On 12/17/2012 3:27 PM, Denis Koroskin wrote:
On Mon, 17 Dec 2012 13:47:36 -0800, Walter Bright <newshou...@digitalmars.com>
wrote:
I've often thought Java bytecode was a complete joke. It doesn't deliver any
of its promises. You could tokenize Java source code, run the result through
an lzw compressor, and get the equivalent functionality in every way.
Not true at all. Bytecode is semi-optimized,
I'm not unaware of that, recall I wrote a Java compiler. The "semi-optimized" is
generous. The bytecode simply doesn't allow for any significant optimization.
easier to manipulate with (obfuscate, instrument, etc),
The obfuscators for bytecode are ineffective. It's probably marginally easier to
instrument, but adjusting a Java compiler to emit instrumented code is just as easy.
JVM/CLR bytecode is shared by many languages
(Java, Scala/C#,F#) so you don't need a separate parser for each language,
That's true. But since there's a 1:1 correspondence between bytecode and Java,
you can just as easily emit Java from your backend.
and there is hardware that supports running JVM bytecode on the metal.
There's a huge problem with that approach. Remember I said that bytecode can't
be more than trivially optimized? In hardware, there's no optimization, so it's
going to be doomed to slow optimization. Even a trivial JIT will beat it, and if
you go beyond basic code generation to using a real optimizer, that will beat
the pants off of any hardware bytecode machine.
Which is why such machines have not caught on. It's the wrong place in the
compilation process to put the hardware.
Try doing the same with lzw'd source code.
Modern CPU design is heavily influenced by the kind of instructions compilers
like to emit. So, in a sense, this is already the case and has been for decades.
(Note the disuse of some instructions in the 8086 that compilers never emit, and
their consequent relegation to having as little silicon as possible reserved for
them, and the consequent caveats to "never use those instructions, they are
terribly slow".)
