• If data translations are disabled (PSR.dt is 0) or the referenced I/O port is mapped
to an unimplemented virtual address (via the IOBase register), a GPFault is raised
on the referencing IA-32 IN, OUT, INS, or OUTS instruction.
• Alignment and Data Address breakpoints are also checked and may result in an
IA_32_Exception(AlignmentCheck)
IA_32_Exception(Debug) trap.
• If an IA-32 IN/OUT I/O port Accesses cross a 4-port boundary the processor will
break the operation into smaller 1, 2, or 3 byte transactions.
• Assuming no faults, a physical transaction is emitted to the mapped or specified
physical address.
The processor ensures that IA-32 IN, INS, OUT, OUTS references are fully ordered and
will not allow prior or future data memory references to pass the I/O operation as
defined in
wait for acceptance for IN and OUT operations before proceeding with subsequent
externally visible bus transactions.
10.7.4
I/O Port Accesses by Loads and Stores
If an access is made to the I/O port block using IA-32 or Itanium loads and stores the
following differences in behavior should be noted; EFLAG.iopl permission is not
checked, TSS permission bitmap is not checked, and stores and loads do not honor IN
and OUT memory ordering and acceptance semantics (the processor will not
automatically wait for a store to be accepted by the platform).
Virtual addresses for the I/O port space should be computed as defined in
Section 10.7.1, "Virtual I/O Port Addressing" on page 2:268
enabled, the TLB is consulted for mappings and permission, and the resulting mapped
physical address used to address the physical I/O device.
If IA-32 ordering semantics are required to a particular I/O port device (or memory
mapped I/O device), IA-32 or Itanium architecture-based software must enforce
ordering to the I/O device. Software can either perform a memory ordering fence
before and after the transaction, or use an load acquire or store release
To ensure the processor does not speculatively access an I/O device, all I/O devices
must be mapped by the UC memory attribute.
If IA-32 acceptance semantics are required (i.e. additional data memory transactions
are not initiated until the I/O transaction is completed), Itanium architecture-based
code can issue a memory acceptance fence. Conversely, if certain I/O devices do not
require IA-32 IN/OUT ordering or acceptance semantics, Itanium architecture-based
code can relax ordering and acceptance requirements as shown below.
OUT
[mf]//Fence prior memory references, if required
add port_addr = IO_Port_Base, Expanded_Port_Number
st.rel (port_addr), data
[mf.a] //Wait for platform acceptance, if required
[mf]
//Fence future memory operations, if required
2:272
Volume 2, Part 1: Itanium
Section 10.6.10, "IA-32 Memory Ordering" on page
®
Architecture-based Operating System Interaction Model with IA-32 Applications
fault (if PSR.ac is 1) or
2:265. The processor will
If data translations are
Need help?
Do you have a question about the ITANIUM ARCHITECTURE - SOFTWARE DEVELOPERS MANUAL VOLUME 1 REV 2.3 and is the answer not in the manual?
Questions and answers