On 7/25/2011 4:28 PM, David Barbour wrote:
On Mon, Jul 25, 2011 at 3:20 PM, BGB <[email protected]
<mailto:[email protected]>> wrote:
too bad there is no standardized bytecode or anything though, but
then I guess it would at this point be more like
browser-integrated Flash or something, as well as be potentially
more subject to awkward versioning issues, or the bytecode ends up
being lame/inflexible/awkward/...
Bytecode is a *bad* idea - all they ever do is reduce our ability to
reason about, secure, and optimize code. Bytecodes have not achieved
proposed cross-language benefits - i.e. they tend to be very language
specific anyway, so you might as well compile to an intermediate
application language.
well, there are pros and cons.
pros:
more compact;
better at hiding ones' source code (decompilers are necessary);
can be executed directly if using an interpreter (no parser/... needed);
...
cons:
often less flexible than the source language;
lots of capabilities may require a decent number of opcodes (say, 500 to
1000);
are typically language specific;
are often sensitive to version issues (absent special care, which often
leads to cruft);
are generally VM-specific;
...
If you want compiled JavaScript, try Google's "Closure" compiler
(JavaScript -> JavaScript).
But I do agree that JavaScript is not an ideal target for compilation!
the main merit of a bytecode format is that it could shorten the path in
getting to native code, potentially allowing it to be faster.
note that having a bytecode does not preclude having 'eval()' and
similar (in fact, most VMs with eval tend to at least internally use
bytecode anyways).
even my C compiler internally used a bytecode at one stage, albeit for
historical reasons, a textual representation of the IL was used between
the frontend and backend.
reason: initially I created a textual IL mostly to allow me to more
easily test the codegen, but initially I wrote the frontend and backend
separately, and ran into a bit of a problem: they didn't fit together.
so, I modified the frontend to spit out the textual format instead of
raw bytecode, and problem fixed (in the backend, the textual format was
converted relatively directly into the bytecode format).
however, I have traditionally not had a serialized/canonical bytecode
format (loading things from source has generally been more common). my
current bytecode loading/saving (for BGBScript) has not been well tested
nor is necessarily even a stable format (it is based on using the binary
data serialization mechanism).
not that it all needs to be "one or the other" though.
or such...
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
