Question about the x86/AMD64 io-port space r/w instructions such as inp()
Cecil Ward
cecil at cecilward.com
Wed Apr 5 02:42:59 UTC 2023
Re eg https://dlang.org/library/core/bitop/inp.html
1. Shouldn’t these functions take a port address argument of type
uint16_t, rather than a 32-bit argument ? If nothing else it
would be worthy interface documentation for callers.
I don’t believe there are any post-1986 x86/amd64 processors that
have a port io/space larger than 16 bits - is that correct?
We could perhaps check the port value <= 0xffff at compile-time
preferably, or at run-time in a debug build ? (Wouldn’t want a
runtime range checks left in in asserts in a release build.)
2. An additional point: If we can make a specialisation for port
address of type uint8_t then we can generate better code for
ports <= 0xff. We might have opportunities for so doing at
compile time.
I’m not at all sure how to write conditional code to detect
whether a variable or argument’s value is known at compile time
or not. I have struggled with that before, trying to get
specialisations of overload functions or templates where a
compile-time known value can be exploited to generate better
code, and even better code still if we can then go on to spot
certain particular special constant values, for example to
generate alternative optimal specialised instructions, or to
generate opcodes that have immediate arguments.
I assume writing an overload that takes a uint8_t port address
argument wouldn’t work as the compiler wouldn’t spot the need to
pick the best specialisation? Or am I wrong?
3. Is the current code capable of generating the opcode for an
immediate port address?
More information about the Digitalmars-d
mailing list