VOGONS


First post, by superfury

User metadata
Rank l33t++
Rank
l33t++

According to the manuals I can find, the MUL and IMUL instructions (both byte and word sized) only affect the carry and sign flags (set or cleared depending on AX or DX::AX overflow).

However, I find some strange bit of CPU detection code in the Super PC/Turbo XT BIOS 2.5 (detecting 8088 vs V20 CPU):

;---------------------------------------------------------------------------------------------------
; Detect CPU type (8088 or V20)
;---------------------------------------------------------------------------------------------------
proc cpu_check near ; Test for 8088 or V20 CPU

xor al, al ; Clean out al to set ZF
mov al, 40h ; mul on V20 does not affect the zero flag
mul al ; but on an 8088 the zero flag is used
jz @@have_v20 ; Was zero flag set?
mov si, offset str_8088 ; No, so we have an 8088 CPU
ret
@@have_v20:
mov si, offset str_v20 ; Otherwise we have a V20 CPU
ret

endp cpu_check

According to this code, the zero flag is affected like other instructions with 8-bit MUL instructions? What about 16-bit MUL instructions and IMUL instructions? Does the zero flag work or not?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 1 of 12, by Jepael

User metadata
Rank Oldbie
Rank
Oldbie

I don't know if this applies to 8-bit or 16-bit or both, but I see the same info regarding detecting CPUs here:

http://stanislavs.org/helppc/cpu.html

Edit: it appears the Z flag could reflect some bit of internal storage used in intermediate stages of calculation.
It is possible that after the specific multiply in the detection code the Z flag is always set to 0 on real 808x and always untouched on V20.

Reply 2 of 12, by superfury

User metadata
Rank l33t++
Rank
l33t++

I've added the zero flag 'bug' in my latest 808x CPU core commit.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 4 of 12, by superfury

User metadata
Rank l33t++
Rank
l33t++

Strangely on all manuals I can find, they tell me that MUL only affects the carry and sign flags. All other flags are 'undefined'? What's up with those so-called 'undefined' flags? ZF doesn't seem to be entirely undefined (it seems to be half-working? Only clearing and not setting?)

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 5 of 12, by vladstamate

User metadata
Rank Oldbie
Rank
Oldbie

To complicate matters more I think I've seen PCEm only updating the Zflag based on the lower 16bit register (AX). So for 16bit multiply where the result would be in DX:AX it only checks the AX to set the flag. I think fake8086 does that too. That expands to 32bit multiply where they only look at EAX.

YouTube channel: https://www.youtube.com/channel/UC7HbC_nq8t1S9l7qGYL0mTA
Collection: http://www.digiloguemuseum.com/index.html
Emulator: https://sites.google.com/site/capex86/
Raytracer: https://sites.google.com/site/opaqueraytracer/

Reply 6 of 12, by Jepael

User metadata
Rank Oldbie
Rank
Oldbie

Even on Pentium 4, SF, ZF, AF and PF are undefined after MUL/IMUL.
It's just undefined, meaning, it could be set, or unset, so you can't determine anything from it.
Because it is undefined, it is just as correct to always clear it, always set it, always preserve its value, set it randomly or actually set it correctly based on result but nobody would use the result.
It could depend on source values, or destination values.
And as you see, different CPUs work differently.

Reply 7 of 12, by peterferrie

User metadata
Rank Oldbie
Rank
Oldbie

No, that's not true at all. They are very well defined, I'm just not allowed to tell you exactly how, but vladstamate is correct when he sees that only the lower half of the result is contributing to the effect.

Reply 8 of 12, by superfury

User metadata
Rank l33t++
Rank
l33t++

So the bits are very well defined, but hidden from most programmers? Why would Intel hide information that a program might use during execution? Especially since it might affect execution flow (like this BIOS using it to detect 8088 processors vs V20 processors)? Like this actual 'accurate' emulators can't be made when information when such a basic result is hidden? Software depending on it might actually crash on any emulator actually following the processor specs itself, instead of observed information? Or it might assume something according to docs and emulators, but crash when ran on an actual processor? Is this why they actually documented as 'undefined'?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 9 of 12, by peterferrie

User metadata
Rank Oldbie
Rank
Oldbie

They are documented as "undefined" in order for the behaviours to be removed in the future, primarily to increase performance. The most interesting bits from Intel's point of view are the ones that are truly documented.
That's as much as I can say about it.

Reply 10 of 12, by superfury

User metadata
Rank l33t++
Rank
l33t++

There's one thing I wonder now: Why do you (peterferrie) know about those flags(since you say that's about as much as you can(are allowed) to say about it)? Since it's officially undocumented and unusable on newer processors, why would you need to know about it (if it can't be used in normal software, it's practically useless to know since it can't be used on a modern CPU)? No software can actually use it if it's inconsistent with different CPUs, so it's useless in that aspect? Except for viruses etc.(saw some information about your job at antivirus companies>)?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 11 of 12, by peterferrie

User metadata
Rank Oldbie
Rank
Oldbie

I was working on a research project over a decade ago (intended to be a conference talk that wasn't accepted), which led to questions which required a pact with the devil (NDA) for the answers.

Reply 12 of 12, by Stiletto

User metadata
Rank l33t++
Rank
l33t++
peterferrie wrote:

I was working on a research project over a decade ago (intended to be a conference talk that wasn't accepted), which led to questions which required a pact with the devil (NDA) for the answers.

Peter Ferrie, one of my favorite Internet people 😁

"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen

Stiletto