ftp.nice.ch/peanuts/GeneralData/Usenet/news/1989/CSN-89.tar.gz#/comp-sys-next/1989/Sep/Motorola-DSP56001-so-called-"insane-instructions"

This is Motorola-DSP56001-so-called-"insane-instructions" in view mode; [Up]


Date: Sun 10-Sep-1989 04:50:17 From: Unknown Subject: Motorola DSP56001 so called "insane instructions" eric thayer writes: >Did you know that there are actually instructions on the 56k which can >potentially damage the chip? Things like move x:ea -> b and y:ea -> b. >The assembler will not generate insane instructions, but if you go executing >random data, there is the possibility of executing one of these. >You can find more information on Insane DSP56000 instructions on page A-260 >of the Rev 1 User's Manual for the chip. But, it says instructions like > > <op> x:ea,b y:ea,b > >Can cause damage to the XDB and YDB bus drivers and permanent damage to the >chip could result. So, don't put weird DC directives in your P space. greg shannon writes a short time later: >I would greatly appreciate it if someone from NeXT would comment on this >problem -- is it true or not?? this is NOT a NeXT problem. this is a Motorola documentation problem. here is how it happened. a new circuit designer with the best intentions did an analysis of these instructions. he INCORRECTLY concluded that he had found a problem with the chip. he sent electronic mail to a lot of us including the guy who was doing the manual. other circuit designers got together with the new circuit designer and showed him the errors in his conclusions, i.e., that he had not found a problem. unfortuitously the DSP56001 manual documentation person (unbeknownst to everyone else) included this text in the manual, and during the proofreading this insane passage was not caught and deleted. Rev 1 of the Motorola DSP56001 manual was printed in early may, 1989, and distributed first at icassp in scotland in late may. within about a week one of our Motorola dsp research engineers pointed this passage-in-error to us, and we knew many people would have a question about the passage. not a week goes by that we don't get at least one applications call concerning this documentation problem. i personally was wondering when this would be pointed out by someone on the net. we have more than 20,000 copies of rev 1 of this manual out in the world, and we are trying to get all the errors corrected in rev 2 of the manual (rev 2 will just be error corrections to rev 1). rev 0 of the manual was gray. rev 1 and rev 2 of the DSP56001 manual are and will be red. i can give you no forecast when rev 2 of this manual will happen. if you want to do these "insane" instructions (the insane name came from a non-native english speaker, and lacking a better term for the type of instruction, we adopted it.) on your DSP56001, do it. they won't harm the chip. if you want to put your DSP56001 in a loop that will execute these "insane" instructions for hours, days, or years, you can do that too. no problem. in case you are wondering, we have done this just so we can say that the theory and the practice agree. we would not have done this had this documentation error not occurred. we knew someone would ask us whether we had actually DONE it on real DSP56001 chips. one part of the documentation is correct. you will get indeterminate results if you do this. bryant wilder Motorola DSP operations manager oak hill, texas >From: cs141043@brunix (Ronald Antony)

These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.