1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

undocumented PIC16 opcodes

Discussion in 'Embedded' started by bruno gavand, Jun 28, 2007.

  1. bruno gavand

    bruno gavand Guest

    bruno gavand, Jun 28, 2007
    1. Advertisements

  2. bruno gavand

    mc Guest

    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.
    mc, Jun 29, 2007
    1. Advertisements

  3. 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:

    Please visit my GURU's LAIR web site at http://www.tinaja.com
    Don Lancaster, Jun 29, 2007

  4. 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:

    Please visit my GURU's LAIR web site at http://www.tinaja.com
    Don Lancaster, Jun 29, 2007
  5. 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.
    Jim Granville, Jun 29, 2007
  6. bruno gavand

    MooseFET Guest

    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
    MooseFET, Jun 29, 2007
  7. bruno gavand

    mc Guest

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

    But why?
    mc, Jun 29, 2007
  8. bruno gavand

    Tauno Voipio Guest

    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, Jun 29, 2007
  9. http://en.wikipedia.org/wiki/Halt_and_Catch_Fire
    Richard Henry, Jun 29, 2007
  10. bruno gavand

    Joerg Guest

    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.
    Joerg, Jun 29, 2007
  11. 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

    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.

    David T. Ashley, Jun 29, 2007
  12. bruno gavand

    MooseFET Guest

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

    Why not?
    MooseFET, Jun 30, 2007
  13. bruno gavand

    BrunoG Guest

    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

    BrunoG, Jul 2, 2007
  14. bruno gavand

    BrunoG Guest

    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.

    BrunoG, Jul 2, 2007
  15. bruno gavand

    BrunoG Guest

    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

    BrunoG, Jul 2, 2007
  16. bruno gavand

    BrunoG Guest

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

    BrunoG, Jul 2, 2007
  17. bruno gavand

    BrunoG Guest

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

    BrunoG, Jul 2, 2007
  18. bruno gavand

    Rolf Blom Guest

    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 Blom, Jul 2, 2007
  19. bruno gavand

    larwe Guest

    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.
    larwe, Jul 2, 2007
  20. bruno gavand

    BrunoG Guest

    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.

    BrunoG, Jul 2, 2007
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.