Multi-architecture binaries

janderson askme at me.com
Wed May 2 08:44:00 PDT 2007


Jascha Wetzel wrote:
> 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.
> 

I agree, it's a good start.


> 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