henry@utzoo.uucp (Henry Spencer) (08/07/88)
In article <5440@june.cs.washington.edu> pardo@uw-june.UUCP (David Keppel) writes: >All seriousness aside, if you ever get a chance to look at the >UMichigan list of opcodes (Circa 1970, since reprinted elsewhere) you >really should... For the purposes of comp.arch, let us at least stick to *real* opcodes, not imaginary ones (amusing though they can be...). >HACF # Halt And Catch Fire As is now moderately well-known, some of the Motorola 8-bit chips actually have such an instruction, sort of: there is a test opcode which makes the CPU just sit there endlessly incrementing its address lines. Nothing short of powerdown will shake it out of this. Some third-party opcode charts show this as HCF. The Motorola spec sheet that I remember doesn't give it a name, but does have a footnote warning you about it. Another real-life example is that the Burroughs 6700 series had some opcodes for interprocessor communication in multi-CPU systems. There was one for atomic access to memory, which had some boring name. The fun pair were for actually attracting another processor's attention: there was one that interrupted *all* processors, and another that would give you the processor number of the current processor. So you would set up some sort of message in shared memory and then interrupt everybody, and each processor would get its own processor number and then inspect the message to find out if it was the addressee. The instructions were HEYU and WHOI, I'm told. -- MSDOS is not dead, it just | Henry Spencer at U of Toronto Zoology smells that way. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
asw@inf.rl.ac.uk (Tony Williams) (08/10/88)
In article <1988Aug7.013526.7798@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >For the purposes of comp.arch, let us at least stick to *real* opcodes, >not imaginary ones (amusing though they can be...). > > ... >Another real-life example is that the Burroughs 6700 series had some opcodes >for interprocessor communication in multi-CPU systems. There was one for >atomic access to memory, which had some boring name. The fun pair were for >actually attracting another processor's attention: there was one that >interrupted *all* processors, and another that would give you the processor >number of the current processor. So you would set up some sort of message >in shared memory and then interrupt everybody, and each processor would >get its own processor number and then inspect the message to find out if >it was the addressee. The instructions were HEYU and WHOI, I'm told. As I recall, there was also a variant known as the super-HEYU, which could not be ignored. Its mnemonic was ZAP. -- --------------------------------------------------------------------------- Tony Williams |Informatics Division JANET: asw@uk.ac.rl.vd |Rutherford Appleton Lab Usenet: {... | mcvax}!ukc!rlvd!asw |Chilton, Didcot ARPA: asw%vd.rl.ac.uk@nss.cs.ucl.ac.uk |Oxon OX11 0QX, UK
ericb@athertn.Atherton.COM (Eric Black) (08/15/88)
In article <1988Aug7.013526.7798@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >As is now moderately well-known, some of the Motorola 8-bit chips actually >have such an instruction, sort of: there is a test opcode which makes the >CPU just sit there endlessly incrementing its address lines. Nothing short >of powerdown will shake it out of this. Some third-party opcode charts >show this as HCF. The Motorola spec sheet that I remember doesn't give it >a name, but does have a footnote warning you about it. Actually, it's better called WTD -- "Walk The Dog". On the 6800 it caused the chip to do nothing but read cycles, incrementing the address by one each time. Quite useful for bootstrapping the testing a new system; just force the opcode onto the data bus at chip reset time (never mind that the first two fetches are to get the reset vector, it'll get the opcode on the third fetch), and away we go. You can observe toggling address lines, test memory, and so on. Makes a handy address generator. I think its opcode was $AD, but it's been a bunch of years. It could be terminated by the chip reset, but ignored IRQ and NMI. In our systems we put in a two-stage watchdog timer. If it fell, it would NMI the chip, and the NMI handler would try to sort things out. However, if we were out walking the dog, this wouldn't work, and the second knock of the wolf at the door caused RESET. One neat thing about it was that we had a PROM at $AD00, with lots of vectors into itself at the beginning; hence, we had lots of occurences of $AD in there. It was pretty easy to go from executing data (bug, of course) right out onto the street and go walking the dog. >MSDOS is not dead, it just | Henry Spencer at U of Toronto Zoology >smells that way. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu [Sniff, sniff] Hey, mutt! Get away from that! -- Eric Black "Garbage in, Gospel out" Atherton Technology, 1333 Bordeaux Dr., Sunnyvale, CA, 94089 UUCP: {sun,decwrl,hpda,pyramid}!athertn!ericb Domainist: ericb@Atherton.COM
brian@ncrcan.Toronto.NCR.COM (Brian Onn) (08/18/88)
In article <217@mango.athertn.Atherton.COM> ericb@mango.UUCP (Eric Black) writes: >In article <1988Aug7.013526.7798@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >>As is now moderately well-known, some of the Motorola 8-bit chips actually >>have such an instruction, sort of: there is a test opcode which makes the >>CPU just sit there endlessly incrementing its address lines. Nothing short >>of powerdown will shake it out of this. Some third-party opcode charts >>show this as HCF. The Motorola spec sheet that I remember doesn't give it >>a name, but does have a footnote warning you about it. > >Actually, it's better called WTD -- "Walk The Dog". On the 6800 it... Is'nt this (HCF) an acronym for Halt and Catch Fire?. I remember seeing it described as just that in one of those third party opcode charts. :-) Brian. +-------------------+--------------------------------------------------------+ | Brian Onn | UUCP:..!{uunet!mnetor, watmath!utai}!lsuc!ncrcan!brian | | NCR Canada Ltd. | INTERNET: Brian.Onn@Toronto.NCR.COM | +-------------------+--------------------------------------------------------+