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

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

This is along post. Please read it in its entirety.

Having only floating point pins is both an interesting question and at 
the same time completely irrelevant for the issue at hand.

If the issue was as simple as suggested, then we can change the pins to 
floating point today simply by redefining the hal_xxx_t types to use 
double as backing store and be done with it. It doesn't matter that 
user-space still uses multiple type indicators 
(HAL_[SU]{32,64}|HAL_FLOAT|HAL_BIT). The compiler will do all conversion 
for us from and to floating point and integer.

However, doing so will crash and burn. The question is: Why doesn't it work?

The answer is as obvious and simple as it is intricately complex. The 
"abstraction" in HAL is there in name only and not in the 
implementation. Code is accessing private HAL constructs and data with 
complete disregard of the - abstraction - that is promised by HAL. This 
is also known as a layer violation.

Any proper working HAL abstraction would entail that no program, 
library, component or other piece may access the shared memory directly 
and all access must go through HAL-lib, which is the narrowly defined 
interface published in hal.h.

Instead, multiple implementations exist in LinuxCNC to access shared 
memory and they all bypass the actual abstraction required. The 
user-space program halcmd and python interface library halmodule call 
directly into HAL's private API (hal_priv.h) and dereference internal 
structures. The pyhal interface (now retired) and the hal.hh constructs 
re-implement access to shared memory and bypass the published API entirely.
[A very clear indication that something is very wrong is the fact that 
the HAL mutex is used by code that is not part of the HAL library code.]

Based on this observation, it is impossible to make any significant 
changes to any part that touches HAL because the promised central 
authority, implied by an abstraction, is violated. Therefore, changing 
the user-visible types is impossible and doomed. You cannot change the 
type system, external or internal, when you cannot control access in any 
meaningful way.
That is why the discussion of using floating point everywhere is 
completely irrelevant. We first need to fix the code to _use_ the 
/abstraction/ and _only_ use the abstraction.

This is also where the discussion of issue #3286 becomes relevant and 
you are encouraged to go there and read it from start to end.

Eliminating the 32-bit types from HAL entails a complete overhaul of the 
internal structure. Code /assumes/ how things are laid out, uses direct 
access and cannot cope with moving all 32-bit types to 64-bit types. Why 
could anybody believe that we could change the current code base to use 
floating point exclusively when we can't even upgrade the 32-bit types? 
The reason, of course, are the layer violations by all the code and the 
assumptions it makes and uses to accomplish its task.

The getter/setter approach is solving /one/ of the problems we have in 
the layer violation. It eliminates direct access to the underlying 
shared memory and enforces _using_ the HAL API. It is the prelude to 
eliminating the distinction between 32/64 types. It is outlined in the 
described sequence of changes that need to be performed in order to do so.

Once you have a getter/setter interface, then you have decoupled the 
type seen by the component and the type available to the user. The 
getters and setters will do all translation for you on demand. But you 
first need to assure that *no one* bypasses the getter/setter API. 
Otherwise you will have the same mess we are in today. And that is also 
why talking about "make all floating point" is completely irrelevant at 
this time.

The next fix, after getter/setter, must be to eliminate other layer 
violations that are present in programs and code that access HAL private 
structures. These need to use the narrowly defined API in hal.h and that 
API needs some adaptions for it to become a true abstraction. There 
cannot be any access to any parts of HAL shared memory that bypass the 
official HAL API.

Talking about floating point everywhere is only relevant *after* the HAL 
abstraction is actually a fully functional abstraction. Changes would 
then just be adaptations of the HAL library and no other core changes 
would be required (and, of course, the presentation layer needs 
equivalent adaptions).


Note on why you need all those different getters and setters:
The code that uses the pin data, f.ex. a component, needs to have types 
that are appropriate for the component to work with, like hardware 
interfacing. The abstraction decouples the component's view from the 
underlying data/view with the getter/setter. The getters and setters 
perform all appropriate read, write and data/type translation for you as 
required for operation. User-space's view of pins and such may be 
completely different. That is why this is called an abstraction.


Note on the pin/param issue:
There is a genuine difference between what a pin represents and what a 
parameter represents. There is no need to eliminate parameters. 
Actually, the getter/setter changes require pins and parameters to 
become extremely close relatives and will ultimately share the exact 
same underlying structure out of necessity.
The issue mentioned, that you cannot find the one or the other is not an 
issue of pins and parameters, but an issue of presentation. Halshow does 
not need to show two trees because the names of pins and parameters 
/cannot/ overlap. The namespaces are only separated by 
attribute/function, not by name. Therefore, there is nothing that 
prevents you from showing one tree and have a uniform search.
Another issue is that halcmd's setp function addresses both pins and 
parameters, so a name collision between the two would hide one over the 
other. This too has (already) been fixed by first checking for collision 
while creating them. It will ultimately result in merging the pins and 
parameters internally. The only difference between the to will be the 
attributes. The user-space programs will be adapted accordingly to 
provide a consistent interface.

-- 
Greetings Bertho

(disclaimers are disclaimed)