[comp.arch] PUSH on i8088/i80x86

DAVISTD@MSU.BITNET (Tom Davis) (01/05/90)

In debugging some vendor code (:-) I came across what appears to be a subtle
difference between the i8088 and i80x86.  Without an i80x86 manual handy, I
wondered if someone could verify my claim...

On the i8088, a "PUSH SP" decrements SP before pushing it onto the stack.  On
the i80x86, SP is pushed onto the stack before it is decremented (somehow).
Therefore, on the i8088 the following code does not work as expected:

  PUSH SP
  POP  SP

(SP ends up "off by two bytes".)
-------
Tom Davis                 | The above statement shall be construed,
Network Software Services | interpreted, and governed by me alone.
Michigan State University | EMail: davistd@ibm.cl.msu.edu

firth@sei.cmu.edu (Robert Firth) (01/06/90)

In article <182DAVISTD@MSU> DAVISTD@MSU.BITNET (Tom Davis) writes:

>In debugging some vendor code (:-) I came across what appears to be a subtle
>difference between the i8088 and i80x86.  Without an i80x86 manual handy, I
>wondered if someone could verify my claim...
>
>On the i8088, a "PUSH SP" decrements SP before pushing it onto the stack.  On
>the i80x86, SP is pushed onto the stack before it is decremented (somehow).

Well, I just checked my manuals for the 8086, 8088, 80286 and 80386.
As best I can determine, all of them agree on this

. PUSH xxx should decrement SP and then push the value of xxx

. PUSH SP is a legal instruction

. There is no difference among the 80xxx processors in the semantics
  of the PUSH instruction

Now, I may have missed it, or there may be a later revision I haven't
got, but hope this helps anyway.

[ Intel: The 8086 Family User's Manual (1979); iAPX 286 Mocroprocessor
  Architecture Overview (1980); 80386 architecture manual [231630] (1985);
  80376 architecture manual [240182] (1988) ]

dricejb@drilex.UUCP (Craig Jackson drilex1) (01/07/90)

In article <182DAVISTD@MSU> DAVISTD@MSU.BITNET (Tom Davis) writes:
<In debugging some vendor code (:-) I came across what appears to be a subtle
<difference between the i8088 and i80x86.  Without an i80x86 manual handy, I
<wondered if someone could verify my claim...
<
<On the i8088, a "PUSH SP" decrements SP before pushing it onto the stack.  On
<the i80x86, SP is pushed onto the stack before it is decremented (somehow).
<Therefore, on the i8088 the following code does not work as expected:
<
<  PUSH SP
<  POP  SP
<
<(SP ends up "off by two bytes".)
<-------
<Tom Davis                 | The above statement shall be construed,
<Network Software Services | interpreted, and governed by me alone.
<Michigan State University | EMail: davistd@ibm.cl.msu.edu

The behavior of "PUSH SP" was one of the documented differences between the
808[68] and its succcessors... this should be documented in an 80186 or
80286 manual.
-- 
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}

gordonl@microsoft.UUCP (Gordon LETWIN) (01/09/90)

In article <5524@bd.sei.cmu.edu>, firth@sei.cmu.edu (Robert Firth) writes:
> 
> Well, I just checked my manuals for the 8086, 8088, 80286 and 80386.
> As best I can determine, all of them agree on this
      .....
> . There is no difference among the 80xxx processors in the semantics
>   of the PUSH instruction

This is totally wrong.  It's a fact that the handling of "push sp" differs
between some of these processors.  I forget which does what and am too
lazy to look it up, but this is *fer sure* listed in a difference table
that Intel has somewhere.  And I've seen it used as part of a "identify
processor" subroutine.

	Gordon letwin
	Microsoft

firth@sei.cmu.edu (Robert Firth) (01/09/90)

In article <5524@bd.sei.cmu.edu>, firth@sei.cmu.edu I wrote:

> Well, I just checked my manuals for the 8086, 8088, 80286 and 80386.
> As best I can determine, all of them agree on this
      .....
> . There is no difference among the 80xxx processors in the semantics
>   of the PUSH instruction

In article <10190@microsoft.UUCP> gordonl@microsoft.UUCP (Gordon LETWIN) writes:

>This is totally wrong.  It's a fact that the handling of "push sp" differs
>between some of these processors.  I forget which does what and am too
>lazy to look it up, but this is *fer sure* listed in a difference table
>that Intel has somewhere.  And I've seen it used as part of a "identify
>processor" subroutine.

It may well, indeed, be totally wrong.  However, given that I went to
the trouble actually to extract the documents, reread them, and post to
the net their citations, including title, date, and order number, it
seems to me that it would be a matter of simple courtesy, both to me
and to the net, if you would take the same trouble before issuing a
public contradiction.  Our opinions, even our FER SURE opinions, are
pretty useless otherwise.

sc@qmet.UUCP (Steve Croft) (01/10/90)

Well, to clear things up...  here is an extract from the Intel iAPX 286
Programmer's Reference Manual 1984, Appendix D (iAPX 86/88 Software
Compatibility Considerations), page D-2:

	8.  Do not Rely on the Value Written by PUSH SP.

	    The iAPX 286 will push a different value on the stack for
	    PUSH SP than the iAPX 86/88.  If the value pushed is
	    important, replace PUSH SP instructions with the
	    following three instructions:
	    PUSH BP
	    MOV  BP,SP
	    XCHG BP,[BP]
	    This code functions as the iAPX 86/88 PUSH SP instruction
	    on the iAPX 286.


Steve
-- 
******************************************************************************
*   If what I say is not correct,    *      Steve Croft, Qualimetrics, Inc.  *
*       then it's not what I meant!  *      (ucbvax!ucdavis!csusac!qmet!sc)  *
******************************************************************************

nfs@notecnirp.Princeton.EDU (Norbert Schlenker) (01/10/90)

In article <5550@bd.sei.cmu.edu| firth@sei.cmu.edu (Robert Firth) writes:
|In article <5524@bd.sei.cmu.edu>, firth@sei.cmu.edu I wrote:
|
|> Well, I just checked my manuals for the 8086, 8088, 80286 and 80386.
|> As best I can determine, all of them agree on this
|      .....
|> . There is no difference among the 80xxx processors in the semantics
|>   of the PUSH instruction
|
|In article <10190@microsoft.UUCP> gordonl@microsoft.UUCP (Gordon LETWIN) writes:
|
|>This is totally wrong.  It's a fact that the handling of "push sp" differs
|>between some of these processors.  I forget which does what and am too
|>lazy to look it up, but this is *fer sure* listed in a difference table
|>that Intel has somewhere.  And I've seen it used as part of a "identify
|>processor" subroutine.
|
|It may well, indeed, be totally wrong.  However, given that I went to
|the trouble actually to extract the documents, reread them, and post to
|the net their citations, including title, date, and order number, it
|seems to me that it would be a matter of simple courtesy, both to me
|and to the net, if you would take the same trouble before issuing a
|public contradiction.  Our opinions, even our FER SURE opinions, are
|pretty useless otherwise.

This is verbatim from Intel's 80386 Programmer's Reference Manual.
The book is Intel order number 230985-001.  Intel's number is 800-548-4725.

Section 14.7.  Differences from 8086
...
4.  Value written by PUSH SP.

    The 80386 pushes a different value on the stack for PUSH SP than the
    8086/8088.  The 80386 pushes the value of SP before SP is incremented
    as part of the push operation; the 8086/8088 pushes the value of SP
    after it is incremented.  If the value pushed is important, replace
    PUSH SP instructions with the following three instructions:

	PUSH BP
	MOV  BP, SP
	XCHG BP, [BP]

    This code functions as the 8086/8088 PUSH SP instruction on the 80386.

There are similar sections in both the 80186 and 80286 programmer's
reference manuals.  Look for "Differences" in the table of contents.

Norbert

rob@prism.TMC.COM (01/10/90)

dricejb@drilex.UUCP writes:

>In article <182DAVISTD@MSU> DAVISTD@MSU.BITNET (Tom Davis) writes:
><In debugging some vendor code (:-) I came across what appears to be a subtle
><difference between the i8088 and i80x86...
><On the i8088, a "PUSH SP" decrements SP before pushing it onto the stack. On
><the i80x86, SP is pushed onto the stack before it is decremented (somehow).
><Therefore, on the i8088 the following code does not work as expected:
><
><  PUSH SP
><  POP  SP
><
><(SP ends up "off by two bytes".)

>The behavior of "PUSH SP" was one of the documented differences between the
>808[68] and its succcessors... this should be documented in an 80186 or
>80286 manual.

   For what it's worth, I think the 286 was the first one to push SP
before decrementing it. The 8088/6 and 80188/6 decrement SP, then push
it.

   Only Intel knows for sure, but it's a guess that, aside from making the 
PUSH SP / POP SP pair behave more logically, the newer method allows the
CPU to detect a stack overrun before SP gets changed. The difference is
fairly clearly documented, though. One of Intel's 'compatibility rules'
is something like 'Don't rely on the value put on the stack by PUSH SP'.

md89mch@cc.brunel.ac.uk (Martin Howe) (01/11/90)

In article <5524@bd.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes:

>>On the i8088, a "PUSH SP" decrements SP before pushing it onto the stack.  On
>>the i80x86, SP is pushed onto the stack before it is decremented (somehow).

In the iAPX-286 manual, I remember it saying that the 802[and presumable 34]86
pushes a DIFFERENT value for SP onto the stack from that pushed by the
8086/8088. I don't know about the 186 and I've never heard of any 8086/8088
difference, since they have the same execution units.

On a '286, though
	PUSH BP
	MOV  BP,SP
	XCHG BP,[BP]
is supposed to emulate the behaviour of the 8086/8088's PUSH SP, 
at least according to Intel.

I hope this helps.
Regards,
-- 
Martin C. Howe           | "Motorhead will be the DIRTIEST band in
MSc. Microelectronics    |  Rock N' Roll. If this band moved in next door,
System Design, Brunel U. |  your lawn would die." - Kilminster
Any unattributed opinions are mine, but YOU can have them today for just $20 !

dricejb@drilex.UUCP (Craig Jackson drilex1) (01/11/90)

In article <5550@bd.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes:
>In article <5524@bd.sei.cmu.edu>, firth@sei.cmu.edu I wrote:
>
>> Well, I just checked my manuals for the 8086, 8088, 80286 and 80386.
>> As best I can determine, all of them agree on this
>      .....
>> . There is no difference among the 80xxx processors in the semantics
>>   of the PUSH instruction
>
>In article <10190@microsoft.UUCP> gordonl@microsoft.UUCP (Gordon LETWIN) writes:

   (Someone well-known to be familiar with the 80x8x architecture.)

>
>>This is totally wrong.  It's a fact that the handling of "push sp" differs
>>between some of these processors.  I forget which does what and am too
>>lazy to look it up, but this is *fer sure* listed in a difference table
>>that Intel has somewhere.  And I've seen it used as part of a "identify
>>processor" subroutine.
>
>It may well, indeed, be totally wrong.  However, given that I went to
>the trouble actually to extract the documents, reread them, and post to
>the net their citations, including title, date, and order number, it
>seems to me that it would be a matter of simple courtesy, both to me
>and to the net, if you would take the same trouble before issuing a
>public contradiction.  Our opinions, even our FER SURE opinions, are
>pretty useless otherwise.

I have here in my hand a document, entitled "iAPX 286 Programmer's Reference
Manual Including the iAPX 286 Numeric Supplement", dated 1984, published by
the intel Corporation.

It contains an chapter, Appendix D, entitled "iAPX 86/88 Software
Compatibility Considerations".

Item number 8 in that chapter is labelled "Do not Rely on the Value Written
by PUSH SP."

The first sentence reads: "The iAPX 286 will push a different value
on the stack for PUSH SP than the iAPX 86/88."

It goes on to give some sample code
which gives the same answer in both
architechtures.  It is reproduced
here in the interest of satisfying
inews' line counter.

    PUSH BP
    MOV  BP,SP
    XCHG BP,[BP]

I hope we can all put this issue
to bed now.

I also hope that inews will now accept
this article.
-- 
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}

gordonl@microsoft.UUCP (Gordon LETWIN) (01/13/90)

In article <5550@bd.sei.cmu.edu>, firth@sei.cmu.edu (Robert Firth) writes:
> In article <5524@bd.sei.cmu.edu>, firth@sei.cmu.edu I wrote:
> 
> > . There is no difference among the 80xxx processors in the semantics
> >   of the PUSH instruction
> 
> In article <10190@microsoft.UUCP> gordonl@microsoft.UUCP (Gordon LETWIN) writes:
> 
> >This is totally wrong.  It's a fact that the handling of "push sp" differs
> 
> It may well, indeed, be totally wrong.  However, given that I went to
> the trouble actually to extract the documents, reread them, and post to
> the net their citations, including title, date, and order number, it
> seems to me that it would be a matter of simple courtesy, both to me
> and to the net, if you would take the same trouble before issuing a
> public contradiction.  


Nah.  The key fact here is that I'm right.  I'm doing a "service" to the
net by warning folks that your "authoritative" posting is N.F.G., so that
some day someone won't get caught out on this.

I don't care what expectations, demands, or requirements you may have on
me.  It's ridiculous to assert that I'm "discourteous" because I don't
do what you expect of me.  In my case, I expect folks in this "babel" forum
to be right or to be quiet.  You don't meet those expectations.

THis isn't a timely topic and is therefore of minimial interest, I just
took a quick moment in case there was anyone who might believe - and later
rely - upon your erronious information.

If you want to talk courtesy, then talk about how courtious it is to
do negligent research and then to post it as authoritative.

	gordon


(The order number of this reply is : "BUZZ-12-45/Qr-OFF".  That compenstates
	for any other failing - such as being totally wrong - that it may have.

ldo@waikato.ac.nz (Lawrence D'Oliveiro) (01/15/90)

This problem with pre/post-decrementing of SP in the Intel CPUs--
there's another chip family with this quirk too. The analogous
sequence

	mov	sp, -(sp)

is supposed to give different results on different members of
the PDP-11 family. I may be wrong (it's been a while since I've
programmed a PDP-11) but the behaviour might occur if you replace
SP with any of the other registers, as well.

Anybody else remember this? Or am I just showing my age?

Lawrence D'Oliveiro
Computer Services Dept
Waikato University
Hamilton
New Zealand

sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz) (01/16/90)

In article <1990Jan15.064658.1816@waikato.ac.nz> ldo@waikato.ac.nz (Lawrence D'Oliveiro) writes:
>This problem with pre/post-decrementing of SP in the Intel CPUs--
>there's another chip family with this quirk too. The analogous
>sequence
>
>	mov	sp, -(sp)
>
>is supposed to give different results on different members of
>the PDP-11 family...
>
>Anybody else remember this? Or am I just showing my age?

	I remember it well.  This is the (in)famous "Z" error which the
	assembler uses to flag such instructions.  The pdp-11/44, 45, 70 do
	not suffer from this peculiarity but the 11/40 and members of the
	micro-pdp11 family do.
	do.

	Steven M. Schultz
	sms@wlv.imsd.contel.com

henry@utzoo.uucp (Henry Spencer) (01/16/90)

In article <1990Jan15.064658.1816@waikato.ac.nz> ldo@waikato.ac.nz (Lawrence D'Oliveiro) writes:
>	mov	sp, -(sp)
>
>is supposed to give different results on different members of
>the PDP-11 family. I may be wrong...

Nope, you're correct.  Using the same register as the source and as the
subject of autoinc/dec in the destination gives model-specific results
on the 11.  There are two or three other such fuzzy spots.
-- 
1972: Saturn V #15 flight-ready|     Henry Spencer at U of Toronto Zoology
1990: birds nesting in engines | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

johnl@n3dmc.UU.NET (John Limpert) (01/16/90)

In article <1990Jan15.064658.1816@waikato.ac.nz> ldo@waikato.ac.nz (Lawrence D'Oliveiro) writes:
>This problem with pre/post-decrementing of SP in the Intel CPUs--
>there's another chip family with this quirk too. The analogous
>sequence
>
>	mov	sp, -(sp)
>
>is supposed to give different results on different members of
>the PDP-11 family. I may be wrong (it's been a while since I've
>programmed a PDP-11) but the behaviour might occur if you replace
>SP with any of the other registers, as well.
>
>Anybody else remember this? Or am I just showing my age?

You are correct.  The LSI-11 processor handbook had a handy
list of the differences in CPU implementation for the PDP-11
family.

Here is the note from the MACRO-11 manual:

	Certain special instruction/address mode
	combinations, which are rarely or never
	used, do not operate the same on all
	PDP-11 processors, as described below.

	In the autoincrement mode, both the JMP
	and JSR instructions autoincrement the
	register before its use on the PDP-11/40
	but not on the PDP-11/45 or PDP-11/10.

	In double operand instructions having
	the addressing form Rn,(Rn)+ or
	Rn,-(Rn), where the source and
	destination registers are the same, the
	source operand is evaluated as the
	autoincremented or autodecremented
	value, but the destination register, at
	the time it is used, still contains the
	originally intended effective address.

	The use of these forms should be
	avoided, since they are not compatible
	with the entire family of PDP-11
	processors.

-- 
John A. Limpert			I'm the NRA!
Internet: johnl@n3dmc.UU.NET	UUCP: uunet!n3dmc!johnl

don@gp.govt.nz (10/28/90)

In article <1990Jan15.064658.1816@waikato.ac.nz>, ldo@waikato.ac.nz (Lawrence D'Oliveiro) writes:
> This problem with pre/post-decrementing of SP in the Intel CPUs--
> there's another chip family with this quirk too. The analogous
> sequence
> 
> 	mov	sp, -(sp)
> 
> is supposed to give different results on different members of
> the PDP-11 family. I may be wrong (it's been a while since I've
> programmed a PDP-11) but the behaviour might occur if you replace
> SP with any of the other registers, as well.
> 
> Anybody else remember this? Or am I just showing my age?

Yup, and yes, it does affect all registers (did you expect otherwise? SP
is just another name for R6 after all).  According to my Microcomputer
Processor Handbook (deals with LSI-11 processors), on the LSI-11/23,
PDP-11/15, 11/20, 11/35 & 11/40, an instruction along the lines of MOV
Rn, (Rn)+ or MOV Rn, -(Rn) results in Rn being incremented or decremented
before being used as the source operand, whereas on the LSI-11,
PDP-11/04, 11/05, 11/10, 11/34 and 11/45 (that's all this book, circa
1979, mentions), the initial contents of the source operand are used. 
The same goes for things like MOV Rn, @(Rn)+. 

There are quite a large number of differences between different PDP-11 
models - the table of differences runs to 12 pages.

Don Stokes  ZL2TNM    /  /                               vuwcomp!windy!gpwd!don
Systems Programmer   /GP/ Government Printing Office <-- until 31-Jan-1990
__(and_Postmaster)__/  /__Wellington__New_Zealand________don@gp.govt.nz________
The number of errors is proportional to the number of people watching.