SM>  *** Glen McNabb wrote in a message to Scott McNay:
SM> 
SM> SM> The 808x and 8018x have the PUSH SP bug, where the wrong value of SP 
SM> is 
SM> SM> pushed.
SM> SM>   PUSH SP
SM> SM>   POP AX
SM> SM>   CMP AX,SP
SM> SM>   JNE Bug
SM> GM> Really... Seems to me the SP changes value in a push. Which
SM> GM> is what it's supposed to do. If would seem to me, to be
SM> GM> asking for a problem. 
SM> It does, as you can see from the code above.  If you think about it, 
SM> you'll realize that if you take a value off the stack after it has been 
SM> pushed, it should be the same value that it was before the push started.  
SM> Example:
SM>  :LP
SM>  PUSH SP
SM>  POP SP
SM>  JMP LP
SM> will eventually die from overwriting the program or overflowing the 
ack.
According to my manual on the 8088...
Push.... SP = SP - 2.... then.... top of stack = operand
Pop .... operand = top of stack...  then.... SP = SP + 2
Because of a before/after SP change I could see where this would happen.
SM> SM> There's a difference between the 808x and 8018x, in which if you
SM> write a
SM> SM> word to xxxx:FFFF, on the 808x, the second byte will appear at 
SM> xxxx:0000 
SM> SM> and on the 8018x, the second byte will appear at xxxx:10000 (Note 
SM> five 
SM> SM> digits there).  My notes say something about V86 mode; apparently V86 
SM> SM> memory managers trap this but don't emulate it, but would have to 
SM> verify 
SM> SM> this.  I guess I need to fiddle with my CPUID program a bit more and 
SM> SM> clarify the note. SM>  
SM> 
SM> GM> I would think you'd get a segment overflow interupt if that
SM> GM> was the case. 
SM> 
SM> In V86 mode, yes, but apparantly most V86 memory managers don't attempt 
SM> to emulate it or check to see if the application program has its' own 
SM> handler, they just trap it and complain.
Ah... ok...
SM> SM> After a MUL, the 808x always sets ZF=0, while the V20/V30 leaves ZF 
SM> alone.
SM> 
SM> GM> Actually the 808x does this correct. On any multiply it
SM> GM> would with 2 exceptions. 1. if you multiplied by zero. In
SM> GM> which case the result is 0. 2. if the values multiplied
SM> GM> overflowed the AX (for 8 bit) or DX:AX (for 16 bit) where
SM> GM> the result was 0 in the register(s). I discovered this when
SM> GM> making a random number generator that used a division after
SM> GM> multiplicitive method.
SM> In that case, I should change the wording to say "sets ZF appropriately".
Yup... as for the NEC, during a multiply you wouldn't usually follow it
by a JZ, JNZ, JE, JNE instuction so it's rather mute...
SM> SM> On the 808x/NEC, when doing a shift/rotate, the 808x/NE will actually
SM> SM> execute the number of times specified.  On 8018x and higher, the 
SM> count is 
SM> SM> masked off to the # of bits in the register.
SM> GM> That depended on the contents of the carry/borrow flag if I
SM> GM> remember correctly...
SM> Doesn't matter, the difference exists, and thus the newer CPUs give what 
SM> most people would consider incorrect results, except that it's explicitly 
SM> stated that they operate in this way.
Somehow that's quite believable. :)
SM> GM> This can be done better by reading words across the odd/even
SM> GM> address boundry...
SM> That's exactly what I said...  If you read a word from an odd address, 
SM> the read will go across the odd/even boundary.
I was thinking it didn't make a difference to an 8088/188... it would take
the same time either way... (you did list those) but, I could be
wrong too.
SM> SM> On the 808x, when loading SS, an interrupt can occur before SP is 
SM> loaded, 
SM> GM> Reliably, a well written interrupt will not use the current
SM> GM> stack for that reason.
SM> You must be talking about something else...  it sounds like you're 
SM> talking about stack overflow.  In this case, for reliability, you'd want 
SM> to NOT change stacks, to avoid the chances of a NMI coming along at the 
SM> wrong moment and killing your program.
Not really, that's where the biggest danger exists. If I was changing
the SS and an interupt occured, it would push the CS,IP,FLAGS into
the stack to service the interupt. Thereby, corrupting unknown memory.
The thing to do is disable the interupts first, load the stack as
fast as possible (least clocks) and restore interupts. Also, if you
really want to be safe, make sure the interupts uses a known stack
as much as possible, check the DMA count is high enough before you
do. It's really important for interupt routines in a multitasking
environment...
SM> SM> On the 808x, PUSHA is interpreted as JMP $+2 (effectively a NOP).  On 
SM> the 
SM> SM> V20/V30/80x8x chips, it's a PUSHA.
OK
SM> GM> As far as I know the PUSHA was not a part of the 808x
SM> GM> instruction set. 
SM> It wasn't there as PUSHA, certainly; it was there as a subset of another 
SM> instruction, the effect was JMP $+2.
Glen..
--- ProBoard v2.16 [Reg]
---------------