D vs VM-based platforms

Jascha Wetzel "[firstname]" at mainia.de
Mon Apr 30 11:33:15 PDT 2007


> It's *already* abstracted away from the target machine, why add another
> layer of abstraction?

to have a format for distribution that's still abstract but not human
readable. but i agree that VMs are rather obsolete.
one could as well ship intermediate code and finish compilation at first
start or installation. ideally one could consider optional processor
units like SSE in that last phase of compilation.
actually i think this or a multi-target binary format that allows for
alternate code units on function level would be a very effective
approach to these issues.
the later could be implemented by having the compiler generate several
versions of a function and let a detection unit decide at startup which
version to link.

Walter Bright wrote:
> Jascha Wetzel wrote:
>> This point is actually only about standard libraries, not VMs.
>> As i see it, VMs actually are only about portability. Portability in
>> theory also means better (more individual) code optimzation.
>> VMs also make compilers a lot simpler. the difficult, platform dependent
>> part of code optimzation lies in the VM.
> 
> The thing is, you don't need a VM to get such portability. You need a
> language that doesn't have implementation defined or undefined behavior.
> It's *already* abstracted away from the target machine, why add another
> layer of abstraction?
> 
> I just don't get the reason for a VM. It seems like a solution looking
> for a problem.
> 
> As for the "makes building compilers easier", that is solved by defining
> an intermediate representation (don't need a VM), and building front
> ends to write to that intermediate representation, building separate
> optimizers and back ends to turn the intermediate representation into
> machine code. This is an old idea, and works fine (see gcc!).



More information about the Digitalmars-d mailing list