The unsigned integer question

[grandixximo]

@rene-dev about the signed and unsigned integer use, these are what I found.

• encoder.N.counts => joint.N.jog-counts (s32 to s32): every MPG pendant configuration. In-tree alone: woodpecker mpg.hal, touchy, shuttle, xhc-hb04, and pico pendant.hal (rawcounts via ilowpass, s32 throughout). Motion's jog protocol is an exact per-cycle count delta (control.c:1066).

• iocontrol.0.tool-prep-number: axis_manualtoolchange.hal is pulled in by 50 in-tree inis, and smithy/924.hal nets it into classicladder s32 word logic on shipped commercial machines.

• Unsigned: hm2_modbus (in 2.9) maps raw device registers to pins, including 64-bit unsigned compounds (hal_pin_u64_newf, plus a u64 .offset tare doing modulo-2^64 subtraction). A totalizer register above 2^53 loses bits on a float pin; the range [2^63, 2^64) reads negative on s64. The pin is the user-facing register image, so "keep it driver-internal" does not apply.

• Bit patterns: hm2 raw.write-data and bitwise (u32 pins), plus lut5 (stepconf generates setp lut5.0.function 0x10000, a u32 param). On an integer pin, NaN and 2.5 are unrepresentable; today setp <int-pin> nan is rejected while setp <float-pin> nan succeeds, and (int32_t)NaN is 0x80000000 straight into an FPGA register. No driver checks isnan; the type is the guard.

[BsAtHome]

With respect to Modbus, any system that uses 64-bit (flag) registers cannot be read using floating point or important information will be lost. It may currently be rare to find these systems, but it is not unheard of in implementations that use read/write-in-depth instead of classic modbus register addressing.

Do we distinguish between the sets ℕ and ℤ? Normally, ℕ is a subset of ℤ. But in computers that is not the case with distinct ranges. If we are to abandon unsigned (ℕ), then we should also remove all use of unsigned types in the rest of the code. Arguing that the distinction is immaterial in one case but not the other would be inconsistent IMO.

[rene-dev]

hal and code are 2 different things. It is called hardware abstraction layer, not hardware access layer. I dont understand where the idea comes from that having hardware registers exposed as hal pins is useful for anything. It is the drivers job to abstract the hardware. in the case with encoders, it scales it to machine units, so it becomes useful. for a vfd, it converts rpm to whatever the vfd needs. linuxcnc does not even have a setting for scaling anything, it is always scaled in the driver.
anyone who has ever worked with machines using ethercat or modbus knows this.
Same applies for flag register. its the drivers job to extract the flags, and display them in a useful way.
52 bits is a lot more than the 32 we had for years.
a good example is this:
https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/components/eoffset_per_angle.comp#L9-L14
so they are making up a scale, and using the pin as a fixed point integer. This is mental.
in fact, I discovered that all of plasmac calculates height in fixed point integer, just because this pin is an integer. WHY.
this is another example:
https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/components/ilowpass.comp#L10-L14
because lowpassing an integer lacks resolution, you have to come up with a scale, and then convert back to float.
if those are gone, and they are both better of as a float, there are not many integer pins left, and my original question still remains unanswered:
is there any use for any integer pin in linuxcnc, that cant be a float?
if yes, can this pin be a signed integer, so we only have 2 types?

so far, lut5 is the only answer that came up.

I am talking about HAL, not about the code. Of course integer types are needed in the code.

[BsAtHome]

hal and code are 2 different things. It is called hardware abstraction layer, not hardware access layer. I dont understand where the idea comes from that having hardware registers exposed as hal pins is useful for anything.

Well, that is nice in theory, but unworkable in practice.

For example, the hostmot2 interfaces are interconnecting through HAL layering, where the "driver" as you call it is split between the protocol interface and the logic interface. For hm2_modbus this means you have a simple choice: reimplement the hardware/protocol interface provided by hm2_modbus for every Modbus device driver with all the problems that entails, or, interface your VFD (or other device) it at a higher level and let it connect to an abstracted protocol layer.

[rene-dev]

as far as I know pktuart, and hm2 are talking to each other using function calls, not hal pins, is that not the case?

[BsAtHome]

as far as I know pktuart, and hm2 are talking to each other using function calls, not hal pins, is that not the case?

This is not about pktuart, which is the transport layer (Layer 2; with hardware serial signalling at Layer 1). The protocol layer is modbus (Layer 3). The interconnect via HAL goes to the actual "device" drivers, which operate at Layers 4...7.

[grandixximo]

as far as I know pktuart, and hm2 are talking to each other using function calls, not hal pins, is that not the case?

hm2_modbus.c:2983-3025 creates one HAL pin per modbus data item from the compiled mbcc: bool, ui32, uint (u64), si32, sint (s64), real. The u64 flag-register case sits at line 3006 (hal_pin_new_uint).

So the Layer 3 to Layer 4+ interconnect Bertho describes is HAL pins by construction, and the device semantics live in the user's mbcc file, not in the driver. That is why hm2_modbus cannot scale or decompose registers itself: it is the protocol layer, and the meaning is defined downstream.

[grandixximo]

Conceding the two examples first: ilowpass and eoffset_per_angle are indeed scale-hack artifacts and would be better as float. I am not defending integer pins where a physical quantity is involved. If the list of integer pins were only those two, I would agree with you.

But the original question, "is there any integer pin that can't be a float", still has concrete cases on the table, so let me ask about those directly.

1. hm2_modbus exposes holding registers as pins, including u64 compounds. The component is a protocol bridge; it has no knowledge of the device on the other end, so there is no scaling it can apply. Bertho's point stands here: the alternative is every VFD driver reimplementing the modbus interface itself. What should a u64 register in the range [2^63, 2^64) read as on a float pin? On a signed pin it reads negative. Is either acceptable for a register image?

2. lut5.0.function is a bit pattern; stepconf generates setp lut5.0.function 0x10000. If this pin becomes float, what should setp lut5.0.function 2.5 do, and what should setp lut5.0.function nan do? Today the type rejects both. If the type no longer rejects them, which component checks isnan before the value lands in an FPGA register?

3. Same question for hm2 raw.write-data, a u32 bit pattern written verbatim to hardware. What does scaling mean for a bitmask?

4. iocontrol tool-prep-number feeds classicladder s32 word logic in smithy/924.hal on shipped commercial machines, and axis_manualtoolchange.hal is pulled in by 50 in-tree inis. If this becomes float, who re-verifies those configurations, and what is gained that justifies that?

5. On the consistency question Bertho raised and I haven't seen answered: if the ℕ/ℤ distinction is immaterial at the pin level, why is it material in the code? A u32 register image and a u32 C variable describe the same hardware fact. What changes at the HAL boundary?

My actual position is narrower than "keep everything": physical quantities should be float, counts and register images should stay integer, and bit patterns should stay unsigned. That gives us float + signed + unsigned, which is what we have. The two-type proposal (float + s64) answers cases 1 through 3 with either lost information or silent truncation, so I am asking: what does it buy that justifies that?