gnu@hoptoad.uucp (John Gilmore) (07/02/87)
I was surprised to find this in comp.os.minix: jaime@killer (James da Silva @ The Unix Connection BBS, Dallas, Texas) wrote: > After more than a couple nights of poking around and endless > iterations of re-compiling the kernel, I have gotten Minix to > boot on a 16Mhz Intel-Motherboard 80386 AT. > > The basic incompatibility arises in the vid_copy function, used > to copy text into screen memory. AST uses the 'lock' prefix to > indicate to the PC-Simulator that video memory has changed. The > specific instruction used is 'lock nop'. > > The designers of the 80386 decided to restrict the use of the > lock prefix to certain instructions that read a value from > memory, modify it in some way, then store it back in the same > memory location. In particular, the lock prefix is permitted only > with the following instructions and addressing modes: > > BT, BTS, BTR, BTC mem, reg/immediate > ADD, OR, ADC, SBB, AND, SUB, XOR mem, reg/immediate > XCHG reg, mem > XCHG mem, reg > NOT, NEG, INC, DEC mem > > The 'lock nop' instruction was causing an undefined opcode trap > to occur. Not Pretty. And not easy to find. With the lock nop > instruction commented out, Minix came up without a hitch. It looks like the 386 is compatible with the 8086 in the same sense that the 68010 is compatible with the 68000 -- very close, but a few instructions now cause traps. What surprises me the most is that the address of the undefined opcode after an undefined opcode trap was "not easy to find". On the 68000 series the address of the bad opcode is stacked, and on the 68000, the opcode itself is also stacked. -- {dasys1,ncoast,well,sun,ihnp4}!hoptoad!gnu gnu@ingres.berkeley.edu Alt.all: the alternative radio of the Usenet. Contributions welcome - post 'em
tomk@intsc.UUCP (Tom Kohrs ) (07/02/87)
in article <2353@hoptoad.uucp> gnu@ingres.berkeley.edu writes: > I was surprised to find this in comp.os.minix: > > jaime@killer (James da Silva @ The Unix Connection BBS, Dallas, Texas) wrote: > > After more than a couple nights of poking around and endless > > iterations of re-compiling the kernel, I have gotten Minix to > > boot on a 16Mhz Intel-Motherboard 80386 AT. ... > > The designers of the 80386 decided to restrict the use of the > > lock prefix to certain instructions that read a value from > > memory, modify it in some way, then store it back in the same > > memory location. In particular, the lock prefix is permitted only > > with the following instructions and addressing modes: > > > > BT, BTS, BTR, BTC mem, reg/immediate > > ADD, OR, ADC, SBB, AND, SUB, XOR mem, reg/immediate > > XCHG reg, mem > > XCHG mem, reg > > NOT, NEG, INC, DEC mem > > > What surprises me the most is that the address of the undefined opcode > after an undefined opcode trap was "not easy to find". On the 68000 series > the address of the bad opcode is stacked, and on the 68000, the opcode > itself is also stacked. The reason for the change in the use of the lock instruction prefix had something to do with the pipelining of the 386 that the 8086 did not have. The lock prefix was restricted to make the micro code reasonable with the 6 stage pipeline. As far as the bad opcode trap, it is actually a fault. Subtle difference, in a fault the address of the first byte of the instruction string is pointed to by the return address on the stack. Traps point to the following instruction. The recommended work around for the lock problem is a lookup table in the invalid opcode fault handler that either increments the return address to step over the lock prefix or emulates the instruction with one of the valid lock instuctions. ------ "Ever notice how your mental image of someone you've known only by phone turns out to be wrong? And on a computer net you don't even have a voice..." tomk@intsc.UUCP Tom Kohrs Regional Architecture Specialist Intel - Santa Clara