The challenge was to find a HAL workload that stays integer and never
converts to float. I think that is the wrong test. Almost nothing avoids
conversion, so by that test integers always look unnecessary. The right
test is whether a double can represent the value at all, and a double is
integer-exact only up to 2^53.
We do not have to hypothesize, because we already hit this. hostmot2
computes a 64-bit internal encoder accumulator specifically to stop
high-count encoders wrapping:
// 64-bit internals prevent the count wrap that would otherwise make
float position jump.
// Not exposed as HAL pins; s32 pins above are truncated views.
rtapi_s64 rawcounts_64;
So the case Rene says does not exist is in the tree today. This is the
whole arc of issue #2331: stepgen and sserial already hold s64
internally, hostmot2 followed (#3944), and exposing those counts as HAL
pins was tried as parallel _64 pins and dropped because it doubled the
pin set, broke configs, and had no clean type story. So we compute the
64-bit value and then throw it away at the pin boundary for lack of a
decent 64-bit pin. That, not counting in the abstract, is why an integer
pin type earns its place.
Most integer use in HAL (indices, tool numbers, gcode line, bounded
position) fits inside 2^53 and there float is genuinely fine. A linear
scale reports bounded position and never gets close, even at nanometer
resolution. But an accumulating high-count encoder does not, and that is
core motion data.
And this is the wrong moment to design for only today. Bit-width needs
have only ever grown, 8 to 16 to 32 to 64, and every boundary was hit
later than expected with an expensive retrofit (Y2K, IPv4, the 2038
time_t problem). The drivers are not speculative: absolute encoders went
from 13-bit to 23 and 26-bit as standard within a decade, and modern
fieldbuses already carry 64-bit registers. 64-bit is not arbitrary
headroom either, it is the machine word and the widest value real
hardware actually produces, so there is a natural stopping point, not a
slippery slope to 128. The cost is what is asymmetric: adding the 64-bit
pin path now, while we are already breaking the API, is nearly free,
whereas retrofitting it once more devices ship means another churn
across every component.
So "why integers at all" has a concrete answer: so the 64-bit values we
already compute can cross the pin boundary without being truncated or
rounded, and so the path exists before the next generation of encoders
and fieldbus needs it. Not for counting in general, but for these it has
to stay.
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
