Post by thread:[PIC]: instructions not in the instruction set !

U gurus seem to have some instructions to use that isnt in the instruction set like "skpnc" and "skpc", "skpcnc". I have seen them in examples and they compile so guess they are ok... weird. I have the PIC 16F87x pdf datasheet. Instruction set in page 138. What does they mean, and are there more of 'em ? -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Your right, it should be illegal to confuse the already confused. I found a list of all the "special" mnumonics under one of the appendix's (Quick Reference) of the MPASM help file Patrick J wrote: {Quote hidden}> Arghhh, that should be illegal to use in examples ! > Newbies like me might spend hours and hours trying to figure > out what that is :-) > > From: "Bob Ammerman" > > These are actually synonyms for other instructions. For example, SKPNC is > > really "BTFSC STATUS,C". > > -- > http://www.piclist.com hint: The PICList is archived three different > ways. See http://www.piclist.com/#archives for details. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Some time ago there was a post from someone who purported to know of undocumented PIC instructions but never followed it up with proof when challenged. I assume this is urban myth ? On the 6502/6510 there are undocumented instructions, which appear as illegal code (???) in disassemblers. For example one that performs LXA (ie LDA and LDX with the same number), which can be useful -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email spam_OUTlistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

Patrick J wrote: > > U gurus seem to have some instructions to use that isnt in the > instruction set like "skpnc" and "skpc", "skpcnc". I have seen them > in examples and they compile so guess they are ok... weird. > > I have the PIC 16F87x pdf datasheet. Instruction set in page 138. > What does they mean, and are there more of 'em ? Hi Patrick, these are STANDARD Microchip mnemonics for their PIC instruction set. As such I don't see any problem in using them, in fact the opposite, I think SKPNZ (skip if not zero) is so much more sensible than BTFSC STATUS,Z Surely you agree? The MPASM handbook and associated .PDF format list these mnemonics. The only ones I don't like are the BZ, BNZ, etc which assemble to 2 instructions. That can cause problems with other "skip" situations and I don't use them. The standard mnemonics that assemble to ONE instruction are great, like SKPZ, SKPNZ, SKPC, SKPNC, and I use TSTF a lot, great for testing if a register is zero by: TSTF register SKPZ (this code is very obvious what you tested) goto blah There are a few custom designed mnemonics that are not official Microchip ones, but which are really handy, I got these from Olin, SKPWGT skip if w greater than SKPWLE skip if w less or equal SKPWEQ skip if w equal SKPWNE skip if w not equal These are amazingly useful when using the sometimes confusing Microchip SUBLW and SUBWF instructions. That can save so much effort and debugging. You can make some custom instructions yourself just by using the define# command. A couple I like are INCW and DECW, very useful. As long as they assemble to one instruction I would recommend using these, they can help you write and debug code so much quicker. :o) -Roman -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email .....listservKILLspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

Jinx wrote: > >Some time ago there was a post from someone who purported to >know of undocumented PIC instructions but never followed it up >with proof when challenged. I assume this is urban myth ? On the >6502/6510 there are undocumented instructions, which appear as >illegal code (???) in disassemblers. For example one that performs >LXA (ie LDA and LDX with the same number), which can be >useful > Useful perhaps, but IMHO very dangerous to use. An undocumented opcode in a processor is generally a side-effect that was never intended to be there in the first place. The original chip manufacturer (or a licensed second source) is under no obligation to keep that side-effect present in future versions of the chip. The Z80 has quite a few of these and, while I may be able to save a byte or two occasionally, the risk of having a future die revision break my code just isn't worth it to me. YMMV _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listservKILLspammitvma.mit.edu with SET PICList DIGEST in the body

At 12:44 AM 6/10/01 +1000, Roman Black wrote: >There are a few custom designed mnemonics that are not >official Microchip ones, but which are really handy, >I got these from Olin, > >SKPWGT skip if w greater than >SKPWLE skip if w less or equal >SKPWEQ skip if w equal >SKPWNE skip if w not equal I've got a few more that I find useful: 12 bit core only: tstw MACRO ;test w, valid Z; C & DC unchanged xorlw 0 endm comw MACRO ;complement W, valid Z; C & DC unchanged xorlw 0xFF endm 12 bit and 14 bit core parts: decw MACRO ;decrement w, valid Z, C & DC trashed addlw -1 endm ;C & DC =1 if w>0 after decrement negw MACRO ;negate w sublw 0 endm ;valid z; C & DC trashed And you are right: Olin's 1 line macros were (are) a great idea - thanks, Olin! dwayne Dwayne Reid <.....dwaynerKILLspam.....planet.eon.net> Trinity Electronics Systems Ltd Edmonton, AB, CANADA (780) 489-3199 voice (780) 487-6397 fax Celebrating 17 years of Engineering Innovation (1984 - 2001) * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Do NOT send unsolicited commercial email to this email address. This message neither grants consent to receive unsolicited commercial email nor is intended to solicit commercial email. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email EraseMElistservspam_OUTTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

Actually, Roman, they're not "standard mnemonics"; they're macros (or #defines, if you like) that are built into MPASM. There is no entry in any instruction set descriptions from Microchip that list these "instructions" as real instructions. (See my PIC Microcontroller Instruction Set Comparison Matrix for a complete list of all PIC microcontroller instructions. Note: this chart DOES NOT include any of the new dsPIC instructions.) Secondly, the Bn conditional branch instructions 1) only appear in the enhanced 16-bit core products (i.e., 18Cxxxx/18Fxxxx) and 2) are all encoded in a single word (note, however, that they take two machine cycles, but NOT two program words). Skip instructions will work perfectly find with them. Douglas Wood Software Engineer dbwoodspam_OUTkc.rr.com Home of the EPICIS Development System for the PIC and SX http://epicis.piclist.com {Original Message removed}

Douglas Wood wrote: > > Actually, Roman, they're not "standard mnemonics"; they're macros (or > #defines, if you like) that are built into MPASM. There is no entry in any > instruction set descriptions from Microchip that list these "instructions" > as real instructions. (See my PIC Microcontroller Instruction Set Comparison > Matrix for a complete list of all PIC microcontroller instructions. Note: > this chart DOES NOT include any of the new dsPIC instructions.) The "official" quick reference card I got from Microchip with MPASM users guide lists these as "PIC16C5X/PIC16CXX Special Instruction Mnemonics" And they are listed under the same name, all the same official mnemonics on page 135 of the MPASM users guide. Maybe they are not "real" instructions as such but if listed as part of MPASM that makes them official enough for me. And I never said they were official instructions, I said they were official mnemonics. :o) > Secondly, the Bn conditional branch instructions 1) only appear in the > enhanced 16-bit core products (i.e., 18Cxxxx/18Fxxxx) and 2) are all encoded > in a single word (note, however, that they take two machine cycles, but NOT > two program words). Skip instructions will work perfectly find with them. Wrong again Douglas! :o) BZ, BNZ, BC etc are all included in the same list, and they assemble to 2 instructions as I said. See the "instruction set" pages in your MPASM guide, they are all listed. I also forgot a couple of the other official ones I use all the time; CLRC, SETC, CLRZ, SETZ. And one homemade one that is very useful to simplify close branching without having to resort to labels; #define SKP2 goto $+1+2 ; skips the next 2 instructions Example: DECFSZ register,f ; dec register, and test zero SKP2 (do blah) ; if register==Z, do both these instructions (do another blah) ; ; if register==NZ, skipped them both I know some purists won't like that, but so often you need to do a conditonal test and then do (or not-do) 2 instructions. This saves having to add goto+label where there is really no need. I don't use this all the time, only some times when it gives simpler code. -Roman > {Original Message removed}

Dwayne Reid wrote: > > At 12:44 AM 6/10/01 +1000, Roman Black wrote: > > >There are a few custom designed mnemonics that are not > >official Microchip ones, but which are really handy, > >I got these from Olin, > > > >SKPWGT skip if w greater than > >SKPWLE skip if w less or equal > >SKPWEQ skip if w equal > >SKPWNE skip if w not equal > > I've got a few more that I find useful: > > 12 bit core only: > > tstw MACRO ;test w, valid Z; C & DC unchanged > xorlw 0 > endm Clever! Never thought of using that one! :o) {Quote hidden}> > comw MACRO ;complement W, valid Z; C & DC unchanged > xorlw 0xFF > endm > > 12 bit and 14 bit core parts: > > decw MACRO ;decrement w, valid Z, C & DC trashed > addlw -1 > endm ;C & DC =1 if w>0 after decrement > > negw MACRO ;negate w > sublw 0 > endm ;valid z; C & DC trashed > > And you are right: Olin's 1 line macros were (are) a great idea - thanks, > Olin! Absolutely! And may I ask is there any gain from making these one-inst mnemonics as macros and not just using #defines? I use: #define NEGW sublw d'0' ; negate w -Roman -- http://www.piclist.com hint: To leave the PICList @spam@piclist-unsubscribe-requestKILLspammitvma.mit.edu

> An undocumented opcode in a processor is generally a side-effect that was > never intended to be there in the first place. The original chip > manufacturer (or a licensed second source) is under no obligation to keep > that side-effect present in future versions of the chip. > > The Z80 has quite a few of these and, while I may be able to save a byte or > two occasionally, the risk of having a future die revision break my code > just isn't worth it to me. YMMV 6800 from long ago had a nice one - We called it HCF aka "Halt & Catch Fire" :-) When implemented the cpu turned into a binary hardware counter with addresses appearing on address bus at clockspeed. An excellent instruction for testing address decoders etc and a good trap if the cpu ran away ever. When it did it would often as not strike a HCF and the system would lock in this interesting mode. Presumably it was intended as a hardware test. RM -- http://www.piclist.com hint: To leave the PICList KILLspampiclist-unsubscribe-requestKILLspammitvma.mit.edu

>6800 from long ago had a nice one - >We called it HCF >aka "Halt & Catch Fire" :-) Don't tell me that! ;oD Yesterday I was fixing a pinball machine (Jurassic Park - Data East Co.) and looking at the CPU board I though "hmmm...6502...too crazy to use it in a pinball..." and when I turned my vision to one of the 6821 PIA (there are LOTS of them in the board) I saw something interesting - The chip MELTED and throw some brown guts in the board. Like a crocroach (again, where is my english dictionary?) when you step on it. Very nice indeed. Lots of repair and board rework time... :o\ >When implemented the cpu turned into a binary hardware counter with >addresses appearing on address bus at clockspeed. An expensive 4040? :o) >An excellent instruction for testing address decoders etc and a good trap if >the cpu ran away ever. When it did it would often as not strike a HCF and >the system would lock in this interesting mode. Ah, so it is "Halt and Count Forever" :o) >Presumably it was intended as a hardware test. Or a cheap way to turn your $300 microprocessor into a $5 binary counter? :o) ---8<---Corte aqui---8<---- Alexandre Souza spamBeGonetaitospamBeGoneterra.com.br http://planeta.terra.com.br/lazer/pinball/ ---8<---Corte aqui---8<---- -- http://www.piclist.com hint: To leave the PICList TakeThisOuTpiclist-unsubscribe-requestEraseMEspam_OUTmitvma.mit.edu

----- Original Message ----- From: Bob Barr <RemoveMEbob_barrTakeThisOuTHOTMAIL.COM> > Useful perhaps, but IMHO very dangerous to use. > > An undocumented opcode in a processor is generally a side-effect that was > never intended to be there in the first place. The original chip > manufacturer (or a licensed second source) is under no obligation to keep > that side-effect present in future versions of the chip. This is pretty much the reason not to use them. Even if there were valid opcodes intentionally put in, it might be under a specific revision, specific sub-family, specific part, etc., it may be removed at any time and might further reduce the range of chips that your code would work under. Microchip is trying to ween developers from using OPTION and TRIS for the 16x family as it is, if those are possibly subject to future elimination or non-support on new chips, I imagine the undocumented ones way be under an even greater threat. Jeff -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestEraseME.....mitvma.mit.edu

> Absolutely! And may I ask is there any gain from > making these one-inst mnemonics as macros and not > just using #defines? Yes. Macros are only recognized where instructions would normally go, whereas a #DEFINE will kick in for any symbol of that name. This could lead to unexpeted results if you accidentally create a label or a variable with the #DEFINE name. ******************************************************************** Olin Lathrop, embedded systems consultant in Littleton Massachusetts (978) 742-9014, EraseMEolinembedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestEraseMEEraseMEmitvma.mit.edu

At 06:14 PM 6/10/01 +1000, Roman Black wrote: >Absolutely! And may I ask is there any gain from >making these one-inst mnemonics as macros and not >just using #defines? > >I use: >#define NEGW sublw d'0' ; negate w Umm . . . never thought of it, I guess. I'll have to take a closer look at that! dwayne Dwayne Reid <RemoveMEdwaynerspam_OUTKILLspamplanet.eon.net> Trinity Electronics Systems Ltd Edmonton, AB, CANADA (780) 489-3199 voice (780) 487-6397 fax Celebrating 17 years of Engineering Innovation (1984 - 2001) * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Do NOT send unsolicited commercial email to this email address. This message neither grants consent to receive unsolicited commercial email nor is intended to solicit commercial email. -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu