Searching \ for 'Instruction encodings (was: Code error)' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/index.htm?key=code+error
Search entire site for: 'Instruction encodings (was: Code error)'.

Truncated match.
PICList Thread
'Instruction encodings (was: Code error)'
1997\02\21@012611 by Clyde Smith-Stubbs

flavicon
face
(PIC related stuff at end!!)

Thus spake John Payson (spam_OUTsupercatTakeThisOuTspamMCS.NET):

> The opcode for NOP on the 68000 is decidedly NOT the same as the opcode for
> a jump-short to the next instruction.  On the 68000, a jump instruction has
> an eight bit relative address.  If this field is non-zero, it will be added
> to the address of the following instruction and loaded into the PC.  If this
> field is zero, then the 68000 will fetch the next 16 bits and use those as a
> relative address.

Yup, that's what I said in my previous message. I did not say that a NOP has the
same opcode as a jump, I said (in an oblique manner) that some assemblers will
output a NOP when jmp $+2 is requested.

> [1] Output some useless one-word instruction [e.g. NOP].  This will be compact
>     but it will produce slightly skewed timings.
>
> [2] Output a short jump ahead 2, followed by a NOP.  The NOP will put the tar-
>     get of the jump in an acceptable place, while giving execution timings
>     comparable to just using a short jump (if such a thing were possible).
The
>     extra NOP may mess up cache timings, however.
>
> [3] Output a long jump to next instruction.  This may be slower to execute
than
>     method #2, and probably doesn't have any particular advantage, but it is
>     the only output which is "literally" correct.

Neither [1] nor [2] is correct, since they implement jmp $+4. Other than the
effect on the pipeline (which on a 68000 is only one word deep anyway) a NOP
has precisely the same effect as a short jmp $+2 would if it existed. But some
people have trouble with the assembler choosing a bit pattern for an instruction
that is not what they expect.

In the same vein, there are processors with skip instructions, including SKIPA
(skip always) and SKIPN (skip never), and on at least one (can't remember which
one now) the SKIPN is used as a NOP.

The PIC is an interesting case - have a look at the encoding for NOP - it
happens to be equivalent to

       movwf   0,w

NOP even gets listed in the opcode table with the other instructions that
reference memory. Go figure.


--
Clyde Smith-Stubbs    | HI-TECH Software,       | Voice: +61 7 3354 2411
.....clydeKILLspamspam@spam@htsoft.com      | P.O. Box 103, Alderley, | Fax:   +61 7 3354 2422
http://www.htsoft.com | QLD, 4051, AUSTRALIA.   |
---------------------------------------------------------------------------
Download a FREE beta version of our new ANSI C compiler for the PIC
microcontroller! Point your WWW browser at http://www.htsoft.com/

1997\02\21@101813 by John Payson

picon face
> The PIC is an interesting case - have a look at the encoding for NOP - it
> happens to be equivalent to
>
>         movwf   0,w
>
> NOP even gets listed in the opcode table with the other instructions that
> reference memory. Go figure.

Right.  What happens if FSR happens to be pointing at a register which would
be affected by the read?

1997\02\21@130145 by David Tait

flavicon
face
John Payson wrote:

> Right.  What happens if FSR happens to be pointing at a register which would
> be affected by the read?

Even though movwf 0,w would be the obvious interpretation of opcode 0x0000
surely it would never be executed as such so we never have to worry about
where FSR points.  Or have I got that wrong?

David

1997\02\21@195354 by John Payson

picon face
> John Payson wrote:
>
> > Right.  What happens if FSR happens to be pointing at a register which would
> > be affected by the read?
>
> Even though movwf 0,w would be the obvious interpretation of opcode 0x0000
> surely it would never be executed as such so we never have to worry about
> where FSR points.  Or have I got that wrong?

Well, on the 16C74, a RETURN instruction (0x000D) does a read to port D (at
address 0x000D) which will clear the incoming byte flag if that port is used
in parallel-slave mode.  Draw your own conclusions (I would not rely on that
behavior, because Microchip may fix it, but AFAIK current silicon works that
way.  Fortunately, on the PIC very few things are affected by reads.

Consider as well, by the way, that CLRW may behave similarly; even if Mchip
adds logic to ensure that 000000x xxxxxxx instructions don't read memory, the
CLR instruction probably will continue to do so.

1997\02\24@040652 by Wolfram Liebchen

flavicon
face
At 18:42 21.02.97 -0600, you wrote:
>> > Right.  What happens if FSR happens to be pointing at a register which
would
>> > be affected by the read?
>>
>> Even though movwf 0,w would be the obvious interpretation of opcode 0x0000
>> surely it would never be executed as such so we never have to worry about
>> where FSR points.  Or have I got that wrong?
>
>Well, on the 16C74, a RETURN instruction (0x000D) does a read to port D (at
>address 0x000D) which will clear the incoming byte flag if that port is used
>in parallel-slave mode.  Draw your own conclusions (I would not rely on that
>behavior, because Microchip may fix it, but AFAIK current silicon works that
>way.  Fortunately, on the PIC very few things are affected by reads.
>

I can't believe, that PICs behave the way you say.
It should be easy, to decode special instructions in a way that they don't
have theses side effects you mentioned.
The data sheets _SHOULD_ also mention them?!?

regards

Wolfram


+-----------------------------------------------------+
| Wolfram Liebchen                                    |
| Forschungsinstitut fŸr Optik, TŸbingen, Deutschland |
| liebchenspamKILLspamffo.fgan.de                         |
+-----------------------------------------------------+

1997\02\24@085903 by mike

flavicon
picon face
In message  <3.0.32.19970224100413.009057b0@mira> .....PICLISTKILLspamspam.....MITVMA.MIT.EDU writes:
> At 18:42 21.02.97 -0600, you wrote:
> >> > Right.  What happens if FSR happens to be pointing at a register which
> would
> >> > be affected by the read?
> >>
> >> Even though movwf 0,w would be the obvious interpretation of opcode>
0x0000
> >> surely it would never be executed as such so we never have to worry about
> >> where FSR points.  Or have I got that wrong?
> >
> >Well, on the 16C74, a RETURN instruction (0x000D) does a read to port D (at
> >address 0x000D) which will clear the incoming byte flag if that port is>
used
> >in parallel-slave mode.  Draw your own conclusions (I would not rely on>
that
> >behavior, because Microchip may fix it, but AFAIK current silicon works>
that
> >way.  Fortunately, on the PIC very few things are affected by reads.
> >
>
> I can't believe, that PICs behave the way you say.
> It should be easy, to decode special instructions in a way that they don't
> have theses side effects you mentioned.
> The data sheets _SHOULD_ also mention them?!?
>

It sure seems to be worrying.

Can we have some comment from Microchip on this please? Brian?

Regards,


Mike Watson

1997\02\24@194012 by Eric Smith

flavicon
face
John Payson <EraseMEsupercatspam_OUTspamTakeThisOuTMCS.NET> wrote:
> Right.  What happens if FSR happens to be pointing at a register which
> would be affected by the read?

and later added:
> Well, on the 16C74, a RETURN instruction (0x000D) does a read to port D (at
> address 0x000D) which will clear the incoming byte flag if that port is
> used in parallel-slave mode.

Wolfram Liebchen <liebchenspamspam_OUTFFO.FGAN.DE> wrote:
> I can't believe, that PICs behave the way you say.
> It should be easy, to decode special instructions in a way that they don't
> have theses side effects you mentioned.
> The data sheets _SHOULD_ also mention them?!?

Yes, they should.  But they don't.

Another example of this is the CLRW instructions, which is described in the
data sheets as having the bit pattern 00 0001 0xxx xxxx, where the "x"s are
"don't care".

Originally the Microchip assemblers set all of the don't care bits to 0,
but if the FSR points to a register which has a side effect when read,
this coding will cause problems.  This is understandable since CLRW is really
just a ",W" variant of the CLRF instruction.

Recent versions of MPASM now use 00 0001 0000 0011 for CLRW, so the
superfluous read is to the PCL register, and has no side effect.  As far as I
know, the PIC data sheets have not been updated to reflect this.

It would appear that all the instructions in the range 0000h..0fffh hex
do a read, even the "special" instructions from 0000h..007fh:

       NOP     00 0000 0xx0 0000       (it appears that they have
                                       special-cased 0000h to not read IND,
                                       but I'm not sure about 0020h, 0040h,
                                       and 0060h)
       RETURN  00 0000 0000 1000       reads PORTD, TRISD, PORTG, TRISG,
                                       ADCON0, ADCON1, EEDATA, EECON1, or
                                       unimplemented, depending on the part
                                       and the RP0/RP1 bank switch bits
       RETFIE  00 0000 0000 1001       reads PORTE, TRISE, ADRES, EEADDR,
                                       EECON2, or unimplemented

The following instructions no doubt do an extraneous read also, but of
locations from 62h to 67h that are likely to always either be RAM or
unimplemented:

       OPTION          00 0000 0110 0010       (obsolete)
       SLEEP           00 0000 0110 0011
       CLRWDT          00 0000 0110 0100
       TRIS    PORTA   00 0000 0110 0101       (obsolete)
       TRIS    PORTB   00 0000 0110 0110       (obsolete)
       TRIS    PORTC   00 0000 0110 0111       (obsolete)

Eric

1997\02\24@201932 by John Payson

picon face
>         NOP     00 0000 0xx0 0000       (it appears that they have
>                                         special-cased 0000h to not read IND,
>                                         but I'm not sure about 0020h, 0040h,
>                                         and 0060h)

Hmm... perhaps they have special-cased NOP.  From what I can tell, at least
on 16C84's in 1995, MOVWF always does a read (which means there's no way to
change any bits on port B without clearing the port-changed latch).  I don't
know whether the UART on the 16C74 has this problem (it would be rather a
pain if trying to output a character to the UART would clear any character
that had 'just' come in)

>         RETURN  00 0000 0000 1000       reads PORTD, TRISD, PORTG, TRISG,
>                                         ADCON0, ADCON1, EEDATA, EECON1, or
>                                         unimplemented, depending on the part
>                                         and the RP0/RP1 bank switch bits

I think PORD is the only one of these where a read has any effect, however.

>         RETFIE  00 0000 0000 1001       reads PORTE, TRISE, ADRES, EEADDR,
>                                         EECON2, or unimplemented

Does a read of any of these addresses do anything on any 16Cxx device?  If
not, the superfluous read is a non-issue.

> The following instructions no doubt do an extraneous read also, but of
> locations from 62h to 67h that are likely to always either be RAM or
> unimplemented:

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