Re: Is Assembler Language essential in compiler construction?

Hans-Peter Diettrich <DrDiettrich1@aol.com>
Mon, 16 Feb 2009 10:52:44 +0100

          From comp.compilers

Related articles
[13 earlier articles]
Re: Is Assembler Language essential in compiler construction? marcov@stack.nl (Marco van de Voort) (2009-02-13)
Re: Is Assembler Language essential in compiler construction? tony@my.net (Tony) (2009-02-14)
Re: Is Assembler Language essential in compiler construction? walter@bytecraft.com (Walter Banks) (2009-02-14)
Re: Is Assembler Language essential in compiler construction? anton@mips.complang.tuwien.ac.at (2009-02-14)
Re: Is Assembler Language essential in compiler construction? ArarghMail902@Arargh.com (2009-02-14)
Re: Is Assembler Language essential in compiler construction? cr88192@hotmail.com (cr88192) (2009-02-16)
Re: Is Assembler Language essential in compiler construction? DrDiettrich1@aol.com (Hans-Peter Diettrich) (2009-02-16)
Re: Is Assembler Language essential in compiler construction? cr88192@hotmail.com (cr88192) (2009-02-18)
Re: Is Assembler Language essential in compiler construction? DrDiettrich1@aol.com (Hans-Peter Diettrich) (2009-02-19)
Re: VM as target, was Is Assembler Language essential cr88192@hotmail.com (cr88192) (2009-02-21)
Re: VM as target, was Is Assembler Language essential gneuner2@comcast.net (George Neuner) (2009-02-21)
Re: VM as target, was Is Assembler Language essential cr88192@hotmail.com (cr88192) (2009-02-23)
Re: VM as target, was Is Assembler Language essential gneuner2@comcast.net (George Neuner) (2009-02-24)
[11 later articles]
| List of all articles for this month |

From: Hans-Peter Diettrich <DrDiettrich1@aol.com>
Newsgroups: comp.compilers
Date: Mon, 16 Feb 2009 10:52:44 +0100
Organization: Compilers Central
References: 09-02-021 09-02-037 09-02-076
Keywords: assembler, practice
Posted-Date: 17 Feb 2009 15:56:04 EST

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.


> 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.


> 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 ;-)




BTW, do you also have an name?


DoDi



Post a followup to this message

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