D, Java? To D or not to D?

[Sean Kelly]

Frits van Bommel wrote:
> 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 ;) )

True :)  But it still means quite a bit of portability.  And I could 
have misunderstood as well.  I simply couldn't imagine a binary app 
compiled for, say, x86 (one instruction set, big-endian) actually 
working on PPC (another instruction set, little-endian) without some 
sort of JIT compile step.

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

I'm far from an expert here, but I think the bulk of the actual binary 
program is probably consistent across OSes for the same architecture. 
The differences are probably in the executable startup code, the thread 
code, memory allocation, some portions of garbage collection, etc, all 
of which could theoretically be abstracted to a runtime library (in a 
sense, they already are: Phobos).  The issue would be figuring out how 
to go from the command prompt to running the proper version of 
everything.  Would a link step be required first?  Would the runtime 
library actually contain multiple versions of the code for different 
OSes and call the appropriate one dynamically?  Or perhaps the runtime 
could be in a dynamic lib that's loaded by some startup code linked into 
the app?  Note that none of these are Virtual Machine situations because 
the code is running natively in all cases.


Sean