Searching \ for '[PIC] Undocumented instruction used by jal' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Undocumented instruction used by jal'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Undocumented instruction used by jal'
2012\02\18@204057 by Peter

picon face
I found some balky jal generated pic code which was disassembled by me to yield
the use of what appears to be an undocumented instruction, used as in:

 0821  movf     0x21, w ; load w with data from reg. 0x21
 0065  tris     0x65    ; undocumented instruction

Target is pic16f628 (non A), disassembler is gpdasm.

Can someone shed some light on this? Jal author (Wouter), gpdasm contributors
(Scott D.)? Vasile Surducan?

I have the jal source for the above, this is not reverse engineering or anything
like that.

Any more easter eggs in pics we need to know about? Google knows next to nothing
about it, and I suspect any entries might have been censed.

thanks,

-- Peter

2012\02\18@211937 by IVP

face picon face

>  0065  tris     0x65    ; undocumented instruction

I'm sure it's just some sort of a leftover. TRISx was at one time the
TRIS-setting instruction

Others in the vicinity -

0062 OPTION [224] Use of this instruction is not recommended
0063 SLEEP
0064 CLRWDT
0065 TRIS PORTA [224] Use of this instruction is not recommended
0066 TRIS PORTB [224] Use of this instruction is not recommended
0067 TRIS IRP [224] Use of this instruction is not recommended

eg the old way was

movlw 0x55
tris portb

is now deprecated to

movlw 0x55
movwf trisb

Jo

2012\02\18@222919 by Peter

picon face
IVP <joecolquitt <at> clear.net.nz> writes:

> I'm sure it's just some sort of a leftover. TRISx was at one time the
> TRIS-setting instruction

True, BUT why is it not documented? There is no trace of 0x65 or 0x66 in the
docs for 16f62x, nor in any docs of their relatives. I so love to find easter
eggs in silicon (<- sarcasm). Anyway I have been around for long enough to have used the original pics with trisa and trisb opcodes, yet, I was not
aware that the feature made its way into 16 bit core pics? I was unable to
find a single datasheet referring to this.

More importantly, are there any other easter eggs to be found? Perhaps related
to undocumented debugging mode and/or ice? I am especially concerned about code
theft from protected devices and about glitches in operation unleashing some
operation which I did not foresee in the state machines I code.

-- Peter

2012\02\18@224911 by IVP

face picon face
>> I'm sure it's just some sort of a leftover. TRISx was at one time the
>> TRIS-setting instruction
>
> True, BUT why is it not documented?

It is kind of documented in MPLAB, as a warning. But IKWY

2012\02\19@004930 by IVP

face picon face
> original pics with trisa and trisb opcodes

IMHO TRIS PORTx is still safe to use on those PICs that recognise
it, (which I'm sure would be most if not all of the 12F and 16F) despite
eg an MPLAB warning. Because there is so much legacy code that
they just couldn't change the 0065/0065 values to other instructions / mnemonics. For example 0065 on the 12F675 is TRIS GPIO. And
no [224] warning

I don't believe TRISx has made it to 16-bit devices, because AFAIK
they came along after TRISx was deprecated

Jo

2012\02\19@020953 by John Temples

flavicon
face
On Sun, 19 Feb 2012, Peter wrote:

> IVP <joecolquitt <at> clear.net.nz> writes:
>
>> I'm sure it's just some sort of a leftover. TRISx was at one time the
>> TRIS-setting instruction
>
> True, BUT why is it not documented? There is no trace of 0x65 or 0x66 in the
> docs for 16f62x, nor in any docs of their relatives.

It is very clearly documented (and highlighted) in the DS40044G data
sheet for the 16F627A/628A/648A in the instruction set summary (along
with the OPTION instruction).  Both have warnings that they are
deprecated.

--
John W. Temples, II

2012\02\19@022250 by Wouter van Ooijen

face picon face
> Can someone shed some light on this? Jal author (Wouter),

I am no longer involved in the compiler development.

This seems not a compiler issue to me, more a library issue. Think: the TRIS instruction is not something a compiler will generate to implement a specific HLL construct.

If there are any chips that really don't implement (as opposed to just don't mention) TRIS it would be interesting to check what the libraries use for those chips.

When I was involved in the compiler, TRIS was documented for all chips I targeted. So it was valid, and it still is for those chips. I checked 12F629, it is still there.

I dunno what Kyle (he current compiler author) does, but way back I always ran the generated asm text through MPASM, and comared the result with the directly-generated .hex. Always a full match.

You could ask this on the jallist, more chance that the compiler and/or library developers read it.

--
Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu
C++ on uC blog: http://www.voti.nl/erblog

2012\02\19@030012 by Tamas Rudnai

face picon face
On 19 February 2012 02:18, IVP <spam_OUTjoecolquittTakeThisOuTspamclear.net.nz> wrote:

> eg the old way was
>
> movlw 0x55
> tris portb
>
> is now deprecated to
>
> movlw 0x55
> movwf trisb
>

Why should we worry about these? JAL is a High Level Language and we should
not much care about what code is generated until it works. If JAL can
optimise the code to a shorter or faster one using TRIS instruction and if
that TRIS instruction is still working on the target chip then why not? One
thing is good about TRIS instruction is that you do not need to worry about
the BANKSEL, therefore less program memory footprint and higher execution
speed.

Tamas



>
> Joe
>

2012\02\19@031619 by William \Chops\ Westfield

face picon face


On Feb 18, 2012, at 11:09 PM, John Temples wrote:

>> True, BUT why is it not documented?

My (old: DS31029A) midrange instruction set manual says:

Question 2:        Is there any danger in using the TRIS instruction for the PIC16CXXX since there is a warning in the Data book suggesting it not be used?
Answer 2:
For code compatibility and upgrades to later parts, the use of the TRIS instruction is not recommended. You should note the TRIS instruction is limited to ports A, B and C. Future devices may not support these instructions.
Question 3:        Do I have to switch to Bank1 of data memory before using the TRIS instruc- tion (for parts with TRIS registers in the memory map)?
Answer 3:
No. The TRIS instruction is Bank independent. Again the use of the TRIS instruction is not recommended.

TRIS  Load TRIS Register
Syntax: [ label ] TRIS f
Operands: 5≤f≤7
Operation:  (W) → TRIS register f;
Status Affected:  None
Encoding: 00 0000 0110 0fff
Description:
The instruction is supported for code compatibility with the PIC16C5X products. Since TRIS registers are readable and writable, the user can directly address them.

2012\02\19@034408 by Peter

picon face
Wouter van Ooijen <wouter <at> voti.nl> writes:
> If there are any chips that really don't implement (as opposed to just
> don't mention) TRIS it would be interesting to check what the libraries
> use for those chips.

Thanks to all who answered.

I did check as many datasheets as I could find, again, this is about TRIS
appearing in a 14 bit core datasheet where I never saw one. And appearing at
encoding level, at that (i.e. not TRIS in .asm but the equivalent of 0x0065 in
..hex !).

TRIS is indeed a valid instruction on 12xxx and other 12 bit cores. Frankly, I
do not know what to make of it, as it does not appear in the instruction table
"PIC16F62X INSTRUCTION SET".
BillW's notes wrt. his datasheet are noted, I will find that datasheet and
compare with it. I am using DS40300C which has no mention of tris anywhere.

Are there any more easte egg "grandfathered" opcodes in modern pics? Such as,
for example, option (the opcode, not the register) ?

-- Peter


2012\02\19@035829 by Peter

picon face
William "Chops" Westfield <westfw <at> mac.com> writes:

> >> True, BUT why is it not documented?
>
> My (old: DS31029A) midrange instruction set manual says...

And yes, that document also documents OPTION, the instruction, for 14 bit cores,
also deprecated like TRIS ... I was not ranting in vain. Hey that document is
from 1997. It should already have some antiquarian value.


2012\02\19@044930 by Joep Suijs

picon face
Hi

2012/2/19 Wouter van Ooijen <.....wouterKILLspamspam@spam@voti.nl>:
> This seems not a compiler issue to me, more a library issue. Think: the
> TRIS instruction is not something a compiler will generate to implement
> a specific HLL construct.

A quick scan of the jallib sources did not reveal any use of tris
opcode, so I'd like know what triggered this code. The asm file
(compiler output) is helpful for this, since it contains the output
code, as well as all (code generating) source. Please let us know what
statement for which source file triggered this opcode and - if
relevant - where that source file originated.

Joe

2012\02\19@045126 by IVP

face picon face
> from 1997

Probably Microchip feel that they warned programmers of that era,
like me, who then stopped using TRISx. Newer programmers would
not likely be aware of TRISx and so the warning has not continued
into more recent revisions of the datasheets. However, it still works
(because of my suspected disruption to legacy code) as long as you
use a chip of that era

A very very new PIC like the 16F1827 does not support TRISx

 tris  portb

Warning[224] : Use of this instruction is not recommended.
Error[126] : Argument out of range (0D not between 05 and 07)
Build Failed

Manually inserting 0x0065 gives TRIS FSR0H, which is a nonsense
instruction

Jo

2012\02\19@060606 by Rob Hamerling

picon face

Hi Joep,

On 02/19/12 10:49 am, Joep Suijs wrote:

> 2012/2/19 Wouter van Ooijen<wouterspamKILLspamvoti.nl>:
>> This seems not a compiler issue to me, more a library issue. Think: the
>> TRIS instruction is not something a compiler will generate to implement
>> a specific HLL construct.
>
> A quick scan of the jallib sources did not reveal any use of tris
> opcode,

I'm not so surprised that you didn't find any 'TRIS' occurence because in Jallib sources, because we use 'PORTx_direction' and 'pin_xy_direction' in stead of using TRISx directly.

Note: There are a few PICs which don't have a TRISx register, but do have a TRIS instruction (12-bits core).  In the Jallib libraries (device files) we hide this for the user (library) with pseudo variables. These 'put procedures have to use the TRIS instruction in stead of using the TRISx register, of course.

> so I'd like know what triggered this code.

The original poster detected the TRIS instruction in the hex file of a program for the 16F628. I agree with Wouter that this must come from user code or a library (probably old).

Regards, Rob.


-- R. Hamerling, Netherlands --- http://www.robh.n

2012\02\19@085454 by PICdude

flavicon
face
Some years ago I fat-fingered movwf as movfw instead and it compiled  w/o an error.  Apparently it's the same as "movf ...,W" and was  leftover from an earlier time.  Still works, but I don't use it as  it's undocumented so unsure when/if it'll be dropped.

Cheers,
-Neil.



Quoting Peter <.....plpeter2006KILLspamspam.....yahoo.com>:

{Quote hidden}

>

2012\02\19@085502 by PICdude

flavicon
face
Some years ago I fat-fingered movwf as movfw instead and it compiled  w/o an error.  Apparently it's the same as "movf ...,W" and was  leftover from an earlier time.  Still works, but I don't use it as  it's undocumented so unsure when/if it'll be dropped.

Cheers,
-Neil.



Quoting Peter <EraseMEplpeter2006spam_OUTspamTakeThisOuTyahoo.com>:

{Quote hidden}

>

2012\02\19@094239 by Tamas Rudnai

face picon face
MOVFW is a pseudo instruction defined by MPASM, not the actual architecture
-- so that is documented actually. The only reason I do not like that is
because it is too easy to read it as MOVWF by mistake.

Tamas



On 19 February 2012 13:55, PICdude <picdude3spamspam_OUTnarwani.org> wrote:

{Quote hidden}

> > --

2012\02\19@094405 by Jan-Erik Soderholm

face picon face


PICdude wrote 2012-02-19 14:55:
> Some years ago I fat-fingered movwf as movfw instead and it compiled
> w/o an error.  Apparently it's the same as "movf ...,W" and was
> leftover from an earlier time.  Still works, but I don't use it as
> it's undocumented...

It's not.

See : "A.6 12-BIT/14-BIT INSTRUCTION WIDTH PSEUDO-INSTRUCTIONS"
in the MPASM manual.



{Quote hidden}

>> -

2012\02\19@113627 by PICdude

flavicon
face
Quoting Tamas Rudnai <RemoveMEtamas.rudnaiTakeThisOuTspamgmail.com>:

> ... The only reason I do not like that is
> because it is too easy to read it as MOVWF by mistake.

And exactly why I wasted much time debugging code because of it.

2012\02\19@125026 by Dwayne Reid

flavicon
face
At 07:18 PM 2/18/2012, IVP wrote:

>eg the old way was
>
>movlw 0x55
>tris portb
>
>is now deprecated to
>
>movlw 0x55
>movwf trisb

One huge difference, though, is this: the 'tris' instruction works properly no matter how the RP0 / RP1 bits are set.

In other words, your second example (above) will NOT work if the RAM page bits are not correctly set.  The 'tris' instruction works all the time, every time.

Same for the 'option' instruction - it works properly regardless of the RAM page bit settings.

For those reasons, my legacy code still uses those instructions.  The 'option' instruction saves several cycles, which was useful in some ISR routines.

dwayne

-- Dwayne Reid   <spamBeGonedwaynerspamBeGonespamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax
http://www.trinity-electronics.com
Custom Electronics Design and Manufacturing

2012\02\19@125719 by Dwayne Reid

flavicon
face
At 06:54 AM 2/19/2012, PICdude wrote:
>Some years ago I fat-fingered movwf as movfw instead and it compiled
>w/o an error.  Apparently it's the same as "movf ...,W" and was
>leftover from an earlier time.  Still works, but I don't use it as
>it's undocumented so unsure when/if it'll be dropped.

'movwf' is a pseudo-op that is supported by MPASM as well as some other assemblers.  In other words, its not a 'real' instruction with a specific op-code.

You will find it and several other pseudo-ops documented in the MPASM documentation files.

And yes - I use 'movwf' exclusively, as opposed to 'movf XX,W'.  Its much easier for my brain to recognize.

dwayne

-- Dwayne Reid   <TakeThisOuTdwaynerEraseMEspamspam_OUTplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax
http://www.trinity-electronics.com
Custom Electronics Design and Manufacturing

2012\02\19@154835 by IVP

face picon face


> MOVFW ...... too easy to read it as MOVWF by mistake.

I use movfw in MPLAB, and have colours set so that it isn't
the same as movwf. Makes me stop and think

Edit / Properties / Tex

2012\02\25@153258 by Wouter van Ooijen

face picon face
On 19/2/2012 2:40 AM, Peter wrote:
> I found some balky jal generated pic code which was disassembled by me to yield
> the use of what appears to be an undocumented instruction, used as in:
>
>    0821  movf     0x21, w ; load w with data from reg. 0x21
>    0065  tris     0x65    ; undocumented instruction

Do you know which version of the Jal compiler and which libraries created this code? I checked the libraries (as I said, the compiler by itself would never generate a TRIS instruction): the stone-age library (written by me, in the days that all 14-bit cores supported TRIS instructions) does use it, because the library file jpic.jal had constructs like

procedure _trisa_flush is
   assembler
      bank movfw trisa
           tris  5
   end assembler
end procedure

The current library files for 14-bit cores should not generate the TRIS instruction, instead they use bank switching:

var volatile byte   TRISA                     at { 0x85 }
var volatile byte   PORTA_direction           at TRISA

Of course, the current library still uses TRIS for 12-bit cores:

procedure PORTA_direction'put(byte in x) is
   pragma inline
   _TRISA_shadow = x
   asm movf _TRISA_shadow,W
   asm tris 6
end procedure

--
Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu
C++ on uC blog: http://www.voti.nl/erblog

More... (looser matching)
- Last day of these posts
- In 2012 , 2013 only
- Today
- New search...