Post by thread:Re[2]: Instruction encodings (was: Code error)

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_OUTsupercatTakeThisOuTMCS.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?

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 <.....liebchenKILLspam@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}>> > 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 | | liebchenKILLspamffo.fgan.de | +-----------------------------------------------------+

> 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?

John Payson <.....supercatKILLspam.....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

> John Payson <EraseMEsupercatspam_OUTTakeThisOuTMCS.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.

John Payson <supercatspam_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