undocumented PIC16 opcodes

undocumented PIC16 opcodes

Post by bruno gava » Sat, 30 Jun 2007 07:21:03


Hi,

I listed 119 undocumented PIC16 opcodes here :
http://www.yqcomputer.com/

Does anybody here ever tried one of them ?

Thanks,

Bruno
 
 
 

undocumented PIC16 opcodes

Post by mc » Sat, 30 Jun 2007 10:41:52


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 PIC16 opcodes

Post by Don Lancas » Sat, 30 Jun 2007 10:43:48


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.yqcomputer.com/ : XXXX@XXXXX.COM

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

undocumented PIC16 opcodes

Post by Don Lancas » Sat, 30 Jun 2007 10:47:38


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.yqcomputer.com/

--
Many thanks,

Don Lancaster voice phone: (928)428-4073
Synergetics 3860 West First Street Box 809 Thatcher, AZ 85552
rss: http://www.yqcomputer.com/ : XXXX@XXXXX.COM

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

undocumented PIC16 opcodes

Post by Jim Granvi » Sat, 30 Jun 2007 11:18:48


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
 
 
 

undocumented PIC16 opcodes

Post by MooseFE » Sat, 30 Jun 2007 22:43:56

On Jun 28, 7:18 pm, Jim Granville < XXXX@XXXXX.COM >



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.
 
 
 

undocumented PIC16 opcodes

Post by mc » Sat, 30 Jun 2007 23:20:08


The x86 line predates Microsoft... you may mean the 386 and its successors.

But why?
 
 
 

undocumented PIC16 opcodes

Post by Tauno Voip » Sat, 30 Jun 2007 23:57:38


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.

--

Tauno Voipio
tauno voipio (at) iki fi
 
 
 

undocumented PIC16 opcodes

Post by Richard He » Sun, 01 Jul 2007 01:06:33

 
 
 

undocumented PIC16 opcodes

Post by Joer » Sun, 01 Jul 2007 02:53:24


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 ump *** th production batch.

--
Regards, Joerg

http://www.yqcomputer.com/
 
 
 

undocumented PIC16 opcodes

Post by David T. A » Sun, 01 Jul 2007 04:44:36


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 ( XXXX@XXXXX.COM )
http://www.yqcomputer.com/ (Consulting Home Page)
http://www.yqcomputer.com/ (Personal Home Page)
http://www.yqcomputer.com/ (GPL Publications and Projects)
 
 
 

undocumented PIC16 opcodes

Post by MooseFE » Sun, 01 Jul 2007 11:14:41


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



Why not?
 
 
 

undocumented PIC16 opcodes

Post by Bruno » Tue, 03 Jul 2007 23:03:58


orZgi.1011$ XXXX@XXXXX.COM ...



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
 
 
 

undocumented PIC16 opcodes

Post by Bruno » Tue, 03 Jul 2007 23:07:39


XXXX@XXXXX.COM ...


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
 
 
 

undocumented PIC16 opcodes

Post by Bruno » Tue, 03 Jul 2007 23:13:39

"Jim Granville" < XXXX@XXXXX.COM > a rit dans le message de



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