bcase@amdcad.UUCP (Brian case) (06/19/85)
I read the following in the "WE 32100 Microprocessor Information
Manual" section 3.6.6 Stack and Miscellaneous Instructions:
If an instruction, other than a conditional transfer, reads
the PSW, the assembler m32as inserts a NOP before that
instruction. This allows time for the PSW codes to settle
before the new instruction tries to access them.
Ahem. Allows the codes to settle? Don't they need to settle before
the conditional transfer can reliably take place? Oh well, not a
very big bug because explicit access of the PSW should be rare in
user code, but come on guys, be honest! It's a bug! :-)
bcase
Ok, now look. The views stated here are only those of a few brain
cells that worked correctly yesterday but are probably dead by today
anyway. They don't possibly represent the views of anyone I work
for or ever worked for.darrell@sdcsvax.UUCP (Darrell Long) (06/22/85)
I did some tests on the code generated by the 3B-2 C compiler, including some of the ``standard utilties'' and NOP's make up nearly 10% of the code. Agreed, this is a bug. As for the previously mentioned RESTORE instruction, it was privately confirmed that there is a problem with it when used in a virtual memory environment (which SYS VR2 is not). This is why it is mapped to a sequence of POPW's. -- Darrell Long Department of Electrical Engineering and Computer Science University of California, San Diego USENET: sdcsvax!darrell ARPA: darrell@sdcsvax
johnl@ima.UUCP (06/22/85)
> If an instruction, other than a conditional transfer, reads > the PSW, the assembler m32as inserts a NOP before that > instruction. This allows time for the PSW codes to settle > before the new instruction tries to access them. > > Ahem. Allows the codes to settle? Don't they need to settle before > the conditional transfer can reliably take place? Sounds pretty smart to me. Why waste chip real estate with locking circuits that'll be used .0001% of the time? I expect that the WE 32100 chip special-cases the interlocking between branches and the tests they depend on. For that matter, the 360/91 did that 15 years ago. Speeds up the sorts of things that programs do all of the time, while only slightly complicating obscure stuff. It really is a feature, not a bug. John Levine, ima!johnl
ed@mtxinu.UUCP (Ed Gould) (06/25/85)
In article <1680@amdcad.UUCP> bcase@amdcad.UUCP (Brian case) writes: >I read the following in the "WE 32100 Microprocessor Information >Manual" section 3.6.6 Stack and Miscellaneous Instructions: > > If an instruction, other than a conditional transfer, reads > the PSW, the assembler m32as inserts a NOP before that > instruction. This allows time for the PSW codes to settle > before the new instruction tries to access them. > >Ahem. Allows the codes to settle? Don't they need to settle before >the conditional transfer can reliably take place? That's not necessarily a bug at all. It's probably the case (I don't have any particulars on the WE chip) that the conditional transfer instructions are interlocked so that they will always read the correct codes (or perhaps they get the codes from an internal register other than the PSW). Other instructions rarely care about the condition codes when accessing the PSW, so it's not unreasonable to make the programmer (or in this case the assembler) be careful about timings like that. I expect that the condition code-to-PSW loop was a long part of the instruction cycle, so they decided to relax the "finish this one before starting the next" requirements somewhat to keep things going fast. It's certainly not a feature, though. -- Ed Gould mt Xinu, 2910 Seventh St., Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146 "A man of quality is not threatened by a woman of equality."
darrell@sdcsvax.UUCP (Darrell Long) (06/30/85)
Well, by looking at the code generated by the 3B-2/300 sitting beside me, I get some interesting results. Fully 10% of the code is made up of NOPs. Futher, NOPs are inserted in some very peculiar places. TSTW NOP BEB # a conditional branch! MOVW NOP PUSHW MOVW NOP MOVW CLRW NOP ADDW3 CLRW NOP MOVAW It should be noted that the insertions are by no means consistent, unless there is some strange alignment scheme (which would be a bug) that I haven't noticed. The above examples contain only mundane addressing modes, and no access to the PSW. -- Darrell Long Department of Electrical Engineering and Computer Science University of California, San Diego USENET: sdcsvax!darrell ARPA: darrell@sdcsvax