Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Wierd Instructions.

46 views
Skip to first unread message

Mike Kinney

unread,
Oct 6, 1994, 10:33:11 PM10/6/94
to
I used to do a bit of assembler on Apple IIs (65c02), and I read once
about several odd instructions, with insane mnemonics. One example, HCF,
would compleatly trash all 3 registers, and hang everything. It stood for
"Halt and Catch Fire". What I'm wondering is, is there anything similar
in the x86 line, particularly the 80x8 and the 186? Why the older chips?
Because I'm thinking that stuff like this is easier for an engineer to
get away with when the company is smaller.... Anyway, just wondering, out
of hackish curiosity. Thanks for any info...
--Bird

David Emrich

unread,
Oct 8, 1994, 2:54:40 AM10/8/94
to
bi...@iac.net (Mike Kinney) writes:

First: those "odd mnemonics" were not part of the original 6502 code
set. They were coined by curious hackers who spent innumerable
hours trying "undocumented" opcodes out to see what effect they
had, by setting up values in the registers and memory, running
an instruction and figuring out what changed. A mate of mine
actually found some sort of useful ones that he wrote a "manual"
extension for, in 6502 format! (Looked like an addendum!)

Second: HCF was an opcode that was used on some really archaic hardware
well before apples were even thought of. It really did halt and
catch fire, on one machine, since what it did (if not used
properly) was to enter a tight loop which was not interruptable
or resettable, and since the machine used core memory, the
repetetive access to the same core locations heated up the
to the point where the wires would melt, causing short circuits,
and driver chips would begin to smoke!

Third: You'll only find such opcodes on the 8086/186 since the 286 and
better have implemented an undefined instruction trap which
causes a routine to be called whenever one of these instructions
that is not a "legal" Intel instruction is executed. That is,
if there are any at all! Most of the ones that I tried just
cause the 8086 or 80186 to shutdown, leaving the bus in a halted
state (as if some other processor had taken it over). (Try POP
CS! The "hole" exists in the instruction set, since there are
PUSH CS/DS/ES and SS instructions and only POP DE/ES or SS).

Hope this sheds some light!

Dave
emr...@lethe.uwa.edu.au

Frank Lofaro

unread,
Oct 8, 1994, 6:53:50 PM10/8/94
to
In article <375fng$9...@styx.uwa.edu.au> emr...@tartarus.uwa.edu.au (David Emrich) writes:
>
>Third: You'll only find such opcodes on the 8086/186 since the 286 and
> better have implemented an undefined instruction trap which
> causes a routine to be called whenever one of these instructions
> that is not a "legal" Intel instruction is executed. That is,
> if there are any at all! Most of the ones that I tried just
> cause the 8086 or 80186 to shutdown, leaving the bus in a halted
> state (as if some other processor had taken it over). (Try POP
> CS! The "hole" exists in the instruction set, since there are
> PUSH CS/DS/ES and SS instructions and only POP DE/ES or SS).
>

Hmm, executing 0xf1 on my Intel 486DX/33 from ring 3 in protected mode
results in not an int 0x6 (Illegal Instruction), but instead either an
int 0x01 or an int 0x03 (I am doing this under Linux, and thus can't tell
the difference without a lot of work).


Chris Page

unread,
Oct 8, 1994, 9:54:11 PM10/8/94
to

Just a side note: the HCF "instruction" is probably an unimplemented
instruction opcode whose behavior varies according to the specific
implementation of the 6502 on which it is executed. Many CPUs have such
undefined instructions and they are mainly useful for trivia questions.

--
Chris Page "I got a Power Macintosh...
Adobe Systems Incorporated ...now what?" -- Me
cp...@mv.us.adobe.com

Disclaimer: opinions expressed are not necessarily those of my employer.

Kevin Marcus

unread,
Oct 10, 1994, 4:45:42 AM10/10/94
to
In article <cpage-08109...@paleface.mv.us.adobe.com>,

Chris Page <cp...@mv.us.adobe.com> wrote:
>In article <372c17$a...@great-miami.iac.net>, bi...@iac.net (Mike Kinney) wrote:
>
>> in the x86 line, particularly the 80x8 and the 186? Why the older chips?
>> Because I'm thinking that stuff like this is easier for an engineer to
>> get away with when the company is smaller.... Anyway, just wondering, out

Well, there is no single instruction that does exactly that, however,
youc an definitely lock up your CPU with

CLI
HLT

--
--> Kevin Marcus, Computer Science Dept., University of California, Riverside
Email: dat...@cs.ucr.edu.
.. "Two types of programs do CALL <next instr>; POP <index reg>. They are
viruses and a good chunk of DOS programs. Down with MicroSloth."

Zsoter Andras

unread,
Oct 11, 1994, 2:06:27 AM10/11/94
to
David Emrich (emr...@tartarus.uwa.edu.au) wrote:
: bi...@iac.net (Mike Kinney) writes:
: better have implemented an undefined instruction trap which

: causes a routine to be called whenever one of these instructions
: that is not a "legal" Intel instruction is executed. That is,
: if there are any at all! Most of the ones that I tried just
: cause the 8086 or 80186 to shutdown, leaving the bus in a halted
: state (as if some other processor had taken it over). (Try POP
: CS! The "hole" exists in the instruction set, since there are
: PUSH CS/DS/ES and SS instructions and only POP DE/ES or SS).

Don't try pop CS !
Debug will assemle it for you but the actual instruction is NOT a Pop CS.
The OP code is 0F and it is just a prefix for system instructions in a
286/386/486/Pentium chip.
(Instructions like LIDT, LGDT and the like.)

Andras

Gary L. Smith

unread,
Oct 11, 1994, 1:02:20 PM10/11/94
to
Zsoter Andras (h929...@hkuxb.hku.hk) wrote:

: Don't try pop CS !


: Debug will assemle it for you but the actual instruction is NOT a Pop CS.
: The OP code is 0F and it is just a prefix for system instructions in a
: 286/386/486/Pentium chip.
: (Instructions like LIDT, LGDT and the like.)

POP CS _is_ an instruction on the 8088, and it does exactly that. It's
not entirely clear where this instruction might be usefully employed.

--
Gary L. Smith g...@infinet.com
Columbus, Ohio Gary_...@oclc.org

Paul Schlyter

unread,
Oct 12, 1994, 3:31:35 PM10/12/94
to
In article <37eges$1...@rigel.infinet.com>,

Gary L. Smith <g...@infinet.com> wrote:
>> Don't try pop CS !
>> Debug will assemle it for you but the actual instruction is NOT a Pop CS.
>> The OP code is 0F and it is just a prefix for system instructions in a
>> 286/386/486/Pentium chip.
>> (Instructions like LIDT, LGDT and the like.)
>
> POP CS _is_ an instruction on the 8088, and it does exactly that. It's
> not entirely clear where this instruction might be usefully employed.

One use would be to distinguish an 8086 from other x86'es

Another use would be to relocate some code and then jump to the new copy.
For instance:

call far nxt ; Pushes CS+PC
nxt: pop si ; PC->SI
mov di,si ; ->DI
pop ds ; CS->DS
mov ax, new_seg
mov es, ax ; Point ES to new segment
mov cx, blksize ; Size of code block to move
rep movsb ; Move block of code
push es
pop cs ; Jump to new copy of code
....old copy of code continues....

However this would only work on 8086/88, not on 286+

--
----------------------------------------------------------------
Paul Schlyter, SAAF (Swedish Amateur Astronomer's Society)
Nybrogatan 75 A, S-114 40 Stockholm, Sweden
InterNet: pau...@saaf.se p...@ausys.se

J.J. Keijser

unread,
Oct 12, 1994, 4:59:36 AM10/12/94
to
In article <1994Oct8.2...@unlv.edu> ftlo...@unlv.edu (Frank Lofaro) writes:
>From: ftlo...@unlv.edu (Frank Lofaro)
>Subject: Re: Wierd Instructions.
>Date: Sat, 8 Oct 94 22:53:50 GMT

>Hmm, executing 0xf1 on my Intel 486DX/33 from ring 3 in protected mode
>results in not an int 0x6 (Illegal Instruction), but instead either an
>int 0x01 or an int 0x03 (I am doing this under Linux, and thus can't tell
>the difference without a lot of work).

Correct, opcode 0F1 on Intel chips causes a Debug Trap, even when not single
stepping. On the 286, the opcode 0F1 would IGNORE the next instruction when
single stepping was used. Great opcode to prevent debugging. It's too bad
they reversed it on the 386+. As far as I know, even the Pentium supports the
386 version of the 0F1 opcode. I have never seen 0F1 generate INT 3, however.

On some AMD chips, this opcode does something altogether different, when a
certain bit is set in one of the debug registers (DR7, I think).

Hope this helps,

JJ

Ngoh Tee Chiang

unread,
Apr 5, 1995, 3:00:00 AM4/5/95
to
David Emrich (emr...@tartarus.uwa.edu.au) wrote:

Mike Schmit

unread,
Apr 7, 1995, 3:00:00 AM4/7/95
to

>I used to do a bit of assembler on Apple IIs (65c02), and I read once
>about several odd instructions, with insane mnemonics. One example, HCF,
>would compleatly trash all 3 registers, and hang everything. It stood for
>"Halt and Catch Fire". What I'm wondering is, is there anything similar
>in the x86 line, particularly the 80x8 and the 186?

Yes, on the x86 there is an equivalent of HCF. It is called WIN. And it
isn't as reliable as HCF.

Mike Schmit

-------------------------------------------------------------------
msc...@ix.netcom.com author:
408-244-6826 Pentium Processor Programming Tools
800-765-8086 ISBN: 0-12-627230-1
-------------------------------------------------------------------

Mark Pickerill

unread,
Apr 7, 1995, 3:00:00 AM4/7/95
to
>
>: >I used to do a bit of assembler on Apple IIs (65c02), and I read once
>: >about several odd instructions, with insane mnemonics. One example, HCF,
>: >would compleatly trash all 3 registers, and hang everything. It stood for
>: >"Halt and Catch Fire". What I'm wondering is, is there anything similar
<snip>

>: Second: HCF was an opcode that was used on some really archaic hardware


>: well before apples were even thought of. It really did halt and
>: catch fire, on one machine, since what it did (if not used
>: properly) was to enter a tight loop which was not interruptable
>: or resettable, and since the machine used core memory, the
>: repetetive access to the same core locations heated up the
>: to the point where the wires would melt, causing short circuits,
>: and driver chips would begin to smoke!

Some very early 6800 CPUs (may have been betas) also had this mis-feature.
The chip would literaly burn up! Worked with a guy who was there....
(un-documented opcode).

-Mark


Alan Krause

unread,
Apr 7, 1995, 3:00:00 AM4/7/95
to All
>>I used to do a bit of assembler on Apple IIs (65c02), and I read once

65c02 eh? I did a fair amount of ASM programming on my Apple ][e as well,
wrting serial drivers for BBSs, graphics program etc. I've just decided to
try learning x86 assembly, and although there are a significant amount of new
opcodes to make life for the modern day ASM programmer pretty nice, its still
not that far off the old stuff I used to code..

Anyways, glad to have a newsgroup like this to help lower the learning curve!

Alan Krause

-------------------------------------------------
Alan Krause krau...@coyote.csusm.edu
Compuserve: 76651, 1674

Mike McCarty

unread,
Apr 12, 1995, 3:00:00 AM4/12/95
to
In article <3lvc0h$k...@acad1.tp.ac.sg>,
Ngoh Tee Chiang <ngo...@acad1.tp.ac.sg> wrote:
)David Emrich (emr...@tartarus.uwa.edu.au) wrote:

[stuff about invalid op codes gone]

): state (as if some other processor had taken it over). (Try POP
): CS! The "hole" exists in the instruction set, since there are
): PUSH CS/DS/ES and SS instructions and only POP DE/ES or SS).

POP CS is a valid 8088/8086 instruction. It is not a hole. It is not a
valid 80286/80386/80486 instruction. I don't know about the 80188/80186.

Mike
----
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}

Paul Schlyter

unread,
Apr 18, 1995, 3:00:00 AM4/18/95
to
In article <3mhj9t$k...@sun001.spd.dsccc.com>,

Mike McCarty <jmcc...@spd.dsccc.com> wrote:

> POP CS is a valid 8088/8086 instruction. It is not a hole. It is not a
> valid 80286/80386/80486 instruction. I don't know about the 80188/80186.

On the Nec V20 (an 80186/8 clone chip with 8086/8 compatible connections)
the 8086/8 "Pop CS" opcode was used for another purpose: as a prefix
to a set of V20-specific opcodes (including bit handling).

--
----------------------------------------------------------------
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Nybrogatan 75 A, S-114 40 Stockholm, SWEDEN
e-mail: pau...@saaf.se p...@ausys.se

Mark Pickerill

unread,
Apr 19, 1995, 3:00:00 AM4/19/95
to
In article <3n061l$7...@electra.saaf.se>,

Paul Schlyter <pau...@electra.saaf.se> wrote:
>In article <3mhj9t$k...@sun001.spd.dsccc.com>,
>Mike McCarty <jmcc...@spd.dsccc.com> wrote:
>
>> POP CS is a valid 8088/8086 instruction. It is not a hole. It is not a
>> valid 80286/80386/80486 instruction. I don't know about the 80188/80186.
>
>On the Nec V20 (an 80186/8 clone chip with 8086/8 compatible connections)
>the 8086/8 "Pop CS" opcode was used for another purpose: as a prefix
>to a set of V20-specific opcodes (including bit handling).

Not only that, but POP CS is *NOT* a valid 8088/8086 instruction. Oh, its
there all right, and it works, but as it was not documented or supported by
Intel, it isn't valid. Not only that, most 8088 machines that I know of have
been "upgraded" to a V20 in order to pick up a little speed and '286
(non-protected mode) instruction compatability.

;*****************************************************************************
;* ___ *
;* / \ Mark D. Pickerill Monterey Bay Aquarium Research Institute *
;*| | ma...@mbari.org (M.B.A.R.I.) *
;* \ / *
;*__\_/__ Servant of Athena |==================================|*
;* | Assembly hack extrodinaire | All opinions are my own, and in |*
;* | Diesel engine nut | no way reflect opinions of MBARI |*
;* | Mercedes-Benz enthusiast | "Standard disclaimers apply" |*
;* | |==================================|*
;*****************************************************************************


Paul Schlyter

unread,
Apr 27, 1995, 3:00:00 AM4/27/95
to
In article <3n41bk$4...@reef.mbari.org>,

Mark Pickerill <ma...@reef.mbari.org> wrote:

> Not only that, but POP CS is *NOT* a valid 8088/8086 instruction.
> Oh, its there all right, and it works, but as it was not documented
> or supported by Intel, it isn't valid.

This is false -- the "POP CS" on the 8086/88 _was_ documented by
Intel, at least in earlier documentation. Right in front of me I
have Intel's "Microsystem Components Handbook - Microprocessors
Volume I", the 1986 edition. The 8086/88 opcode definition says:

POP -- segment register: 0 0 0 reg 1 1 1

where "reg" is a 2-bit combination specifying one of the four segment
registers in an 8088. Note that there are no restrictions noted for
"reg". In the 80286 opcode definition one can read:

POP -- segment register: 0 0 0 reg 1 1 1 (reg != 01)

Note the difference -- here the "01" combination for "reg", which
refers to CS, is explicitly forbidden! In the 80186/188 opcode
definition one can read:

POP -- segment register: 0 0 0 reg 1 1 1 (reg != 01)

which means that for the 80186/188 the "POP CS" is forbidden too.

However, for the 8086/88, "POP CS" didn't only work but it was also
documented - by Intel!



> Not only that, most 8088 machines that I know of have
> been "upgraded" to a V20 in order to pick up a little speed and '286
> (non-protected mode) instruction compatability.

Then they are no longer 8088 machines.....

Btw, trying to execute "POP CS" is one possible way to distinguish an
8088 from a V20.


--
----------------------------------------------------------------
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Nybrogatan 75 A, S-114 40 Stockholm, SWEDEN
e-mail: pau...@saaf.se paul.s...@ausys.se

0 new messages