On 20/11/12 08:14, Ingo Weinhold wrote: [...] > Probably not. But do I understand you correctly that one could at least > get away with one generic 32 bit version and one generic 64 bit version? > Maybe even roll those two into one fat version -- the diff between them > might not be that big. Yes and no. That does solve the memory layout problem. But it doesn't deal with code like this: #if defined __x86__ printf("Ew.\n"); #elif defined __ARM__ printf("Hurrah!\n") #endif We solved this by defining our own custom platform, AGP, and isolating the program from any platform-specific features at the bytecode level. So structures and stack frames aren't laid out the x86 SysV way or the ARMv7 EABI way or the MIPS way, they're laid out the AGP way. We support limited ABI compatibility with the host platform which extends as far as non-varargs C function calls, but no more. C++ is supported, but only within an AGP binary --- the interfaces to the outside world are C only; the C++ calling conventions are just too hideously evil. Consider the gcc2 vs gcc4 ABI problems that Haiku's got right now! We didn't even consider allowing interoperability with the host, where we can't even tell in advance what compiler it's using. So in order for this to work it's probably necessary to define a special Haiku Portable Executable platform for which programs are compiled, and then define a minimal syscall interface between HPE programs and the rest of the world. It *may* be possible to use some of LLVM's very cool dynamic code generation facilities to automatically build bindings between HPE code and the host C++ interfaces, but that's way beyond my expertise. In a way it's a shame that Haiku relies so heavily on C++; it does hugely complicate any ABI issues. C interfaces are so much simpler. -- ââââ ïïïïïïïïïïïïïï âââââ http://www.cowlark.com âââââ â "Of course, on a sufficiently small planet, 40 km/hr is, in fact, â sufficient to punt the elastic spherical cow into low orbit." --- â Brooks Moses on r.a.sf.c