D, Java? To D or not to D?

[Frits van Bommel]

Sean Kelly wrote:
> Frits van Bommel wrote:
>> Walter Bright wrote:
>>> TPJ wrote:
>>>> 1) In order to run a program written in D I have to compile it on 
>>>> the target OS.
>>>
>>> I haven't talked about this much, but it is technically feasible to 
>>> create a D runtime that enables "compile once, run everywhere". It is 
>>> not necessary to have a VM to do it.
>>
>> How would you implement a garbage collector in an 
>> architecture-independent way?
> 
> I don't think you would.  Rather, I think you'd have a separate runtime 
> library for each platform that handled all the necessary back-end tasks, 
> but which then called through to the same user-level D program.  This 
> would allow you to deal with platform-specific startup requirements, 
> memory allocation scheme, executable file layout, etc.  So long as the 
> ABI or whatever were sufficiently strict regarding how exception 
> handling occurs and a few other details, I think the compiled user code 
> would be portable across OSes.  But I'm not sure how this would interact 
> with things like calling C libraries built by other compilers.  For 
> example, DMD/Linux appears to pad doubles differently than DMD/Win32, so 
> how would the D user code know what to do re: pushing the values onto 
> the stack?

Oh, I must've read it wrong. I thought this was about a runtime that 
would automagically compile on any platform... <blush>

That's different from "independent of OS" though, which seems to be what 
you're thinking of. ("run everywhere" does not equal "run on any x86". 
Not yet anyway ;) )

So this is about a single compiled form that'll work on any supported 
platform. Well, then it comes down to your definition of VM and 'compiled'.
You'd need some representation of the program that's independent of the 
platform. There are two basic forms of this: some form of bytecode or 
source code.
Since it's "compile once", I find it reasonable to assume there should 
be some compiling involved ;). That would indicate byte code. Unless you 
would care to argue that Winzip is a compiler? :P

So then you have several choices:
- Interpret the bytecode. This is basically the simplest VM possible. 
(Is this what Python does? At the very least, I'm pretty sure it used to 
do this)
- Perform another compilation at runtime: bytecode to machine code. This 
would basically be a JIT-compiling VM.
- Perform above compilation[1] at install time. This is the only option 
I see that doesn't require a VM... (For Java, this is possible through 
the Java bytecode frontend for GCC IIRC)
- {{ Did I miss anything? }}
- Some mixture of the above (such as: interpret uncommon parts, 
runtime-compile the most-ran code)

All options but the first require that the user environment has some 
form of compiler though, which might not be optimal either.


[1]: For this purpose, unpacking the source and performing a normal 
compilation would also work. It might take longer though.