when accessing a 16- and 32-bit I/O port, the operand-size attribute determines the port size.

When operating in real-address mode, the default addressing and operand size is 16 bits.

Is there anything unclear in the manual?:

Wow, I see it first time in the manual. Which volume is it? I usually use Volume 3-A as usually it explains what I need. And port IO sizes in manual looks everything is like I thought. I was using 16 bit IOs for these opcodes, too.

But the processor doesnt trigger #GP for operand size override prefix, what should I do for it?

Could acessing and testing CS:(EIP-1) with operand size override prefix work, as opcode prefixes are just before the opcode?

Bad idea. It can be the last byte of the preceding instruction or even data. Don't do that. If you get a real exception, the code address will point at the beginning of the offending instruction, not its middle. And then you parse the instruction, noting all of its prefixes, ModR/M, SIB and imm bytes and (d)words... I know, parsing x86 instructions sucks. If you're using a library to parse instructions, find out how to extract this info from it. It must be there or it wouldn't make sense to just tell you to emulate access without telling you the location or the size or both.

Also note that you can use the "IO permission bitmap" (in the TSS) to give a Virtual8086 task permission to use specific IO ports (without causing any general protection fault). You can also set "IOPL =3" if you want to give a Virtual8086 task full access to all IO ports (e.g. if you're writing a DOS extender or something and not writing an OS).

Intel® 64 and IA-32 Architectures Software Developer’s Manual
Combined Volumes: 1, 2A, 2B, 3A and 3B (May 2011 version)

Vol 1, section 3.3.5, 32-Bit and 16-Bit Address and Operand Sizes.

Vol 2A, section IN—Input from Port.

Learn to use the table of context and search.



If you have a correctly encoded instruction (with a prefix or without) not trying to violate any protection, why should it?



Bad idea. It can be the last byte of the preceding instruction or even data. Don't do that. If you get a real exception, the code address will point at the beginning of the offending instruction, not its middle. And then you parse the instruction, noting all of its prefixes, ModR/M, SIB and imm bytes and (d)words... I know, parsing x86 instructions sucks. If you're using a library to parse instructions, find out how to extract this info from it. It must be there or it wouldn't make sense to just tell you to emulate access without telling you the location or the size or both.

My computer is really slow, so I can't use combined volumes, also scrolling is really hard. That is why I can't use table of content, as I only use the Volume 3-A. I also tried printing all of Intel documentation, but it's over 3000 pages, as you know. Maybe I need a lightweight and fast PDF viewer instead of browser's built-in PDF viewer.

And my tests in V8086 shows code address points really in middle. 66 ED causes a GPF, but CS:IP points ED instead of 66.

Then get yourself INTEL 80386 PROGRAMMER'S REFERENCE MANUAL 1986. It's a text file, less than 1MB in size and it has everything you need right now.



Then you have bugs in your code or someone else's code you're using (including any VM software in which you're making your OS experiments).