undocumented PIC16 opcodes

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.

Undocumented opcodes can cause all sorts of problems if you depend on them.

The other thing you get into is that there might be one class of four opcodes, a second of four, a third of one, and a fourth of one. All of which 4-bit more significantly decode.

There is no point is exhaustively decoding something that does not need exhaustively decoded.

See my own examples at

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

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. IIRC, the Z80 had several instuctions that would load a value from memory and them completely ignore it. The PIC may do the same sort of thing.

In the 8080 there was a 16 bit subtract that almost worked. It didn't borrow correctly.

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.

But why?

Already in 80286.

Maybe the weirdest is called loadall. It loads all the registers (including memory protection) from a memory block starting at 0x800.

I guess that it is for factory testing the memory management without needing to enter the protected mode (which is a one-way operation in -286).

At least Intel's RMX uses the instruction in the boot to load memory above 1 MiB.

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.

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.

By x86 and not 8086 I mean the later ones not the 8086 its self.

Why not?

"mc" a écrit dans le message de news: orZgi.1011$ snipped-for-privacy@bignews2.bellsouth.net...

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

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

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

"MooseFET" a écrit dans le message de news: snipped-for-privacy@o11g2000prd.googlegroups.com...

Partial decoding may introduce interesting possibilities do you have any other clues ?

Bruno

Haha :) I know a lot of people ready to drink free margaritas even for one day !

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

Finding 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.

"David T. Ashley" a écrit dans le message de news:

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