Page 1 of 1
Pushing IP *solved*
Posted: Sat Dec 06, 2008 11:19 pm
by LoseThos
The x86 does not have [esp] addressing modes. That's on VAXs and stuff. x86 has [RBP]
I happen to use
I have had problems with pipelining in similar situations on older pentium series machines, but this call/pop hasn't presented problems. I don't remember if I stuck code between the call and label. I think I did, but I don't think it matters.
If it is 16 bit code it's pop ax.
Re: Pushing IP *solved*
Posted: Sun Dec 07, 2008 12:37 am
by Brendan
Hi,
LoseThos wrote:The x86 does not have [esp] addressing modes. That's on VAXs and stuff. x86 has [RBP]
80x86 does have "[esp]" addressing modes, and will even handle something like "mov eax,[esp+ebx*4+12345]".
However, 80x86 doesn't have "[sp]" addressing modes, but (for 80386 and later) it's easy enough to do "movzx esp,sp" (to make sure that ESP = SP) and use the 32-bit form.
LoseThos wrote:I happen to use
I have had problems with pipelining in similar situations on older pentium series machines, but this call/pop hasn't presented problems. I don't remember if I stuck code between the call and label. I think I did, but I don't think it matters.
This is about branch prediction - think of a RET instruction as "jmp [esp]; add esp,4" and you'll realize that RET *is* an unconditional branch. You won't find a pipeline stall or anything where this code is, but you will find problems later. For example:
Code: Select all
main:
call foo
ret ;Branch mis-prediction here because CPU's "return address stack" was trashed
foo:
call bar
ret ;Branch mis-prediction here because CPU's "return address stack" was trashed
bar:
nop
nop
call .label
.label:
pop eax ;No problem here
nop
nop
nop
ret ;Branch mis-prediction here because CPU's "return address stack" was trashed
Don't take my word for it - take Intel's word. From (my copy of) Intel's "IA-32 Intel Architecture Optimization Reference Manual":
Intel wrote:Inlining, Calls and Returns
The return address stack mechanism augments the static and dynamic predictors to optimize specifically for calls and returns. [Some stuff skipped]
To enable the use of the return stack mechanism, calls and returns must be matched in pairs. If this is done, the likelihood of exceeding the stack depth in a manner that will impact performance is very low.
Assembler/Compiler Coding Rule 4. (MH impact, MH generality) Near calls must be matched with near returns, and far calls must be matched with far returns. Pushing the return address on the stack and jumping to the routine to be called is not recommended since it creates a mismatch in calls and returns.
Cheers,
Brendan
Re: Pushing IP *solved*
Posted: Sun Dec 07, 2008 12:48 am
by LoseThos
do it your way. I don't care. I use call pop. Rules can change each generation, so why worry? Whatever you want to call what I called "pipelining" got fixed and was no longer a problem. Why don't you suggest he use the absolute address with a $?
Re: Pushing IP *solved*
Posted: Sun Dec 07, 2008 1:35 am
by LoseThos
What this really is about is you trying to trap me into something. I wrote my own bootloader and used call pop. It relocates itself. You are some paranoid person of bare metal hardware and feel threatened by my boot loader doing bare metal.
You are trying to entrap me. I said x86. On the first generations, call pop worked. Intel changed the rules. They can change them in the future.
I experienced problems with an indirect call mechanism which placed the funcation address on the stack and called indirectly
push function address
push other parameters
mov eax, address of the function address
call [eax]
that had a pipeling problem on some generations, but not others and was definitely not acceptable until i moved to x86_64 or better hardware, unless they change the rules.
You downloaded some of the old versions of losethos and saw that.
God says...
y beginning to enliven the
valleys again, and no doubt the marriage will take place in the cool of
the morning, and not in the heat of the afternoon."
Sancho did as his master bade him, and putting the saddle on Rocinante
and the pack-saddle on Dapple, they both mounted and at a leisurely pace
entered the arcade. The first thing that presented itself to Sancho's
eyes was a whole ox spitted on a whole elm tree, and in the fire at which
it was to be roasted there was burning a middling-sized mountai
Re: Pushing IP *solved*
Posted: Sun Dec 07, 2008 7:24 am
by Brendan
Hi,
LoseThos wrote:What this really is about is you trying to trap me into something. I wrote my own bootloader and used call pop. It relocates itself. You are some paranoid person of bare metal hardware and feel threatened by my boot loader doing bare metal.
You are trying to entrap me. I said x86. On the first generations, call pop worked. Intel changed the rules. They can change them in the future.
Intel's 80x86 CPUs have had a return address stack since Pentium (1993) and possibly earlier. Other 80x86 CPU manufacturers do the same thing, including AMD and Cyrix (who stopped making CPUs a long time ago). I didn't bother doing much research though - it's an obvious optimization that I'd expect all current CPU manufacturers for all CISC CPUs use. IMHO it's also an obvious optimization that will never disappear.
The first few generations of 80x86 (e.g. 8086, 8088) didn't have a return address stack, but they didn't have any caches either, and didn't need any of this stuff because the memory was as fast as the CPU. Nobody really cares about the first few generations anymore though..
LoseThos wrote:I experienced problems with an indirect call mechanism which placed the funcation address on the stack and called indirectly
LoseThos wrote:You downloaded some of the old versions of losethos and saw that.
For the record, I've never downloaded any version of your OS. My original comments were about consequences anybody can expect - it's like seeing someone standing in the rain and telling them they'll get wet - some things are easy to predict.
LoseThos wrote:God says...
God says that if you're not smart enough to write a rational response, just make up stuff that has nothing to do with anything...
Cheers,
Brendan
Re: Pushing IP *solved*
Posted: Sun Dec 07, 2008 7:46 am
by quirck
Instead of
this may be used:
Code: Select all
.eip2eax:
pop eax
push eax
ret
; ...
call .eip2eax
This must not lead to branch misprediction.
Re: Pushing IP *solved*
Posted: Sun Dec 07, 2008 8:32 am
by Love4Boobies
Brendan wrote:LoseThos wrote:God says...
God says that if you're not smart enough to write a rational response, just make up stuff that has nothing to do with anything...
Pwned.
Re: Pushing IP *solved*
Posted: Sun Dec 07, 2008 9:09 am
by Stevo14
LoseThos wrote:
y beginning to enliven the
valleys again, and no doubt the marriage will take place in the cool of
the morning, and not in the heat of the afternoon."
Sancho did as his master bade him, and putting the saddle on Rocinante
and the pack-saddle on Dapple, they both mounted and at a leisurely pace
entered the arcade. The first thing that presented itself to Sancho's
eyes was a whole ox spitted on a whole elm tree, and in the fire at which
it was to be roasted there was burning a middling-sized mountai
Funny enough, this is actually a passage from the English translation of Don Quixote. Chapter 20, paragraph 7.
Brendan wrote:
God says that if you're not smart enough to write a rational response, just make up stuff that has nothing to do with anything...
Or copy paste it from the internet.
Seriously, LoseThos, I'm a Christian and false crap like this is very annoying. Please stop.
Re: Pushing IP *solved*
Posted: Sun Dec 07, 2008 11:13 am
by Troy Martin
Love4Boobies wrote:Brendan wrote:LoseThos wrote:God says...
God says that if you're not smart enough to write a rational response, just make up stuff that has nothing to do with anything...
Pwned.
Oh dear "God" he's quoting the bible again. Good thing it was split and it's not in my thread.
Funny enough, this is actually a passage from the English translation of Don Quixote. Chapter 20, paragraph 7.
ROFLMAO!