Agree, you really have consult widely on that.
Have programmed for many years and some programming languages have quite
hard check if data types fit together and think this in general is a
good feature. Some programming languages allow defining sub types for
example restrict range and even define new types for example for current
measurement so that it is not accidentally mixed with other signal. To
define a datatype with restricted range so that it fit inside a signed
number may be useful for unsigned numbers then cast to a signed number
is known to always work without an error or exception.
In some cases a datatype is a subset of another datatype so this
datatype will always fit inside the other. Allow automatic typecasting
in this case might be an option?
A double as input will "swallow" most other numbers so might in this
case be a good idea for inputs.
Nicklas Karlsson
Den 2023-10-11 kl. 11:09, skrev andy pugh:
General chat at the Stuttgart meetup drifted onto the subject of HAL
pin types, and a suggestion that all pins could be of type "double"
and it would still work. This may actually what the STMBL does.)
A double can exactly represent signed integers up to 43 bits, so this
would actually be an improvement on the HAL version in 2.9
master currently has S64 and U64 types added, and a set of conversion
functions to suit. This means that there are a total of 7 HAL pin
types (bit, float, S32 U32, S64, U64, port) and 42(?) conversion
functions.
My proposal, based on further discussion in Stuttgart is to replace
_all_ integer types with Signed-64. This would very much simplify
many HAL configs which are currently liberally scattered with
conv_NN_NN components. The choice of S32 or U32 in many components
appears to be based purely on the whim of the original coder.
I anticipate this happening in a couple of steps, over a couple of
LInuxCNC major versions.
Step 1 is simply to map all the integer hal_pin_new*_*() functions
in HAL to hal_pin_new*_S64() and to replace the integer conv_NN_NN
functions with a simple pass-through.
I think that this would be entirely transparent and would not affect
the function of custom HAL components "out in the wild"
The task of converting the built-in HAL components could then proceed
piecemeal as the opportunity occurred. (for example increasing the
width that is processed in "bitwise")
The other integer types and conversion functions would, at this stage,
just be marked as deprecated.
There is the possibility of making the required HAL changes in the
update_ini script, though it might be non-trivial to get right (And
the changes _should_ be unnecessary)
Apart from a simplification of HAL, this also addresses
https://github.com/LinuxCNC/linuxcnc/issues/2331
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
