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?