"bruno gavand" <bgavand@club-internet.fr> wrote in message news:46843566$0$21151$7a628cd7@news.club-internet.fr...> > I listed 119 undocumented PIC16 opcodes here : > http://www.micro-examples.com/public/microex-navig/doc/087-pic16-secret-opcode.html > > Does anybody here ever tried one of them ?My recommendation is that you take a digital logic class (maybe two of them) and a VLSI design class. You will then understand what an "undocumented opcode" is, why it would exist in many processors, etc. It often comes down to minimization of digital logic. Generally, you don't want to use undocumented opcodes. The chief reasons are: a)These may be reassigned at any time by the manufacturer, rendering your code unable to run. The reassignment could even be silent, meaning that the manufacturer does not change part numbers. b)The opcode may have effects (in the digital logic) that you are not able to detect with the testing you do. For example, it is possible although unlikely that one of these opcode might have built into it "clear the 'dirty' flag in the 213'th memory cache entry". Point is it may do something that you can't detect with the testing you are able to do. Dave. -- David T. Ashley (dta@e3ft.com) http://www.e3ft.com (Consulting Home Page) http://www.dtashley.com (Personal Home Page) http://gpl.e3ft.com (GPL Publications and Projects)
undocumented PIC16 opcodes
Started by ●June 28, 2007
Reply by ●June 29, 20072007-06-29
Reply by ●June 29, 20072007-06-29
On Jun 29, 7:20 am, "mc" <l...@www.ai.uga.edu.for.address> wrote:> > I believe that the entire x86 line has instructions that do trivial > > operations but take as long as the floating point squareroot > > instruction. These secret opcodes were included at Microsofts > > request. > > The x86 line predates Microsoft... you may mean the 386 and its successors.By x86 and not 8086 I mean the later ones not the 8086 its self.> But why?Why not?
Reply by ●July 2, 20072007-07-02
"mc" <look@www.ai.uga.edu.for.address> a �crit dans le message de news: orZgi.1011$Qz4.404@bignews2.bellsouth.net...> "bruno gavand" <bgavand@club-internet.fr> wrote in message > news:46843566$0$21151$7a628cd7@news.club-internet.fr... >> I listed 119 undocumented PIC16 opcodes here : >> http://www.micro-examples.com/public/microex-navig/doc/087-pic16-secret-opcode.html >> Does anybody here ever tried one of them ? > > If you'll remember how a CPU works, you won't assume that any of them do > anything useful at all. Some of them -- perhaps a great many of them -- > are likely to do exactly the same thing as other, documented opcodes. > Some will probably do nothing. > >Yes sure, but there is lot of suppositions in what you say... some... perhaps... likely... probably... My goal is to complete the map, even if I have to fill it with NOPs Bruno
Reply by ●July 2, 20072007-07-02
"Don Lancaster" <don@tinaja.com> a �crit dans le message de news: 5ej6ekF393sq1U3@mid.individual.net...> bruno gavand wrote: >> Hi, >> >> I listed 119 undocumented PIC16 opcodes here : >> http://www.micro-examples.com/public/microex-navig/doc/087-pic16-secret-opcode.html >> Does anybody here ever tried one of them ? >> >> Thanks, >> >> Bruno > > Undocumented opcodes can cause all sorts of problems if you depend on > them. >Your warning is right, but I'm sure nobody would be foolish enough to use them (if they do something). Just consider my question as pure curiosity. Bruno
Reply by ●July 2, 20072007-07-02
"Jim Granville" <no.spam@designtools.maps.co.nz> a �crit dans le message de news: 46846bb1@clear.net.nz...> bruno gavand wrote: >> Hi, >> >> I listed 119 undocumented PIC16 opcodes here : >> http://www.micro-examples.com/public/microex-navig/doc/087-pic16-secret-opcode.html >> Does anybody here ever tried one of them ? > > What you have listed are gaps in the Opcode map, that > does NOT mean they are undocumented PIC16 opcodes. > Most likely, the core will use minimal decoding, and > those opcode spaces will simply alias onto existing opcodes. > -jg >Yes, PIC16 is a very simple core, there is likely no space for extra opcodes but we will know that if I can finish the map Bruno
Reply by ●July 2, 20072007-07-02
"MooseFET" <kensmith@rahul.net> a �crit dans le message de news: 1183124636.600381.25530@o11g2000prd.googlegroups.com...> On Jun 28, 7:18 pm, Jim Granville <no.s...@designtools.maps.co.nz> > wrote: >> bruno gavand wrote: >> > Hi, >> >> > I listed 119 undocumented PIC16 opcodes here : >> >http://www.micro-examples.com/public/microex-navig/doc/087-pic16-secr... >> >> > Does anybody here ever tried one of them ? >> >> What you have listed are gaps in the Opcode map, that >> does NOT mean they are undocumented PIC16 opcodes. >> Most likely, the core will use minimal decoding, and >> those opcode spaces will simply alias onto existing opcodes. > > Actually they may map into strange things that are not useful. Less > than full decoding may cause part of one instruction to be done along > with part of another.Partial decoding may introduce interesting possibilities do you have any other clues ? Bruno
Reply by ●July 2, 20072007-07-02
"Joerg" <notthisjoergsch@removethispacbell.net> a �crit dans le message de news: oGbhi.475$eY.188@newssvr13.news.prodigy.net...> Jim Granville wrote: > >> bruno gavand wrote: >> >>> Hi, >>> >>> I listed 119 undocumented PIC16 opcodes here : >>> http://www.micro-examples.com/public/microex-navig/doc/087-pic16-secret-opcode.html >>> >>> Does anybody here ever tried one of them ? >> >> >> What you have listed are gaps in the Opcode map, that >> does NOT mean they are undocumented PIC16 opcodes. >> Most likely, the core will use minimal decoding, and >> those opcode spaces will simply alias onto existing opcodes. >> -jg >> > > And if someone really found a secret op code that makes free margaritas or > whatever there would be no guarantee that it doesn't disappear some day > after the umpteenth production batch. >Haha :) I know a lot of people ready to drink free margaritas even for one day ! Bruno
Reply by ●July 2, 20072007-07-02
On 2007-07-02 16:07, BrunoG wrote:> "Don Lancaster" <don@tinaja.com> a �crit dans le message de news: > 5ej6ekF393sq1U3@mid.individual.net... >> bruno gavand wrote: >>> Hi, >>> >>> I listed 119 undocumented PIC16 opcodes here : >>> http://www.micro-examples.com/public/microex-navig/doc/087-pic16-secret-opcode.html >>> Does anybody here ever tried one of them ? >>> >>> Thanks, >>> >>> Bruno >> >> Undocumented opcodes can cause all sorts of problems if you depend on >> them. >> > > Your warning is right, but I'm sure nobody would be foolish enough to use > them (if they do something). > Just consider my question as pure curiosity. > > Bruno > >I remember one time a (non-PIC) cpu was acting funny, due to an undocumented opcode that got into a corrupted binary. The opcode caused the cpu to start excercising its address bus in a sequential pattern, and the only way out was reset. (A watchdog was in the design, but disabled during initial testing). This undocumented opcode was intended for factory testing of the die. /Rolf
Reply by ●July 2, 20072007-07-02
On Jul 2, 10:03 am, "BrunoG" <nore...@micro-examples.com> wrote:> My goal is to complete the map, even if I have to fill it with NOPsFinding undocumented opcodes on, say, the Z80 or 6510, was possible because much of the system state was readable. In a PIC, of all the godforsaken architectures to research, that isn't true. You have an exhausting time ahead of you. You should start by analyzing the opcode from bits 13 down to 8 and seeing what patterns emerge. You can then make educated guesses about what to test. But it's a lot of work and of no practical value whatsoever. If you ever find yourself reverse-engineering code, and discover that someone has used one of these undocumented opcodes, you should advertise the fact widely so we can boycott the product, whatever it is.
Reply by ●July 2, 20072007-07-02
"David T. Ashley" <dta@e3ft.com> a �crit dans le message de news: 96SdnSKQ3PAu_RjbnZ2dnUVZ_qGjnZ2d@giganews.com...> "bruno gavand" <bgavand@club-internet.fr> wrote in message > news:46843566$0$21151$7a628cd7@news.club-internet.fr... > > a)These may be reassigned at any time by the manufacturer, rendering your > code unable to run. The reassignment could even be silent, meaning that > the manufacturer does not change part numbers. > > b)The opcode may have effects (in the digital logic) that you are not able > to detect with the testing you do. For example, it is possible although > unlikely that one of these opcode might have built into it "clear the > 'dirty' flag in the 213'th memory cache entry". Point is it may do > something that you can't detect with the testing you are able to do. >Yes I do agree 100% with you for point a) for point b), you are right too, operation can be hidden to best in-circuit debugger and to best operator sagacity. if nothing is detected, the opcode may be a nop in the best case, and for the other cases I suggest to name it PTM (as "Puts The Mess") if it causes troubles later. Bruno
