Thread: The real stack __asm{push, pop}

What are you ACTUALLY trying to achieve?

Code:

#include <stdio.h>

int main()
{

#define MAX 100
    int tmp;
    int i;
    
  
    for(i=0; i<MAX; i++)
    {
	__asm__ __volatile__("push %0"::"r"(i));
    }
    
    for(i=0; i<MAX; i++)
    {
	__asm__ __volatile__("pop %0"::"m"(tmp));
	printf("%d\n", tmp);
    };

    return 0;
}

This compiles, but doesn't output the right values. I haven't tried to figure out why, because the code doesn't make sense.

Stack size varies for different OS's, but generally there is "enough" (that is, Windows and Linux gives you a few megabytes of stack, which should be sufficient for any sane application).

--
Mats

All very well, until you want to actually return from the function who's stack frame you've been dickering about with.

So if you're reading from a file, then already you're going to be millions of times slower than reading from memory.

Concentrate on making it "right" before you even begin to thing about making it "fast".

Here's another saying.
It's easier to optimise a working program than it is to make an optimised program work.

Originally Posted by audinue

I think the real stack is faster that our typedef struct Stack... ?

I wouldn't say so. There's no reason for why a push/pop instruction should be faster than a mov instruction (in fact, I would bet they are slower). And as far as I can see, you are going for straight headache (and for no performance gain) if you try to implement a Stack abstract data type using the push/pop instructions.

Plus, you might want to take a look at Intel Software Developper's Manual (begin by taking a look at Volume 1, Section 6.2). And your code is wrong.

That code only works because the compiler does inline those function calls.
If it didn't, you'd be looking at instant crashing.

Originally Posted by audinue

Btw are you using Intel's C/C++ compiler?

No I'm not; I'm either using Visual Studio 2008 Professional (which I got for free) or GCC 4.2.3 (which I also got for free... ), depending on which OS I'm running. Visual Studio is like the only good stuff installed on my Windows system.

I think you are way off in the weeds here and nothing I see will magically make your program faster. First profile, then look at your C/C++ and improve it. Based on what I've seen, I doubt your assembly will be faster than the compiler generated assembly. And what do you mean the real stack? What stack do you think your compiler uses?

Inline assembly may actually be slower because the compiler has no idea what registers you are about to use. Upon return it also does not know what registers you did use. Also you cannot depend on any registers the compiler had been using prior to entry. Because the compiler cannot possibly predict what you are using or what you will use and whether or not you are a good asm programmer and put things back the way they were upon entry to the function it must preserve all registers and flags for inline assembly code. This also means that the compiler will not optimize anything in an asm statement or block since it cannot rely on the state of the flags or registers prior to entry. Also if you are attempting to hand tune the code you would be upset if the compiler magically removed some of it and insisted on using it's version.

In general with modern compilers you should not need to use any inline assembly. I could see using some inline assembly or pure assembly modules in low-level device code but even then C usually suffices in those types of applications.

You used to be able to get good performance gains back in the 80's and early 90's when compilers were not as good. However that day has long since passed. I stopped using assembly when I started into DirectX because I realized the hardware was faster than any asm I could produce and for the most part my assembly routines were purely graphics related or sound related. Now I have no need for assembly save for the occasional pixel or vertex shader written in assembly.

This compiles, but doesn't output the right values. I haven't tried to figure out why, because the code doesn't make sense.

Possibly because we don't know what's on the stack. I've seen C code transform into:

Code:

// Push arguments for function
// Call function
// push arguments for function
// call function
// repeat...
// pop arguments for all above functions. (Usually on leaving a stack frame)

Such behavoir would mess up your custom push/pops, since you're popping on the assumption that the parameters to the function are also popped. (Since most of them are cdecl, the above it a fine calling strategy, trading speed (less pops) for stack space (arguments acumulate).)

But to make the stack empty I see they use add esi, 15 I don't understand this.

To do mass pops, it is often quicker to subtract from esp, than to do multiple pops. (Usually it's a leave, and you get esp being replaced by ebp.)

However, I think as the forum has covered, this is going to be so compiler specific and possibly undefined as to be maddening. Furthermore, it's entirely unportable. Stick to just plain ole C, unless you really need assembly. (And then, I'd try to write it all in a assembly function that exposes a C interface.)

I agree with your analysis onionknight.

There is nothing magical about how the stack itself works - but there is a single instruction to store to memory and decrement (push) and load from memory and increment (pop). The individual instructions will take two instruction slots, which in many architectures would have the capability of executing in the same clock-cycle.

Edit: I started out, but didn't finish it, on a comment explaining that as separate functions, you CAN NOT push and pop the stack - it only works as long as the functions are inlined, and there's nothing preventing the compiler from storing and restoring things from stack locations, and potentially leaving stuff on the stack until later for it's own purposes.

--
Mats