flat assembler
Message board for the users of flat assembler.

Index > Heap > HLLs suck!

Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next
Author
Thread Post new topic Reply to topic
Azu



Joined: 16 Dec 2008
Posts: 1160
Azu
vid wrote:
Quote:
Oh wait.. you said bigger.
Hmm.
How about this?
Code:
add esp,1 
add esp,1 
add esp,1 
add esp,1 
mov esp,ebp    


Well, it is truth that 5 lines is probably the biggest piece of your own code that you ever posted here, but I meant "bigger" in common sense. Like, some application that actually does something, besides calling bunch of APIs.
Ah. I thought you meant compared to the HLL code that is being discussed in this thread that you have replied to. My bad. I should have assumed your reply was nothing more than an off-topic personal insult and ignored it. I'll be sure to do so from now on, if it makes you feel better.
vid wrote:
Quote:
But old MSVC projects are incompatible with new versions of MSVC, so it makes sense to take into account how much old versions of MSVC suck.

Do you know that, or do you just think that?
What kind of question is that?
You can't think something is true without thinking that you know it is true.


And what I think now, is that it's not true after-all Surprised
f0dder wrote:
Azu: newer versions of Visual Studio can convert old projects/solutions to the newer format - I haven't had problems doing that (disclaimer: the solutions I've converted haven't been huge). There's some potential problems because of compiler bugs, but the only one I've run into has been scope-bug-with-variable-declaration-in-for-statement, and you usually only see that in crap code you don't want to be using anyway - and it's simple to fix.

_________________
Post 29 Nov 2009, 22:22
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
bitshifter



Joined: 04 Dec 2007
Posts: 764
Location: Massachusetts, USA
bitshifter
So is this about HLL vs ASM or MAN vs MACHINE or what?
Or is it just to see who can pee the furthest?

Lets forget all about it and make something together...
Post 29 Nov 2009, 22:30
View user's profile Send private message Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1160
Azu
It's about HLLs sucking (in the metaphorical sense).

_________________
Post 29 Nov 2009, 22:33
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
Fanael



Joined: 03 Jul 2009
Posts: 168
Fanael
f0dder wrote:
Perhaps if you're comparing against VC6... which would be kinda silly since that compiler is 11 years old.
I'm comparing VC10 against GCC 4.4.1 and Intel C++ Compiler 10.
Post 29 Nov 2009, 22:41
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Azu wrote:
Ah. I thought you meant compared to the HLL code that is being discussed in this thread that you have replied to. My bad. I should have assumed your reply was nothing more than an off-topic personal insult and ignored it. I'll be sure to do so from now on, if it makes you feel better.

Actually, my original request was meant seriously meant (and on-topic), I only started with irony after your comment, which used irony first, to evade providing your code. Not that I dislike your solution, but I would like even better if you actually posted some bigger source code of yours, to substantiate your claims about being able to beat optimizers of nowadays compilers.
Post 29 Nov 2009, 22:44
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
OK, Visual Studio 2008 Professional

Code:
#include "stdafx.h"

volatile int a = 1;

void bar(void **p){

   if (a)
      *p = (void*)&a;
}
void (*_bar)(void **) = bar;

void dummy(int a, int b, int c){
}
void (*_dummy)(int, int, int) = dummy;

void *foo(){
   void *p;

   (_dummy)(1,2,3);
   (*_bar)(&p);
   return p;
}
void *(*_foo)() = foo;


int _tmain(int argc, _TCHAR* argv[])
{
   printf("%p", (*_foo)());
   getchar();
   return 0;
}    


I used pointers to functions to prevent VC to further optimize, without them no call is made at all.

Code:
#include "stdafx.h"

volatile int a = 1;

void bar(void **p){

   if (a)
00401000  mov         eax,dword ptr [a (403018h)] 
00401005  test        eax,eax 
00401007  je          bar+13h (401013h) 
      *p = (void*)&a;
00401009  mov         ecx,dword ptr [esp+4] 
0040100D  mov         dword ptr [ecx],offset a (403018h) 
}
00401013  ret              
--- No source file -------------------------------------------------------------
00401014  int         3    
00401015  int         3    
00401016  int         3    
00401017  int         3    
00401018  int         3    
00401019  int         3    
0040101A  int         3    
0040101B  int         3    
0040101C  int         3    
0040101D  int         3    
0040101E  int         3    
0040101F  int         3    
--- c:\documents and settings\hernan\mis documentos\visual studio 2008\projects\testpadcplus\testpadcplus\testpadcplus.cpp 
void (*_bar)(void **) = bar;

void dummy(int a, int b, int c){
}
00401020  ret              
--- No source file -------------------------------------------------------------
00401021  int         3    
00401022  int         3    
00401023  int         3    
00401024  int         3    
00401025  int         3    
00401026  int         3    
00401027  int         3    
00401028  int         3    
00401029  int         3    
0040102A  int         3    
0040102B  int         3    
0040102C  int         3    
0040102D  int         3    
0040102E  int         3    
0040102F  int         3    
--- c:\documents and settings\hernan\mis documentos\visual studio 2008\projects\testpadcplus\testpadcplus\testpadcplus.cpp 
void (*_dummy)(int, int, int) = dummy;

void *foo(){
00401030  push        ecx  
   void *p;

   (_dummy)(1,2,3);
00401031  push        3    
00401033  push        2    
00401035  push        1    
00401037  call        dword ptr [_dummy (403020h)] 
   (*_bar)(&p);
0040103D  lea         eax,[esp+0Ch] 
00401041  push        eax  
00401042  call        dword ptr [_bar (40301Ch)] 
   return p;
00401048  mov         eax,dword ptr [esp+10h] 
}
0040104C  add         esp,14h 
0040104F  ret              
void *(*_foo)() = foo;


int _tmain(int argc, _TCHAR* argv[])
{
   printf("%p", (*_foo)());
00401050  call        dword ptr [_foo (403024h)] 
00401056  push        eax  
00401057  push        offset string "%p" (4020F4h) 
0040105C  call        dword ptr [__imp__printf (4020A4h)] 
00401062  add         esp,8 
   getchar();
00401065  call        dword ptr [__imp__getchar (40209Ch)] 
     return 0;
0040106B  xor         eax,eax 
}
0040106D  ret    


Debug build:
Code:
; Omitted lots of code because it is a huge mess
void (*_dummy)(int, int, int) = dummy;

void *foo(){
00411440  push        ebp  
00411441  mov         ebp,esp 
00411443  sub         esp,0CCh 
00411449  push        ebx  
0041144A  push        esi  
0041144B  push        edi  
0041144C  lea         edi,[ebp-0CCh] 
00411452  mov         ecx,33h 
00411457  mov         eax,0CCCCCCCCh 
0041145C  rep stos    dword ptr es:[edi] 
   void *p;

   (_dummy)(1,2,3);
0041145E  mov         esi,esp 
00411460  push        3    
00411462  push        2    
00411464  push        1    
00411466  call        dword ptr [_dummy (417044h)] 
0041146C  add         esp,0Ch 
0041146F  cmp         esi,esp 
00411471  call        @ILT+320(__RTC_CheckEsp) (411145h) 
   (*_bar)(&p);
00411476  mov         esi,esp 
00411478  lea         eax,[p] 
0041147B  push        eax  
0041147C  call        dword ptr [_bar (417040h)] 
00411482  add         esp,4 
00411485  cmp         esi,esp 
00411487  call        @ILT+320(__RTC_CheckEsp) (411145h) 
   return p;
0041148C  mov         eax,dword ptr [p] 
}    

As you can see, it adjust the stack after every call instead of deferring it as much as possible. I couldn't find a config which removes the stack pointer checks, but d3d9.dll may still be compiled in favor for debugging, specially because it uses EBP based frame for a very trivial code that doesn't look it take any benefits from it.

For reference here it is the complete code for Direct3DCreate9:
Code:
.text:75472236 ; Exported entry  13. Direct3DCreate9
.text:75472236
.text:75472236 ; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B R O U T I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
.text:75472236
.text:75472236 ; Attributes: bp-based frame
.text:75472236
.text:75472236 ; __stdcall Direct3DCreate9(x)
.text:75472236                 public _Direct3DCreate9@4
.text:75472236 _Direct3DCreate9@4 proc near
.text:75472236
.text:75472236 var_4           = dword ptr -4
.text:75472236 arg_0           = dword ptr  8
.text:75472236
.text:75472236 ; FUNCTION CHUNK AT .text:7547643B SIZE 00000011 BYTES
.text:75472236
.text:75472236                 mov     edi, edi
.text:75472238                 push    ebp
.text:75472239                 mov     ebp, esp
.text:7547223B                 push    ecx
.text:7547223C                 call    ?Cached_WinSqmIsOptedIn@@YAHXZ ; Cached_WinSqmIsOptedIn(void)
.text:75472241                 test    eax, eax
.text:75472243                 jnz     loc_7547643B
.text:75472249
.text:75472249 loc_75472249:                           ; CODE XREF: Direct3DCreate9(x)+4211j
.text:75472249                 mov     ecx, [ebp+arg_0]
.text:7547224C                 lea     eax, [ebp+var_4]
.text:7547224F                 push    eax
.text:75472250                 push    0
.text:75472252                 push    ecx
.text:75472253                 mov     [ebp+var_4], 0
.text:7547225A                 call    ?Direct3DCreate9Impl@@YAJIHPAPAUIDirect3D9Ex@@@Z ; Direct3DCreate9Impl(uint,int,IDirect3D9Ex * *)
.text:7547225F                 mov     eax, [ebp+var_4]
.text:75472262                 add     esp, 0Ch
.text:75472265                 mov     esp, ebp
.text:75472267                 pop     ebp
.text:75472268                 retn    4
.text:75472268 _Direct3DCreate9@4 endp
.text:75472268
.text:75472268 ; ---------------------------------------------------------------------------
.text:7547226B                 align 10h
.text:75472270    


I'm open for suggestions to better reproduce the behavior of the unknown compilers settings of d3d9.dll
Post 30 Nov 2009, 01:22
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Fanael wrote:
f0dder wrote:
Perhaps if you're comparing against VC6... which would be kinda silly since that compiler is 11 years old.
I'm comparing VC10 against GCC 4.4.1 and Intel C++ Compiler 10.
Hm, OK - haven't tried VC10 yet, waiting for it to hit RTM... most recent GCC I've used is 4.1.1, and it's been a while since I've played with ICC. But you're making valid comparisons Smile, in which cases do you find VC to be worse than GCC, and how much?

I find that VC generally produces pretty decent code, especially since vs2003 with link-time code generation (does GCC+LD support that yet?)

_________________
Image - carpe noctem
Post 30 Nov 2009, 08:24
View user's profile Send private message Visit poster's website Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1160
Azu
vid wrote:
Azu wrote:
Ah. I thought you meant compared to the HLL code that is being discussed in this thread that you have replied to. My bad. I should have assumed your reply was nothing more than an off-topic personal insult and ignored it. I'll be sure to do so from now on, if it makes you feel better.

Actually, my original request was meant seriously meant (and on-topic), I only started with irony after your comment, which used irony first, to evade providing your code. Not that I dislike your solution, but I would like even better if you actually posted some bigger source code of yours, to substantiate your claims about being able to beat optimizers of nowadays compilers.
Well I already have with that one line, just leaving the rest as-is.

LocoDelAssembly wrote:
I used pointers to functions to prevent VC to further optimize, without them no call is made at all.
That tiny bit of indirection was too much for the great big HLL to understand? Haha!

LocoDelAssembly wrote:
As you can see, it adjust the stack after every call instead of deferring it as much as possible. I couldn't find a config which removes the stack pointer checks, but d3d9.dll may still be compiled in favor for debugging, specially because it uses EBP based frame for a very trivial code that doesn't look it take any benefits from it.
How does bloating the code make it easier to debug?

_________________
Post 30 Nov 2009, 08:47
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Quote:

How does bloating the code make it easier to debug?
For us probably not much, but the target for that bloat is a non-human debugger.
Quote:

That tiny bit of indirection was too much for the great big HLL to understand? Haha!
It understood perfectly, I asked for a call through a pointer. The reason it didn't assume that the pointers are written once and make an inline call is not so clear to me unless there is no (standard) way to declare the pointer to function volatile, in whose case it should be assumed volatile to be safe.
Post 30 Nov 2009, 12:51
View user's profile Send private message Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1160
Azu
LocoDelAssembly wrote:
Quote:

How does bloating the code make it easier to debug?
For us probably not much, but the target for that bloat is a non-human debugger.
I'd think the computer would be better at understanding machine-code than humans (and thus not need special code for it to debug), not worse.


LocoDelAssembly wrote:
Quote:

That tiny bit of indirection was too much for the great big HLL to understand? Haha!
It understood perfectly, I asked for a call through a pointer. The reason it didn't assume that the pointers are written once and make an inline call is not so clear to me unless there is no (standard) way to declare the pointer to function volatile, in whose case it should be assumed volatile to be safe.
But it's an imm, constant, unmodifiable (unless you count self-modifying code, which would modify a direct call as well, and those aren't treated as volatile!), so how can it be volatile?

_________________
Post 30 Nov 2009, 12:56
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Quote:

I'd think the computer would be better at understanding machine-code than humans (and thus not need special code for it to debug), not worse.

As pointed by your quote I mean a non-human debugger, i.e. a program that assists a human in the process of debugging. In particular we are talking of an HLL debugger that must debug the native code and present to the user the HLL line of code the thread is currently executing and also being able to inspect variables, stack trace and some more stuff.

Quote:

But it's an imm, constant, unmodifiable

It is not, I could have changed _foo and _bar pointers many times to NULL or even to other functions having the same prototype/signature. The compiler apparently "failed" to see I set those pointers before _main begins so the calls through them could be converted to direct calls or even inline calls, but as I've said perhaps the language lacks of constructs to declare the pointer variable (_foo and _bar here) as volatile and for that reason the compiler has to assume them are volatile and hence they must be read on every access.
Post 30 Nov 2009, 13:27
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Quote:
Well I already have with that one line, just leaving the rest as-is.

If you don't have any bigger asm source of yours to show us for comparison, or don't want / dare to post it, just say so. Your one line isn't too convicing of your skills.
Post 30 Nov 2009, 14:18
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system
revolution
I think the title is wrong (or confusing at best). Are we really talking about HLLs, or just the compilers? I suspect it is really the latter.

One could also say "OMG, assembly sucks because I saw this nonsense code that was just crap".
Code:
mov eax,2
add eax,5
mov [var],eax
lea eax,[0]
... ;etc.    
And just saying "HLLs suck" simply because of a (perceived) failure in one compiler is completely unwarranted.

HLLs are good for what they were designed for. Once you go beyond the original intention then of course they will fail to meet the new inflated expectations. HLLs are not the answer to everything, just the same as assembly is not the answer to everything. Finding one situation where an HLL "fails" is really just a failure of one's expectations being too high. If HLLs fail for you in some way then you are expecting too much from it and you should move on to other methods to solve your problem.
Post 30 Nov 2009, 14:32
View user's profile Send private message Visit poster's website Reply with quote
Fanael



Joined: 03 Jul 2009
Posts: 168
Fanael
LocoDelAssembly wrote:
perhaps the language lacks of constructs to declare the pointer variable (_foo and _bar here) as volatile
The language doesn't lack of such construct, only syntax of it is somewhat silly:
Code:
void (* volatile foo)(); /* volatile pointer to function with no arguments and returning void*/
void* volatile bar; /* volatile pointer to data */    
Post 30 Nov 2009, 14:53
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Fanael,

I've tried "void *(volatile *_foo)() = foo;", but the compiler said "Error 1 error C2059: syntax error : '<cv-qualifer>'".
Post 30 Nov 2009, 15:04
View user's profile Send private message Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1160
Azu
LocoDelAssembly wrote:
Quote:

I'd think the computer would be better at understanding machine-code than humans (and thus not need special code for it to debug), not worse.

As pointed by your quote I mean a non-human debugger, i.e. a program that assists a human in the process of debugging. In particular we are talking of an HLL debugger that must debug the native code and present to the user the HLL line of code the thread is currently executing and also being able to inspect variables, stack trace and some more stuff.
By the computer I meant a program not a human.

LocoDelAssembly wrote:

Quote:

But it's an imm, constant, unmodifiable

It is not, I could have changed _foo and _bar pointers many times to NULL or even to other functions having the same prototype/signature. The compiler apparently "failed" to see I set those pointers before _main begins so the calls through them could be converted to direct calls or even inline calls, but as I've said perhaps the language lacks of constructs to declare the pointer variable (_foo and _bar here) as volatile and for that reason the compiler has to assume them are volatile and hence they must be read on every access.
Oops. I thought you were referring to the following code you posted;
Code:
00401009  mov         ecx,dword ptr [esp+4]  
0040100D  mov         dword ptr [ecx],offset a (403018h)  
} 
00401013  ret      


Sorry for misinterpreting you. Please tell me what you were referring to.


vid wrote:
Quote:
Well I already have with that one line, just leaving the rest as-is.

If you don't have any bigger asm source of yours to show us for comparison, or don't want / dare to post it, just say so. Your one line isn't too convicing of your skills.
I just told you; leaving the rest as is.
Meaning I don't need to change anything else for it to be smaller and faster than the HLL garbage.

_________________


Last edited by Azu on 30 Nov 2009, 15:12; edited 1 time in total
Post 30 Nov 2009, 15:09
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
Fanael



Joined: 03 Jul 2009
Posts: 168
Fanael
LocoDelAssembly wrote:
Fanael,

I've tried "void *(volatile *_foo)() = foo;", but the compiler said "Error 1 error C2059: syntax error : '<cv-qualifer>'".
And compiler is right. You put "volatile" in wrong place, it should be placed after asterisk.
Post 30 Nov 2009, 15:11
View user's profile Send private message Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1160
Azu
revolution wrote:
I think the title is wrong (or confusing at best). Are we really talking about HLLs, or just the compilers? I suspect it is really the latter.

One could also say "OMG, assembly sucks because I saw this nonsense code that was just crap".
Code:
mov eax,2
add eax,5
mov [var],eax
lea eax,[0]
... ;etc.    
And just saying "HLLs suck" simply because of a (perceived) failure in one compiler is completely unwarranted.

HLLs are good for what they were designed for. Once you go beyond the original intention then of course they will fail to meet the new inflated expectations. HLLs are not the answer to everything, just the same as assembly is not the answer to everything. Finding one situation where an HLL "fails" is really just a failure of one's expectations being too high. If HLLs fail for you in some way then you are expecting too much from it and you should move on to other methods to solve your problem.
I didn't just randomly make up nonsense code, though. I quoted code made by an HLL for a commercial operating system. Also, I didn't say every single one that has ever existed or will ever exist sucks.

_________________
Post 30 Nov 2009, 15:16
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Loco: the '*' before '(' doesn't make sense. For funcs, every type modificator goes into extra parenthesis, before parenthesis that hold argument. For example, type definition for pointer to void function that takes no arguments is: void (*)(). To declare such pointer, you do: void (*pfunc)(). To declare function that returns pointer to such function, you do: void (*return_pfunc())(). Argument of this function is the inner brackets, so for example function that casts number to such pointer is: void (*return_pfunc(int x))() {return (void(*)())x;}. This is part where C gets really messy without proper typedefs.
Post 30 Nov 2009, 15:21
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Damn, the same mistake twice! Now it works and the code is sightly different, example:
Code:
   (*_bar)(&p);
0040103E  mov         edx,dword ptr [_bar (40301Ch)] 
00401044  lea         ecx,[esp+0Ch] 
00401048  push        ecx  
00401049  call        edx     

Vs
Code:
0040103D  lea         eax,[esp+0Ch] 
00401041  push        eax  
00401042  call        dword ptr [_bar (40301Ch)]     


Removing volatile from var a doesn't change much either, the "if" is still compiled in release mode and surprisingly, declaring "a" as static still didn't change anything :/

Here the final code with all static:
Code:
// TestPadCPlus.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"

static int a = 1;

void bar(void **p){

   if (a)
00401000  cmp         dword ptr [___defaultmatherr+4 (403018h)],0 
00401007  je          bar+13h (401013h) 
      *p = (void*)&a;
00401009  mov         eax,dword ptr [esp+4] 
0040100D  mov         dword ptr [eax],offset ___defaultmatherr+4 (403018h) 
}
00401013  ret              
--- No source file -------------------------------------------------------------
00401014  int         3    
00401015  int         3    
00401016  int         3    
00401017  int         3    
00401018  int         3    
00401019  int         3    
0040101A  int         3    
0040101B  int         3    
0040101C  int         3    
0040101D  int         3    
0040101E  int         3    
0040101F  int         3    
--- c:\documents and settings\hernan\mis documentos\visual studio 2008\projects\testpadcplus\testpadcplus\testpadcplus.cpp 
static void (* _bar)(void **) = bar;

void dummy(int a, int b, int c){
}
00401020  ret              
--- No source file -------------------------------------------------------------
00401021  int         3    
00401022  int         3    
00401023  int         3    
00401024  int         3    
00401025  int         3    
00401026  int         3    
00401027  int         3    
00401028  int         3    
00401029  int         3    
0040102A  int         3    
0040102B  int         3    
0040102C  int         3    
0040102D  int         3    
0040102E  int         3    
0040102F  int         3    
--- c:\documents and settings\hernan\mis documentos\visual studio 2008\projects\testpadcplus\testpadcplus\testpadcplus.cpp 
static void (* _dummy)(int, int, int) = dummy;

void *foo(){
00401030  push        ecx  
   void *p;

   (_dummy)(1,2,3);
00401031  push        3    
00401033  push        2    
00401035  push        1    
00401037  call        dword ptr [___defaultmatherr+0Ch (403020h)] 
   (*_bar)(&p);
0040103D  lea         eax,[esp+0Ch] 
00401041  push        eax  
00401042  call        dword ptr [___defaultmatherr+8 (40301Ch)] 
   return p;
00401048  mov         eax,dword ptr [esp+10h] 
}
0040104C  add         esp,14h 
0040104F  ret              
static void *(* _foo)() = foo;


int _tmain(int argc, _TCHAR* argv[])
{
   printf("%p", (*_foo)());
00401050  call        dword ptr [___defaultmatherr+10h (403024h)] 
00401056  push        eax  
00401057  push        offset ___xi_z+30h (4020F4h) 
0040105C  call        dword ptr [__imp__printf (4020A4h)] 
00401062  add         esp,8 
   getchar();
00401065  call        dword ptr [__imp__getchar (40209Ch)] 
        return 0;
0040106B  xor         eax,eax 
}
0040106D  ret    


Although unimportant considering that in real life I would define "a" as a constant instead of expecting it to be detected as such, I'm pretty sure that I had to use volatile and many obstacles to prevent the compiler from omitting code that I wanted it to generate on purpose but this time nothing was needed (besides the indirection for the calls).

Unimportant but unexpected too...
Post 30 Nov 2009, 15:33
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.