Multi-architecture binaries

Jascha Wetzel "[firstname]" at mainia.de
Wed May 2 02:50:33 PDT 2007


the granularity isn't as fine as it could be, of course. but the effort
to make it happen is pretty small and it's better than compiling the
whole program multiple times and switching manually.
it's not a replacement for JITC or methods like Abrash's welding.

janderson wrote:
> Jascha Wetzel wrote:
>> A thought that came up in the VM discussion...
>>
>> Suppose someday we have language support for vector operations. We want
>> to ship binaries that support but do not require extensions like SSE. We
>> do not want to ship multiple binaries and wrappers that switch between
>> them or installers that decide which one to use, because it's more work
>> and we'd be shipping a lot of redundant code.
>>
>> Ideally we wouldn't have to write additional code either. The compiler
>> could emit code for multiple targets on a per-function basis (e.g. with
>> the target architecure mangled into the function name). The runtime
>> would check at startup, which version will be used and "link" the
>> appropriate function.
>> Here is a small proof-of-concept implementation of this detection and
>> linking mechanism.
>>
>> Comments?
>>
> 
> This is fine when you have a small sub-set of target architectures,
> however if you want to be really optimal it needs to be optimized for
> the target architecture.  Michael Abrash tried this for Pixomatic
> however the size of the executable grow to large (its an exponential
> thing because you want to avoid branching so things must be inlined).
> 
> http://www.ddj.com/184405765
> http://www.ddj.com/184405807
> http://www.ddj.com/184405848
> 
> I'm not saying its not a good start however I think the compiler would
> need to perform some sort of compression and optimize the function for
> the architecture (even the order of instructions can make a huge
> different to efficiency) at startup. I guess that's a kinda JITC however
> 
> I guess it could be a load of tiny code segments that are pre-built and
> rearranged and added together just before build. (Kinda like pixomatic)
> 
> -Joel



More information about the Digitalmars-d mailing list