On Tue, 15 Mar 2005 Roger Merchberger <zmerch at 30below.com> wrote:
Rumor has it that William Donzelli may have mentioned
these words:
Parity checking is the job of the memory
controller, not the processor. In
fact, I am having a hard time thinking of a processor that did its own
parity checking in software (yes, I know any processor could do it, but
did any really do it?).
8085? There's a P bit in the condition code register (in 6809 speak) -- I
think it's called the PSW -- Program Status Word? I'm just beginning
learning assembly on my Tandy 10x/200 machines... Anyway, there are several
arithmetic operations that automatically set the Parity bit and there are
branch and return instructions that utilize the status of the P bit.
Unless the 8085 differs from the Z80 (which both come from the 8080) this
P-bit is used as parity very loosely speaking.
It's actually P/V-bit. For arithmetic operations, it indicates overflow
(V), while for logical operations it indicates parity of the result (P).
Logic ops simply count the number of "1"s in the result, and set the P bit
if the number is odd.
Can be useful if you want to generate or check parity for data you're
communicating. (Serial communication sometimes don't have hardware parity
implemented for example).
Parity for memory is never something dealt with by software. It would be a
chicken and egg situation.
Even if the
parity checking is a lowly 74180, like
in a microcomputer - it is still not boggin down the processor. The
processor really doesn't need to know about parity, unless things go bad.
Altho it's not a *huge* need, it can be handy for serial I/O... that would
be a function that uses parity, but is not reliant on the memory controller.
Yes.
But this is two different parity issues. Parity for memory is dealt with
by hardware. Parity for communication might be dealt with by hardware or
software.
Johnny
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at update.uu.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol