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

[Bertho S. <lc...@va...>]

On 6/8/26 6:29 PM, Robert Schöftner wrote:
> Multiple implementations of access to hal shared memory are to be
> avoided if possible, I would make some exceptions for C++ template code
> if it is warranted (e.g. by making python bindings easier via pybind).

Multiple implementations of access to HAL shared memory are to be avoided.

To say it in Highlander mode: There can be only one.

Making exceptions is why we are in the trouble we are in. Halmodule 
using pybind does not need any low-level access to shared memory. A C++ 
wrapper for other code doesn't need access to shared memory either. 
Everything can be mapped using the C API (which does need some 
adjustments from the current state, regardless).

We must keep the single API approach. That is the only way to guarantee 
that you can change the underlying stuff in HAL-lib without breaking 
code that uses the abstraction.


> I would probably keep some sort of "type", even if the underlying bits
> will eventually be double or whatever, just as a hint for the user and
> GUIs. Also the difference between parameter and pin should be kept as
> some sort of "metadata"

And that is exactly what is done today. No change of model needed. Just 
update/modernize the implementation.


> Another approach that would be possible in principle with accessors
> would be to do conversion between types in the setter/getter functions.

That is exactly the idea. If you change the underlying model, then the 
code does not need adjusting because the getter/setter code will capture 
and adapt to the changes so your API is a constant.


> The disadvantage would be that this could lead to surprising behaviour
> and you can't explicitely decide if you want to truncate, saturate,
> round or whatever to convert a value.

FWIW, the current code assumes truncation nearly everywhere. Otherwise 
it codes around the problem (or crashes if the programmer didn't care to 
take account for it).

Conversions are always a problem regardless which system you use. At 
least with the getter/setter approach you provide a uniform API for the 
programmer. All software (primarily interfacing hardware) is already 
confronted with the problem. There is no one-answer here and it always 
depends on what you are trying to achieve. Therefore, I cannot see any 
disadvantage. Surprising behaviour is caused by code that does not know 
its boundary conditions (i.e. programmer error). But remember, there is 
a clear distinction between how this is handled internally (components) 
verses externally (user interfacing).

-- 
Greetings Bertho

(disclaimers are disclaimed)