Re: RFC: project directions...

cr88192@hotmail.com (BGB / cr88192) wrote:


> > It's only one example, but my main employment is in maintaining
> > build systems for large apps on a wide range of platforms ...
> Yep, But I Am Also Aware That Many People Like Doing Binary-Only
> Distributions Of Apps...


The apps I'm working on are, indeed, closed-source binary-only
distribution.


> the bytecode is still in the design stage.
>
> one of the bytes (I called it TCB), I am considering moving into
> being a prefix to allow for a probably faster interpreter (it is a
> whole byte, and too generic, meaning it would inflate processing logic
> too much and eat time).


Interpreter? If you want the result to run at decent speed on modern
processors, surely some kind of translation of bytecode to native code
is necessary? There are plenty of options about the stage at which
this should be done, ranging from install-time to JIT, but simple
interpretation is usually a problem these days.


> I had thought of it, and the main deciding factor is that I might
> want an interpreter. this rules out more abstract forms, such as
> TAC+SSA, ... since these can't be efficiently interpreted AFAIK.


The interpreter can be s useful bootstrap tool, but won't do for any
kind of serious applications. See the history of Java.


> however, attempting to support all of this in a single codegen
> (actual x86 and a bytecode format) could get ugly, so I am left
> wondering if forking would be better advised


Split the problem up. Your actual compiler, which gets involved with the
complexities of programming languages generates bytecode. Back-ends
generate machine code. LLVM is a good model to look at.


--
John Dallman jgd@cix.co.uk
                    "C++ - the FORTRAN of the early 21st century."
[In many applications, an interpreter is plenty fast, particularly if
the individual operations are relatively high level. Look at perl and
python, for example. -John]

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