🚀 go-pugleaf

In article <179@vcvax1.UUCP> tom@vcvax1.UUCP (tom) writes:
> ...
>encountered some rather strange behavior that I now
>attribute to a bug in the Intel 80286 processor.  In
>brief, I suspect that the "popf" instruction enables
>interrupts under certain circumstances even though the
>IF flag is 0 before the instruction is executed and set
>to 0 by the "popf" instruction itself. 
> ...
>
>Tom Scott
>VenturCom, Inc.
>..!seismo!harvard!cybvax0!vcvax1!tom

Believe it or not, this is a documented "feature" or misfeature of the
286 processor (in both protected and real modes).  See page 9-6 of the
IBM PC/AT Technical Reference or (I remember seeing it here) the
appropriate Personal Computer Seminar Proceedings to find out the
exact conditions under which it can occur, but it all has something to
do with the condition "CPL <= IOPL" holding true (I honestly have no
idea what they are talking about here.  I suppose it is some internal
chip condition).

The documented workaround is:

	jmp L1		; jump around iret
L2:	iret		; pop cs,ip, flags
L1:	push cs		; push cs
	call L2		; call near
	....		; program to continue here

which would work for any 80* cpu. They suggest coding this as a macro
which make sense. (I guess you could replace the call near with a call
far and drop the push cs).  I would probably have programmed it as:

	push cs		; save fake cs
	push L2		; push return point (286 only)
	iret		; really just jump ahead one instr with popped flags
L2:	...		; continuation point

if it wasn't going to have to run on anything but a 286 or 186 (push
immediate was new with these) so things at least look linear!

I'm sure you can come up with a dozen different way to accomplish the
same thing now that you know the problem exists.

Charlie C. Kim
User Services