Some CPUs (notably x86 CPUs) feature a parity flag on their status register. This flag indicates whether the number of bits of the result of an operation is odd or even.
What actual practical purpose does the parity flag serve in a programming context?
Side note: I'm presuming it's intended to be used in conjunction with a parity bit in order to perform basic error checking, but such a task seems to uncommon to warrant an entire CPU flag.
Back in the "old days" when performance was always a concern, it made more sense. It was used in communication to verify integrity (do error checking) and a substantial portion of communication was serial, which makes more use of parity than parallel communications. In any case, it was trivial for the CPU to compute it using just 8 XOR gates, but otherwise was rather hard to compute without CPU support. Without hardware support it took an actual loop (possibly unrolled) or a lookup table, both of which were very time consuming, so the benefits outweighed the costs. Now though, it is more like a vestige.
The Parity Flag is a relic from the old days to do parity checking in software.
TL;DR
As Randall Hyde put it in The Art of Assembly Language, 2nd Edition:
Parity is a very simple error-detection scheme originally employed by telegraphs and other serial communication protocols. The idea was to count number of set bits in a character and include an extra bit in the transmission to indicate whether that character contained an even or odd number of set bits. The receiving end of the transmission would also count the bits and verify that the extra "parity" bit indicated a successful transmission.
In the old days there was serial communication hardware (UART) that lacked the ability to do parity checking on transmitted data, so programmers had to do it in software. Also some really old devices like paper tape punches and readers, used 7 data bits and a parity bit, and programmers had to do the parity checking in software to verify data integrity. In order to be able to use parity bit for error detection communicating parties would have to agree in advance on whether every transmitted byte should have odd or even parity (part of a communication protocol).
The primary methods to do parity checking in software without CPU support are bit counting or using a lookup table. Both are very expensive compared to having a Parity Flag in a CPU computed by a single instruction. For that reason in April 1972 Intel introduced the Parity Flag into their 8008 8-bit CPU. Here is an example of how each byte could be tested for integrity on the receiving end since then.
mov al,<byte to be tested>
test al,al
jp <somewhere> ; byte has even parity
; byte has odd parity
Then a program could perform all sorts of conditional logic based on the value of the Parity Flag.
JPO, JPE), calls (CPO, CPE) and returns (RPO, RPE).JNP/JPO, JP/JPE).SETPE/SETP and SETPO/SETNP are added with Intel 80386.CMOVP/CMOVPE, CMOVNP/CMOVPO are added with Pentium Pro.This set of instructions which make use of the Parity Flag remained fixed since then.
Nowadays the primary purpose of this flag has been taken over by hardware. To quote Randall Hyde in The Art of Assembly Language, 2nd Edition:
Serial communications chips and other communications hardware that use parity for error checking normally compute the parity in hardware; you don't have to use software for this purpose.
The antiquity of the Parity Flag is proved by the fact that it works on low 8 bits only, so it's of limited use. According to Intel® 64 and IA-32 Architectures Software Developer Manuals the Parity Flag is:
Set if the least-significant byte of the result contains an even number of 1 bits; cleared otherwise.
Interesting fact: By his own words a networking engineer Wolfgang Kern scanned all code he had written at some point (~14 GB) for JPE and JPO instructions and found it only in an RS232 driver module and in an very old 8-bit
calculation.
There's one practical micro-optimization achievable with parity -- that's bit swapping as used eg in fourier transform address generation using the butterfly kernel.
To swap bits 7 and 0, one can exploit parity of (a&0x81) followed by conditional (a^=0x81). Repeat for bits 6/1, 5/2 and 4/3.
I was one of the original writers for Computer World New Zealand in the 1980's, and earlier had been an MIS Manager for a major utility, which used Datapoint computers. It was three men at Datapoint (formerly Computer Terminal Corporation), a Texan company based in San Antonio, who designed the 8008 in 1967: Victor Poor, Harry Pyle and Jonathan Schmidt. They asked Texas Instruments to make it, and it did, then decided not to continue with the building of microprocessors (not a great decision!). They then gave that task to Intel. In 1971 Datapoint introduced an 8K desktop machine wrapped round that chip, which by then had became the 8080 iirc, and in 1977 they invented the LAN, which they called the ARC (Attached Resource Computer), so they gave the world two very important advances. In 1967 Victor Poor had had the idea of running diskless machines over high-speed intercity links to central repositories of data (that would never catch on!). Hence 'Datapoint' analogous to power-point. It fell to Jonathan Schmidt, then a teenager, to write the code, and he told me he could not write code that would run fast enough to check parity, so he put a parity flag into the chip. When I interviewed him, the 80286 was the level reached, and he said to me: 'Funny thing, that flag's still in the chip.' Datapoint had continued developing the chip till the 286, then handed development to Intel. So that is why there's a parity flag: teenager Jonathan Schmidt could not write code that would run fast enough to check parity on the first cut of that chip when it was being designed in Victor Poor's house in 1967.
Personally, I think that rumours of the parity flag's death have been greatly exaggerated. It can be extremely useful in certain circumstances. Consider the following assembler language procedure:
push rbp
mov rbp, rsp
xor eax, eax
ucomisd xmm0, xmm1
setnp al
pop rbp
ret
This takes two double-precision arguments in xmm0, xmm1, and returns a boolean result. See if you can figure out what it's doing.
Sometimes you just need to wait until somebody comes up with a clever use case for abandoned features: Efficient n-states on x86 systems
With just one test, it's possible to check a variable for 4 states like this:
; flag = {-1, 0, 1, 3}
testl $-1,flag ; and flag with -1 and set condition codes
jz case_1 ; jump if flag == 0
js case_2 ; jump if flag < 0
jp case_3 ; jump if flag > 0 and flag has even parity
; flag > 0 and has odd parity
Furthermore, it's possible to make branches in a fashion JNNJNJJNNJN… or NJJNJNNJJNJ… (J=Jump; N=No Jump)
Things I can think of are:
