• Cecil Ward (27/27) Apr 04 2023 Re eg https://dlang.org/library/core/bitop/inp.html

Cecil Ward <cecil cecilward.com> writes:

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?