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)
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
