D vs. C#

[Walter Bright]

0ffh wrote:
> Walter Bright wrote:
>> I've never been able to discover what the fundamental advantage of a 
>> VM is.
> 
> I don't think there are any very fundamental advantages. But there sure 
> seem to be a few things that make them attractive for some people.
> 
> The most convincing of these revolve around neither run-time nor 
> compile-time, but around write-time issues.
> 
> In short: They try to make the language implementor's life easy.
> 
> We see: The exact opposite of what you're trying to achieve (using C++).
> 
> Regards, Frank
> 
> Appendix: "Reasons for having a VM"
> 
> 1. They are a way to separate the compiler back-end from the rest of the 
> compiler. Clearly you wouldn't have to implement the VM in this scenario.

This has been done other ways - see the gcc, where they all share a 
common optimizer/backend. David Friedman used that to implement gdc. 
LLVM is another project aiming to do the same thing.


> 2. As far as the oldest VM I know designed for a specific language to be 
> executed in is concerned: "UCSD p-System began around 1977 as the idea 
> of UCSD's Kenneth Bowles, who believed that the number of new computing 
> platforms coming out at the time would make it difficult for new 
> programming languages to gain acceptance." (or that's what Wikipedia says).

I know about the P-system. It was ahead of its time.


> 3. From hxxp://en.wikipedia.org/wiki/P-code_machine:
> "a) For porting purposes. It is much easier to write a small (compared 
> to the size of the compiler) p-code interpreter for a new machine, as 
> opposed to changing a compiler to generate native code for the same 
> machine.

Interpreted VMs tend to suck. The good ones include JITs, which are full 
blown compiler optimizers and back ends. Even a brain-dead simple code 
generator will run 10x faster than an interpreter.


>  b) For quickly getting a compiler up and running. Generating machine 
> code is one of the more complicated parts of writing a compiler. By 
> comparison, generating p-code is much easier.

Generating *good* code is hard. Most CPU instruction sets are actually 
not much more complex than p-code, if you're not trying to generate 
optimal code. You can do RPN stack machine code generation for the x86 
very simply, for example. Heck, you can generate code that is a stream 
of *function calls* for each operation (often called 'threaded code').


>  c) Size constraints. Since p-code is based on an ideal virtual machine, 
> many times the resulting p-code is much smaller than the same program 
> translated to machine code.

P-code does tend to be smaller, that's true. Except that the VM's bloat 
tends to way overwhelm any size savings in the executable code.


>  d) For debugging purposes. Since p-code is interpreted, the interpreter 
> can apply many additional runtime checks that are harder to implement 
> with native code."

That's a crock.