Does xtize handle shift counts > 31 in CL by masking the shift count? (186 instruction set detection)

[ecm-pushbx]

I was wondering whether xtize allows to detect an 186 in the usual way, that is to check whether large shift counts passed to a shift/rotate instruction in CL are masked with 1Fh. Example CPU detection: https://hg.pushbx.org/ecm/ldebug/file/0b8e271496a3/source/init.asm#l3056

Well-behaved programs may try to detect an 186 or 286 in this way before running instructions not supported on the 8088/8086. So I think xtize should also make these checks succeed.

[skitt]

I can see two scenarios for this:

• programs which check for a 186/286, and fail if one isn’t found
• programs which check for a 186/286, use “optimised” code if one is found, and fall back to 8086-compatible code if not

In the latter case, handling detection would be undesirable; but it would in the former.

[karcherm]

Currently, XTIZE does not try to make the processor appear as 186 or 286, using either the shift count or the PUSHF/POPF technique. The target is to make programs run on an 8088/8086 that were compiled using Microsoft C or Turbo C with the target processor set to "286", and those programs do not include a processor check, but just crash if they get executed on a 286.

I have to admit that I currently am not actively working on this project, one of the reasons being that the XT machine I wrote it for currently has a V20 installed, and furthermore, I am currently not that engaged with that machine at all. If you have a use case that makes you want to have something like XTIZE, feel free to fork it, or to submit feature requests. They might motivate me to spend some time on polishing it. Keep in mind that the performance of this approach (running the whole program in single step mode) is extremely low, so it is only useful for cases where simple software is "needlessly 286 optimized".

I do see the possiblity of XTIZE to include a command line switch that patches the emulator to either include or not include "186/286 detection". My subjective observation is that more software uses the PUSHF/POPF way of detecting a 286 (or better) than the shift-count way of detecting a 186 (or better), even if it's not about protected mode, but just about 186 features like REP INSW. So if faking a 186/286 for processor identification is a requirement, I would suggest to go "all 286" and emulate 286-like flag behaviour as well.