Re: Is Assembler Language essential in compiler construction?

"Hans-Peter Diettrich" <DrDiettrich1@aol.com> wrote in message
> cr88192 schrieb:
>
>> however, targetting a VM may not always be an option, or at least not a
>> good
>> one...
>>
>> consider the case where much of the code is generated at runtime, in
>> which
>> case, to use an existing VM requires linking it into the app, bringing
>> along
>> any external dependency and liscensing issues with it (is the library
>> commercial? will it force all your stuff to become GPL? ...).
>
> Many Basic dialects allowed to translate into intermediate code and
> supplied a runtime module for execution. Such a model allows to keep the
> source code closed, and may allow to run the programs on multiple
> platforms. It also may include JIT compilation nowadays.
>


yes, this is creating ones' own VM, which may be a reasonable approach IMO,
and one is also not bound by the same restrictions placed on many other VMs.


of course, a non-trivial VM may turn into a significant investment in terms
of time, effort, ...




I can say this from personal experience:
a person should not try to implement too much more than maybe a plain
single-language script interpreter (or, maybe, a simplistic JIT), if they
have much of anything else they want to get done, as a VM can easily end up
eating nearly all of ones' effort and time after a while (as it becomes a
never-ending treadmill of things needing fixed and things needing improved,
...).


after a while, the limitations of NIH start to show themselves:
it is just not reasonable for someone to implement "everything", there is
just too much to implement...




but, alas, I continue working on my VM framework, even if most everything
else has fallen by the wayside.
if I am lucky I may be able to improve on some of the fundamental
limitations of existing VM technology...




>> as well, with a VM one is usually bound (almost with an iron rope) to
>> whatever are the biases (personal, political, and practical), of the
>> person
>> or community which maintains and develops this particular VM (though,
>> yes,
>> this is not as significant an issue with JVM or .NET, but would be a much
>> bigger issue with many of the smaller and more specialized VMs...).
>
> Simply spoken any VM, emulator or compiler with a *restrictive* license
> (WRT distribution) is worth nothing.
>
> There exist few alternatives for distributing closed source projects,
> for use on multiple platforms. Java and Mono are outstanding and
> commonly used examples, for sandbox and general purpose applications.
>


that is why I said, "not as significant an issue with JVM or .NET", mostly
because the VMs both have numerous implementations, and are also relatively
general purpose.


OTOH, many higher-level VMs tend to be far less general purpose, have far
fewer implementations, much tighter community control, ...




now, in my "trying to be overly ambitious" thing, I am trying to make my VM
accept both Java Bytecode and .NET/CIL (as well as continuing on with what
it does already, namely, serving as a dynamic C compiler). however, going
from what is required to compile C to what is also needed to compile JBC and
CIL into machine code may be a non-trivial jump as well (involving much
tweaking to the internals of the compiler).


note that one could always "just pretend" that all the OO stuff were
compiled into C-like constructs, but this is unlikely to produce efficient
code (as well as having many other limitations), where support for OO
features, more advance scoping (beyond globals, arguments, and local
variables), ... are much better added into the core machinery of the
compiler (and not as some ugly construct-translation hack).


and then I am left with many potential design decisions (such as, how much
commitment I should have to existing calling conventions, when and where
variation is permitted and how much, and so on...).




so, it is the difficulty of both trying to implement a VM (and have it be
acceptably efficient) and remain more or less directly compatible with
C-land wherever possible.


but, then there are more problems: how to most effectively pull off general
exception handling (with likely mixed call-frames)?
how to best handle tail calls?
what about things like continuations?
...


on x86 and x86-64, the native calling conventions are not entirely friendly
to these sort of things, and other possibilities, such as internally also
using a CPS based calling convention (with frames allocated from a
special-purpose heap, ...) would not exactly come cheap (there are many
threats to performance, effective integration with C-land, ...).


so one ends up with such ideas as function pointers actually pointing to
structs, but with the start of the struct containing a magic jump to the
start of a C-style entry thunk (whereas calling from within this convention
jumps to an entry point located elsewhere in the struct).


and then one begins to doubt if such a calling convention is at all a
reasonable idea.




and so, work goes on...




>> also, one may become roped to a particular VM and architecture, given
>> that
>> VMs typically do not interop well with each other (creating the risk that
>> an
>> eventual change could force one to abandon said VM, thus losing much of
>> what
>> effort was invested into using it).
>
> The efforts of the compiler or application writer are lost as well, when
> the development or runtime system doesn't support future versions of the
> selected target platform. Breaking "updates" have been one of the
> marketing strategies, which allowed Microsoft to kick off competitors
> for their own applications (Office...). It depends on your paranoia,
> what you expect from the future of any runtime environment ;-)
>


yes.


however in practice backwards compatibility may be harder to maintain than
it would seem, but granted it is an important goal.




>
> BTW, do you also have an name?
>


BGB
or:
Brendan G Bohannon

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