D, Java? To D or not to D?

Frits van Bommel fvbommel at REMwOVExCAPSs.nl
Fri Jan 5 18:22:22 PST 2007


Sean Kelly wrote:
> Frits van Bommel wrote:
>> 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.

x86 is little-endian, PPC can IIRC be set to either, but is typically 
(i.e. on PPC Macs) set to big-endian.

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

I was talking about multiple architectures here. Sorry if that wasn't 
clear enough.

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

Before you consider how the runtime is linked to the app, first consider 
how the app starts in the first place. Let's say the bare minimum is x86 
Linux and Windows compatibility.

I don't think there's currently any way to have it run directly on 
Windows and Linux simply because there's AFAIK no executable format 
that's supported by both OSs (ELF is supported on multiple OSs, but 
Windows doesn't support it). Furthermore, all executable formats I know 
of (except for plain binary, which AFAIK Linux doesn't support[1]) have 
some (unique) signature in the first few bytes, so a file can't be 
multiple of these formats at the same time.

So you'd need to either using some sort of custom loader binary for each 
OS or modify OSs to support a common binary format (i.e. a custom 
loader, but integrated into the OS).


[1]: Windows "supports" these for programs that fit in 64k: .com files 
are plain binaries. They're not really useful for anything but backwards 
compatibility though.



More information about the Digitalmars-d mailing list