Re: [Emc-developers] on the integer question by Rene

[Luca T. <lu...@ai...>]

>> On 64-bit masks being hypothetical: they already exist. The EtherCAT
>> distributed clock is a 64-bit value and the Beckhoff EL5032 puts a
>> 64-bit count on the PDO, both in linuxcnc-ethercat now. The hi/lo
>> split
>> is what we do today, and it's the thing to avoid, not the fallback:
>> two
>> pins tear (low from one cycle, high from the next, off by 2^32) and
>> tools can't show the real value.
> It is not obvious if those enourmous ranges of values really are needed
> and if it could be acceptable to limit the range.
>
>
> Anyway, it is a tradeoff, the question is what is more inconvenient,
> having different pin types that are a hassle and require a number of
> conv_X_Y components and generally complicate everything or having to
> deal with some exceptional cases where 64bit integers would have to be
> either truncated or split into two pins.

That's a fair way to frame it, and you're right on two counts: the 
six-type plus conv_* zoo is a genuine hassle, and in practice the huge 
ranges can often be limited without anyone noticing. No argument there.

But I think the tradeoff as posed is a false binary, "type hassle with 
conversions" versus "one double with a few 64-bit exceptions." There's a 
third option, and it dominates both. The conv_* clutter comes from 
having six numeric types (n-squared conversions), not from types 
existing at all. Trim to three, bool, real, int, where int absorbs 
s32/u32/s64/u64 and carries bit patterns, and the conversion matrix 
nearly vanishes (only real-to-int remains, the one crossing that 
genuinely matters). You get rid of the hassle you dislike and keep clean 
integer wrap and bit patterns. You don't have to trade one for the other.

On whether the big ranges are really needed: for counts, you're right, 
53 bits is almost always enough. But the 64-bit cases that survive 
aren't about magnitude, they're about a device handing you an exact 
64-bit value, a register or a clock, where the question isn't "do we 
need the range" but "do we truncate data the hardware gave us." Even 
there truncation is often tolerable, so it's not the hill I'd die on. 
The point is just that trimming to three types removes the conversion 
pain without forcing any truncation at all.

So I'd reframe it as: the problem is type proliferation, not types. 
Fewer types fixes the hassle; zero types creates a different set of 
problems we then patch around. Three seems to be where the standards 
landed too.