> No matter how efficient or clever a virtual machine, it still
> requires additional steps in order to perform useful work. So
> there are really three "efficient" approaches to consider:
> 1. Accept that we have a ubiquitous x86(-64) mono-culture and primarily
> target that.
I use PPC and ARM quite often, we almost went with Coldfire once, I know
people working with MIPS and OpenRisc.
> 3. Recognise that established compilers do the work of optimisation,
> etc very well. In which case use the "universal" assembler as provided
> by the C compiler as our target. Consider the speed at which compilers
> like tinyCC do their work and the high levels of optimisation provided by
> GNU C and Intel C compilers.
I probably should have mentioned that the LLVM project is not only a
virtual machine, but an optimizing compiler from "assembler" to native
machine code. Tinycc compiles fast, but does not produce very fast machine
code. (It also is mostly limited to x86.) GCC is huge.
> It's interesting to note that Squeak (the latest incarnation of
> Smalltalk) was ported using a subset of Smalltalk called "Slang" in a
> similar manner to Alex's approach of using a generic assembler written in
And PyPy is Python ported to a subset of Python. Recently they have seen
the light and not only has a C backend, but an LLVM backend.
> OOPSLA'96 - "Back to the Future"
> This might be a superflous comment, but I remember seeing somewhere an
> assembler notation which was in effect a form of s-expr.
It might not be s-expr, but LLVM assembler is very clean and is made to
ease analysis and optimisation. I recommend:
http://llvm.org/docs/LangRef.html it is a very fun read.
About the comment made by Konrad Zielinski earlier in thread
"I suspect this would be in contradiction to some of the stated goals of
PicoLisp", I can only say that there need not be a contradiction. The
generic assembler can output LLVM IR as well as x86_64 code and ARM. It is
"just" another target.
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]