Printable View
Let's play with the real stack...And I confusing on these:Code:#define MAX 100
int tmp;
for(int i=0; i<MAX; i++)
{
_asm
{
push i
};
};
for(int i=0; i<MAX; i++)
{
_asm
{
pop tmp
};
printf("%d ", tmp);
};
1. How much limit of the stack(quantity(push 1,push 2,push 3,push 4) and the size(push LONG_LONG_MAX?))?
2. GCC syntax, please?
Btw, thanks in advance. I'm very noob in C-inline-assembly.
What are you ACTUALLY trying to achieve?
This compiles, but doesn't output the right values. I haven't tried to figure out why, because the code doesn't make sense.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;
}
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
I think the real stack is faster that our typedef struct Stack... :) ?
All very well, until you want to actually return from the function who's stack frame you've been dickering about with.
Btw it prints out 99 to 0...
My reason to use stack, I'm now working on parser, and speed of the stack is a critical thing, yeah, you know, even shunting down algorithm need a stack, scanner need stack of tokens, etc...
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.
I already done my code. So I want to make it faster. Maybe using inline assembly stack opcodes (push and pop)...
Btw, again...
This works well on me...Quote:
All very well, until you want to actually return from the function who's stack frame you've been dickering about with.
We should add a counter that count how much stack we already use and then empty it by popping loop...Code:void push(long t)
{
__asm
{
push t
};
};
int pop()
{
int i;
__asm
{
pop i
};
return i;
}
int main()
{
push(10);
push(20);
push(30);
int i;
i = pop();
printf("%d\n", i);
i = pop();
printf("%d\n", i);
i = pop();
printf("%d\n", i);
}
But to make the stack empty I see they use add esi, 15 I don't understand this.
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.Quote:
Originally Posted by audinue
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.
Thanks foxman for the info.
Btw are you using Intel's C/C++ compiler? How about the produced exe-size, libraries, speed, documentation(manual + reference)?
If it's good, I'll buy it (~^_^~)*
That code only works because the compiler does inline those function calls.
If it didn't, you'd be looking at instant crashing.
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.Quote:
Originally Posted by audinue
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.
Possibly because we don't know what's on the stack. I've seen C code transform into:Quote:
This compiles, but doesn't output the right values. I haven't tried to figure out why, because the code doesn't make sense.
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).)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)
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.)Quote:
But to make the stack empty I see they use add esi, 15 I don't understand this.
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.)
Correct me if I'm wrong, but I think the x86 stack is fast mostly because it's a flat array, and because it has specific instructions for pushing and popping. If you want a fast stack, just mimic that for your own stack type.
Code:#include <stdio.h>
#define MAX 100
struct my_stack {
int stack[MAX];
int* pos;
};
void my_stack_init (struct my_stack* s) {s->pos = s->stack;}
void my_stack_push (struct my_stack* s, int v) {*s->pos = v; s->pos++;}
int my_stack_pop (struct my_stack* s) {s->pos--; return *s->pos;}
int main (void)
{
struct my_stack stack;
int i;
my_stack_init(&stack);
for (i = 0; i < MAX; i++)
my_stack_push(&stack, i);
for (i = 0; i < MAX; i++)
printf("%d ", my_stack_pop(&stack));
putchar('\n');
return 0;
}
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
Don't try to be clever using inline assembly instructions, there is absolutely no reason to. It is naive to think that substituting good C code for some assembly instructions just to possibly gain a few clock cycles of performance is a good idea. As Salem stated, if the compiler does not inline those functions, your code will blowup.