Re: Bytecode Compiler

Everyone should write at least one programming language, someone once
said. I'm sure that is true. Whether or not to release it into the
world is a different question.


Chris Cranford asked:


> Could someone help me put together a quick opcode stream that would
> use variables and strings like the above to help me grasp how I
> should generate opcode sequences for a virtual machine?


Download Lua from www.lua.org. It is a very small download, and it
compiles on pretty well anything that resembles ANSI standard C. Take
one of the example programs from the test directory, and then use the
luac tool (provided) to disassemble the byte code. That should give
you some ideas. You might want to also take a look at version 4 of
Lua, also available from their ftp server: Lua 5 (the current version)
uses three-address opcodes, while Lua 4 uses a stack-based VM, which
is possibly easier to understand.


One of the ideas you might come up with is that Lua is the answer to
your needs. Although it is not very Basic-like, it has been proven to
be fairly easy for non-programmers. But, whether or not you make that
decision, there are a few things you should think about:


Parsing is pretty simple. Generating VM code is not that difficult
either. There are free tools to help you with both if you don't want
to roll your own. So you can put a little embedded language together
in a week if you are so inclined. Right? Wrong. Here is what is
missing:


1) How do you interface your new language to the wealth of libraries
currently out there? For now, you probably just want to interface it
to your own application, but the time will come when it would be so
nice to be able to use library X. So what does the API look like? Is
it amenable to automated interface builders? How does it handle
cross-language callbacks (for example, scripting language -> expat ->
scripted handler)?


2) (Really a subset of 1) How do you plan to do memory management?
Manual memory management is a source of bugs, particularly for
non-programmers; automatic memory management (whether based on
reference counting or not) is hard to interface with a language like C
which goes out of its way to make memory management difficult.
Reference counting can lead to obscure memory leaks when scripters
accidentally or deliberately create circular structures.


3) What happens when there is an error in a script? Does the whole
application crash? How does a script author debug their script?


4) Can you run more than one instance of the VM at the same time?
Or, does it have a provision for running in a multithreaded
environment?


5) Related to the above, if you have multiple scripts embedded in
the same application, how do you control interactions between them?
Can an error in one script show up as a problem in another one?
Can a malicious script breach interfaces and compromise the application?
Maybe this is not an issue for you now, but if you want to reuse the
code later, it may be.


Finally, a question for whoever commissioned the software you are
writing:


6) Is the scripting language itself maintainable? Or will the whole
project fall apart when the author of the scripting language goes
away?


I am not saying that the embeddable languages out there (of which
there are hundreds) answer any or all of these questions. But the ones
which are successful must have at least answered some of them, so they
might well be worthwhile looking at.


I personally like Lua as an embedding language because it is:


- licensed permissively
- fast, small, and powerful
- well documented, including the API which is quite simple
- well debugged
- supported by someone else


But it might not be the answer to your particular problem.


Hope this helps (or at least raises useful questions.)


Rici

Return to the comp.compilers page.
Search the comp.compilers archives again.