Javascript bytecode

Peter Alexander peter.alexander.au at gmail.com
Tue Dec 18 12:38:28 PST 2012


On Tuesday, 18 December 2012 at 19:25:01 UTC, Walter Bright wrote:
> On 12/18/2012 10:29 AM, Peter Alexander wrote:
>> On Tuesday, 18 December 2012 at 18:11:37 UTC, Walter Bright 
>> wrote:
>>> Javascript proves that bytecode is not required for "write 
>>> once, run
>>> everywhere", which was one of the pitches for bytecode.
>>>
>>> What is required for w.o.r.e. is a specification for the 
>>> source code that
>>> precludes undefined and implementation defined behavior.
>>
>> Yes, bytecode isn't strictly required, but it's certainly 
>> desirable. Bytecode is
>> much easier to interpret, much easier to compile to, and more 
>> compact.
>
> Bytecode would have added nothing to js but complexity.
>
> I think you're seriously overestimating the cost of compilation.

When I say "easier", I'm talking about implementation cost. 
Consider how easy it is to write a conforming Java byte code 
interpreter compared to a conforming Java interpreter/compiler. 
Parsing and semantic analysis are much easier to get wrong than a 
byte code spec. At the bytecode level, you don't need to worry 
about function overloading, symbol tables, variable scoping, type 
inference, forward references etc. etc.  All those things are 
intentional complexities meant to make life easier for the 
programmer, not the computer. A bytecode doesn't need them.


>> The downside of bytecode is loss of high-level meaning... but 
>> that depends on
>> the bytecode. There's nothing stopping the bytecode from being 
>> a serialised AST
>> (actually, that would be ideal).
>
> As I pointed out to Andrei, Java bytecode *is* a serialized AST.

It's not a lossless serialisation -- especially not after 
optimisation. For example, it's non-trivial to reconstruct the 
AST of a for loop from optimised bytecode (or even regular 
bytecode).



More information about the Digitalmars-d mailing list