Maker Pro
Maker Pro

undocumented PIC16 opcodes

D

Don Lancaster

Jan 1, 1970
0
bruno said:
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.

--
Many thanks,

Don Lancaster voice phone: (928)428-4073
Synergetics 3860 West First Street Box 809 Thatcher, AZ 85552
rss: http://www.tinaja.com/whtnu.xml email: [email protected]

Please visit my GURU's LAIR web site at http://www.tinaja.com
 
D

Don Lancaster

Jan 1, 1970
0
Don said:
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 http://www.tinaja.com/glib/numschip.pdf

--
Many thanks,

Don Lancaster voice phone: (928)428-4073
Synergetics 3860 West First Street Box 809 Thatcher, AZ 85552
rss: http://www.tinaja.com/whtnu.xml email: [email protected]

Please visit my GURU's LAIR web site at http://www.tinaja.com
 
M

MooseFET

Jan 1, 1970
0
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. 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.
 
M

mc

Jan 1, 1970
0
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?
 
T

Tauno Voipio

Jan 1, 1970
0
mc said:
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.
 
R

Richard Henry

Jan 1, 1970
0
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.

http://en.wikipedia.org/wiki/Halt_and_Catch_Fire
 
J

Joerg

Jan 1, 1970
0
Jim said:
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.
 
D

David T. Ashley

Jan 1, 1970
0
bruno gavand said:
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.
 
B

BrunoG

Jan 1, 1970
0
mc said:
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
 
B

BrunoG

Jan 1, 1970
0
Don Lancaster said:
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
 
B

BrunoG

Jan 1, 1970
0
Jim Granville said:
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
 
B

BrunoG

Jan 1, 1970
0
MooseFET said:
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
 
B

BrunoG

Jan 1, 1970
0
Joerg said:
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
 
R

Rolf Blom

Jan 1, 1970
0
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
 
L

larwe

Jan 1, 1970
0
My goal is to complete the map, even if I have to fill it with NOPs

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

BrunoG

Jan 1, 1970
0
David T. Ashley said:
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
 
Top