3

In 8086, OF is put not into low Flags byte as other flags but separated in the second (high) byte. This is followed then in all the x86 line. Beside the possible historical reasons, this looks highly strange. The low byte still has only 5 used bits; 3 bits are hardwired (to 0 or 1).

Is there a known motivation for such a solution?

I seem failing to explain this with 8080 compatibility, as the latter has no OF at all, and a software wouldnʼt depend on spare bits.

Improve this question

1 Answer 1

Reset to default
3

I seem failing to explain this with 8080 compatibility,

But that's exactly the point here - that way the flag byte is fully 8080 compatible. No matter what any software does to these bits. It will make sure that all (automatic) ported 8080 software does not create side effects.

There is no reason not to use the upper 8 bits, since the 8086 flag word is straight 16 bit (read: not twice 8). Using any of the upper 8 can be done freely, as they are unknown to and unreachable by 8080 software.

as the latter has no OF at all, and a software wouldnʼt depend on spare bits.

But 'manually' creation of the flag byte could result in unintended (re-)setting them. Just imagine some software creating an 8080 flag byte, maybe to set various bits to return the result of a subroutine. no matter what default it uses, it would (re-)set OF as well.

Yes, this wouldn't matter in strict 8080 code, but what about the same software get enhanced at some point with 8086 code calling it? It opens all the problems of very nasty incompatibility issues. Keep in mind, this is all about continued use of large chunks of older software.

By keeping the lower 8 bit 100% 8080 compatible all of this is avoided at no cost.

This question opens a rather interesting follow up:

Why you assume it should have been moved into the lower 8 bit?

And what good would it have brought?

Improve this answer
7
  • 3
    The only benefit I can see is it would make LAHF/SAHF more useful to native 8086 code, as they could then access the overflow flag. There's no directly comparable instruction to transfer the whole 16-bit FLAGS to and from a general-purpose register; only PUSHF/POPF which are more awkward.
    – Nate Eldredge
    Nov 21, 2021 at 16:43
  • @NateEldredge Why? It's the only way to access the flag register on an 8080, so not really worse on the 8086. In fact, for 8086 code it would be really useful to be able to test or read the direction flag, as any routine using string operations need to manipulate it. Personally, in may years of 8086 programming, I never used LAHF at all. but ofc. that's just me.
    – Raffzahn
    Nov 21, 2021 at 17:01
  • 2
    "but what about the same software get enhanced at some point with 8086 code calling it?" - Flags are never (except DF) requested to keep across subroutine calls. I canʼt imagine other variant of deep mixing of 80-ported and 86-native code.
    – Netch
    Nov 21, 2021 at 18:08
  • 1
    @Netch "Flags are never (except DF) requested to keep across subroutine calls" Who says that? Serious, in 'ye goode olde days' it was quite common to handle flags the same way as any other storage. Including certain routines not changing them. And yes, ported 8080 software would not use OV, but they do expect certain flag configuration - including the unused bits.
    – Raffzahn
    Nov 21, 2021 at 22:38
  • 2
    @Raffzahn "Including certain routines not changing them." - Then, they save full flags register and restore them. "but they do expect certain flag configuration - including the unused bits." - Really for unused ones? This may be the reason but I hardly imagine such a case...
    – Netch
    Nov 22, 2021 at 8:45

You must log in to answer this question.

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