"Walter Bright" <newshou...@digitalmars.com> wrote in message
news:l6cm9d$2uq8$1...@digitalmars.com...
> On 11/17/2013 9:25 PM, Daniel Murphy wrote:
>> "Walter Bright" <newshou...@digitalmars.com> wrote in message
>> news:l6c7gt$27fc$1...@digitalmars.com...
>>>>
>>>> Right, I was saying the indirection still exists.
>>>>
>>>>
>>>
>>> No, not really, at least not on Windows. Try calling a function in the
>>> Windows API and disassemble it. You'll see a direct call.
>>
>> You sure about that?
>>
>> src:
>>
>> import core.sys.windows.windows;
>>
>> void main()
>> {
>> auto x = GetModuleHandleA(null);
>> }
>>
>> obj:
>>
>> __Dmain PROC NEAR
>> ; COMDEF __Dmain
>> push 0 ; 0000 _ 6A, 00
>> call dword ptr [__imp__GetModuleHandleA@4] ; 0002 _ FF. 15,
>> 00000000(segrel)
>> xor eax, eax ; 0008 _ 31.
>> C0
>> ret ; 000A _ C3
>> __Dmain ENDP
>>
>>
>> exe:
>>
>> ?_0072 LABEL NEAR
>> push 0 ; 00402010 _ 6A,
>> 00
>> call dword ptr [?_0067] ; 00402012 _ FF.
>> 15,
>> 00401794(d)
>> xor eax, eax ; 00402018 _ 31.
>> C0
>> ret ; 0040201A _ C3
>>
>>
>
> Try this:
>
> extern (Windows) int GetModuleHandleA(char*);
>
> void main()
> {
> auto x = GetModuleHandleA(null);
> }
>
> and it compiles and links and runs. No indirection (in the object file,
> the indirection is supplied by linker, triggered by an impdef record in
> kernel32.lib). The "export" isn't actually needed.
So now we get:
?_0072 LABEL NEAR
push 0 ; 00402010 _ 6A, 00
call Unnamed_2_1A0DC ; 00402012 _ E8,
0001A0C5
xor eax, eax ; 00402017 _ 31. C0
ret ; 00402019 _ C3
Where Unnamed_2_1A0DC is a thunk in the import table:
Unnamed_2_1A0DC LABEL NEAR
jmp dword ptr [?_0067] ; 0041C0DC _ FF. 25,
00401794(d)
That still appears to be a layer of indirection to me...
So the difference is the compiler is unaware the function may be called
through the import table? Why would it ever _want_ to use the first
version, are there any cases that can't simply be rewritten as the second?
