17

The x86 "flags" register, which holds condition codes and other processor status bits, has several reserved bits with fixed values, but these fixed values are not all the same. In particular, bit #1 (the twos place, considering the register as holding a number) always reads as 1, whereas bits #3 and #5 read as 0. According to Bit one of the Intel 8080's Flags register this has been true since the 8080 (which did not technically have a flags register, but did have a "push all the status bits onto the stack" instruction, that wrote these bits to memory as shown).

Normally, I expect reserved bits to be uniformly wired to either zero or one, with zero being more common. So, the question: Does anyone know of the original reason, whether documented, leaked, rumored, reverse-engineered, or otherwise, why the 8080's "push the status bits" instruction wrote one of the three reserved bits as 1 and the other two as 0?

Improve this question
6
  • 6
    There a chance that's Intel ended up with it being 1 rather than chose. The early ICs were laid out by hand and mistakes would happen or stuff couldn't be squeezed into tight spots. Guess it might just be one of those.
    – TonyM
    Feb 8, 2022 at 17:59
  • 2
    Intriguingly, bits 1 and 5 are used on the 8085, but not documented; bit 1 encodes the V flag (signed overflow). So the 8086 is backwards-compatible with the documented interface of the 8085, not its actual behaviour, which serves as a counter-argument to “the 8086 had to keep bit 1 set to 1 since the 8080 implemented it that way”.
    – Stephen Kitt
    Feb 9, 2022 at 15:10
  • @StephenKitt Isn't the argument is still true? The bit was 1 on an 8080 and is one on the 8086. The V flag got put 'back' out again - or better back up :))
    – Raffzahn
    Feb 9, 2022 at 22:56
  • 1
    @Raffzahn I don’t think it is true. Saying that the bit has to be 1 on the 8086 because it was 1 on the 8080 relies on backwards-compatibility covering undocumented features as well as documented features; yet Intel’s story around the 8085 shows that that is not the case. The 8086 flags are backwards-compatible with the 8085’s, but only for documented flags. That means that undocumented flags don’t “count” in a backwards-compatibility claim; bit 1 could be 0 in 8086 flags without affecting Intel’s claims regarding either the 8080 or the 8085.
    – Stephen Kitt
    Feb 10, 2022 at 8:34
  • 1
    The 8080 backwards-compatibility story is better if bit 1 is kept the same as it was on the 8080, but the way the flag was handled (both its implementation and its documentation) in the 8085 shows that it wasn’t necessary.
    – Stephen Kitt
    Feb 10, 2022 at 8:35

2 Answers 2

Reset to default
2

I'm looking into this repository https://github.com/1801BM1/vm80a, which have the original die photos of the KR580VM80A (a clone of i8080), its reverse-engineered transistor-level schematics and simplified yet fully correct and synthesizable verilog model as a final result.

First let's take a look at the verilog model (https://github.com/1801BM1/vm80a/blob/master/org/rtl/vm80a.v), on lines 141-279 there's a multiplexor that drives internal data bus with several sources. When alu_frd signal is active, the bus is driven with PSW contents, including the one on D1 and zeros on D3 and D5.

The more detailed explanation is in the reverse-engineered schematics (https://github.com/1801BM1/vm80a/tree/master/sch). I prefer to browse it with p-cad schematics editor, as it has some primitive search facilities, which absent completely in the pdf schematics.

The transistors T2066, T2067 (lower right part of the second page in pdf) and below drive PSW contents on the bus, leaving D1 undriven and driving zeros on D3 and D5.

The transistors T4641 and T4642 (lower right part of the fourth pdf page) would prechange D1 at some other time, giving the desired logic one.

Improve this answer
-3

Why is bit 1 of the x86 [e]flags register always set to 1, rather than 0?

Because of compatibility with the 8080/8085.

After all, the most important design goal for the 8086 was low effort in porting 8080 software. That's why there is the otherwise strange LAHF instruction, as it create the 8080's PSW. Having the 'unused' bits within the lower half of the flags register set the same way allowed the use of LAHF + PUSH AX to emulate an 8080's PUSH A as well POP AX + SAHF to emulate an 8080's POP A.

As so often, Michael Steil has some noted about further development form there.

Improve this answer
13
  • 10
    That was not the question. The question was why did the 8080 set this bit to 1.
    – zwol
    Feb 8, 2022 at 19:26
  • 3
    @zwol Now, if that isn't the question, why did you put it the title? And accordingly in the text as well, as you're referring thruout to 8086 (or x86), mention 8080 only as a side note.
    – Raffzahn
    Feb 8, 2022 at 20:33
  • 4
    @zwol You totally changed the meaning of your question, as can be seen clearly by its history. Let's give Raffzahn a chance to adjust his answer, and take back your down-votes.
    – the busybee
    Feb 9, 2022 at 9:01
  • 3
    @Raffzahn but the only question in the body refers to the 8080. I agree the question was poorly phrased initially (and the title was misleading), but the current version seems clear enough to me. (I’d understood the first version as also asking about the 8080, but I also understand why you thought it was about the 8086.)
    – Stephen Kitt
    Feb 9, 2022 at 11:01
  • 7
    @WayneConrad Looking back at the original phrasing of the question I still do not see how someone can read "it has been that way since the 8080", immediately followed by "why did Intel choose to make it that way", and not understand me to be asking about the 8080.
    – zwol
    Feb 10, 2022 at 0:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .