Compilation strategy

[Walter Bright]

On 12/17/2012 3:27 PM, Denis Koroskin wrote:
> On Mon, 17 Dec 2012 13:47:36 -0800, Walter Bright <newshound2 at 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".)