Searching \ for 'Re[2]: 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+RE%5D
Search entire site for: 'Instruction encodings (was: Code error)'.

Truncated match.
PICList Thread
'Re[2]: Instruction encodings (was: Code error)'
1997\02\21@124506 by Craig Knotts

flavicon
face
    I don't follow.

    On the 16C5x, at least, NOP is 0x000, while movf 0,w would be 0x200
    and movwf 0 would be 0x020.  The only thing that NOP might code to
    would be tris 0, which is of course a nonsense operation.


______________________________ Reply Separator _________________________________
Subject: Re: Instruction encodings (was: Code error)
Author:  John Payson <spam_OUTsupercatTakeThisOuTspamMCS.NET> at Internet
Date:    2/21/97 9:07 AM


> 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\24@140438 by Brian Boles

flavicon
face
    The first 16C5X PIC devices would generally do an extraneous read of
    the memory at whatever address the least significant 5 bits pointed
    to.  This saved transistors and on devices without a lot of
    peripherals was safe to do.
   
    On the '74, as peripherals were added, this became more involved and
    location 000D was overlooked.
   
    On all new devices such as '74A, the instruction decoder PLA treats
    literal and control instructions as special cases and shuts off the
    read logic.
   
    BTW, the NOP reading the FSR was never a problem as the PLA always
    accounted for that.  The NOP is actually MOVWF 0,W which will only
    move W to W and a read of FSR is disabled.  That PLA term that
    disables the read is now generalized to disable all inadvertent reads.
   
    Rgds, Brian.


______________________________ Reply Separator _________________________________
Subject: Re: Instruction encodings (was: Code error)
Author:  Wolfram Liebchen <.....liebchenKILLspamspam@spam@FFO.FGAN.DE> at Internet_Exchange
Date:    2/24/97 10:04 AM


At 18:42 21.02.97 -0600, you wrote:
>> > Right.  What happens if FSR happens to be pointing at a register which
would
{Quote hidden}

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@204204 by John Payson

picon face
>      BTW, the NOP reading the FSR was never a problem as the PLA always
>      accounted for that.  The NOP is actually MOVWF 0,W which will only
>      move W to W and a read of FSR is disabled.  That PLA term that
>      disables the read is now generalized to disable all inadvertent reads.

Hmm... methinks perhaps my code to test that case must have been broken.  Most
sorry about that... I wouldn't want to give Microchip any undeserved bad rep-
utation.  If I might ask though...

[1] Does the generalized PLA term correctly screen out the MOVWF and CLRW
   instructions as well?

[2] Are there any 16C74's out there where writing a character to the serial
   port would risk "reading" one?  If so, but this quirk has been changed,
   when did this change come about?

1997\02\24@221836 by Eric Smith

flavicon
face
John Payson <.....supercatKILLspamspam.....MCS.NET> wrote:
> [2] Are there any 16C74's out there where writing a character to the serial
>     port would risk "reading" one?  If so, but this quirk has been changed,
>     when did this change come about?

The UART has separate Rx and Tx regs, probably because they discovered the
MOVWF problem very early on.  Too bad they didn't think to do the same for
the parallel host port.  Although that still would have left the RETURN
problem.

Cheers,
Eric

1997\02\25@000933 by John Payson

picon face
> John Payson <EraseMEsupercatspam_OUTspamTakeThisOuTMCS.NET> wrote:
> > [2] Are there any 16C74's out there where writing a character to the serial
> >     port would risk "reading" one?  If so, but this quirk has been changed,
> >     when did this change come about?
>
> The UART has separate Rx and Tx regs, probably because they discovered the
> MOVWF problem very early on.  Too bad they didn't think to do the same for
> the parallel host port.  Although that still would have left the RETURN
> problem.

True, though Microchip has indicated that they've fixed that too in new
silicon.  IMHO, the host port as Microchip implements it is still somewhat
limitted, however, since there is no good way to distinguish commands from
data without adding more external logic.  Think what you like about the
8042's instruction set, but having two read addresses and two write addresses
from the host's point of view can really improve things a lot.

1997\02\25@124020 by Eric Smith

flavicon
face
John Payson <supercatspamspam_OUTMCS.NET> wrote:
> IMHO, the host port as Microchip implements it is still somewhat
> limitted, however, since there is no good way to distinguish commands from
> data without adding more external logic.  Think what you like about the
> 8042's instruction set, but having two read addresses and two write addresses
> from the host's point of view can really improve things a lot.

Agreed.  When I first saw the specs, I thought, "Wow, finally a decent
8041/8042 replacement" (since Intel's never done a decent one since).
Given how ubiquitous the 804x are, you'd think someone at Microchip would
have bothered to actually look at it for ideas as to how to make a *usable*
host port.  :-(   Mitsubishi, who I usually don't credit for being
exceptionally clueful, managed to get that right on their 3745x parts.

I'd really like to see three separate registers for data and commands written
by the host to the PIC, but even a single register for both would be OK if
they'd save a 9th bit like to 804x.

Sigh.  Maybe someday some semi company will accidentally stumble onto the
combination of great engineering *and* low prices.  I haven't yet become
convinced that it's impossible.

Maybe we could convince Microchip to send a few of us very early
(pre-tapeout) engineering specs to look over to try to avoid silly design
flaws and limitations like this.

Cheers,
Eric

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