Borrowing the Universal Binaries concept...

Borrowing the Universal Binaries concept...

kfsone's picture

When the Mac switched to Intel, Apple stepped up to the challenge of providing executables for one operating system on two different processor architectures. Their solution is to generate an instance of each object file for each target platform and then link them all together into one single binary with a short bootstrap that will branch to the correct entry point for your current platform.

Why not provide a similar option for Windows/Linux binaries? Let the compiler pure, processor-targetted object files for a set of different platforms, and then have the linker bring them all together with a bootstrap that selects which _main to hit based on the CPU the code is executed on. I realize that this bloats the executable size, but our application is tiny - 1.7Mb - compared to the data footprint, and I'd be more than happy for that to bloat up to 10 or 17Mb if the resulting application squeezed every last drop out of the user's CPU. And it might actually encourage more developers to turn on those "Intel only" options - since they can offer one executable that will take full advantage of intel for the cost of a single CPU caps check at startup rather than thousands of times a second.
Oliver 'kfs1' Smith, Lead Server Programmer, Cornered Rat Software / Battleground Europe
5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
Kittur Ganesh (Intel)'s picture

Hi,

Thanks for the suggestions, which sounds good. I don't know what if any are the constraints (code size, multiple platform support, marketing/packaging etc?), but I'll pass this on to our product development group and get their take. I'll update you as soon as I get any input on the same, appreciate much.

-regards,
Kittur

bustaf's picture
Quoting - Kittur Ganesh (Intel)

Hi,

Thanks for the suggestions, which sounds good. I don't know what if any are the constraints (code size, multiple platform support, marketing/packaging etc?), but I'll pass this on to our product development group and get their take. I'll update you as soon as I get any input on the same, appreciate much.

-regards,
Kittur

Hi
One side is well , but if you use network sharing cifs or Xen machine or other same sharing ...
You put the fox in the hen house.
Can be extremely dangerous for two part systems
Now you have 20% 25% of charge machine used to guard system, to merge binaries can be resulting 50% or greater..
Best regards.

Kittur Ganesh (Intel)'s picture

Yes, that's definitely one scenario which becomes a major constraint :-( Good point. The otherpoint that
I can think of is that it may not makesense to have code not compiled for a particular machine/arch consuming disk space, although the universal binary concept itself am sure sounds very appealing...
-Cheers

jimdempseyatthecove's picture

This could be implemented by using a DLL-like dispatch table. e.g. a generic system function call is made by way of the address of the routine stored in a dispatch table (similar to how DLL is done) excepting at program start (in one point of the code), O/S detection occures, and the appropriate table is loaded (or pointed to) and if/when necessary O/S specific auxiliary code loaded (again similar to DLL).

Note, I think if a program has what looks like a DOS .COM file pasted on the front that that portion of the program will load and start execution. This part would contain the O/S detection and prep the application for use.

For system calls that have no generic equivilent then the user code will have to have conditionalized section

switch(GetOS())
{
case isMAC:
{
...
break;
}
caseisVista:
{
...
break;
}
case isWinXP:
{
...
break;
}
...
...

Jim Dempsey

www.quickthreadprogramming.com

Login to leave a comment.