Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Mon, 8 Aug 2005 16:41:43 -0600

> If we do support a limited range of types and 32 bit floats are what is
> supported - when 64 bit ones arrive, isn't it a simple matter to add them?

Initially there may not be that much need for additional numeric range.
Address space will be the initial driving issue for 64 bit architectures.

Nevertheless, recall that we wrote the embryonic versions of EPICS not that
long after the switch from 16 bit systems to 32 bit systems. We originally
used float32 for the VAL related fields in IOC core, but that users made the
argument that certain instruments directly produce float64, and even require
float64. Why worry about saving space. That was a pretty good argument so we
changed to float64. Nevertheless, many clients today would still work
reasonably well for most signals with type float32. That would, for example,
be a tenable solution for clients running on architectures that do not
support a 64 bit double if there was some way to inform the client during
its callback of a range error so that it could take the appropriate action.
Still, we would never suggest today that the servers should use type float32
for all VAL fields.

Eventually there *will* be instrument xxx (perhaps an astronomy instrument
or software component) that wants to source the EPICS server with an
engineering units value expressed as an 128 bit floating point number. They
will make the argument that certain instruments produce float128, and even
require float128. Why doesn't a physics control system support this? And our
answer will be that DA does support this, but can allow a 32 bit client to
continue to function in a sane degraded mode because proper range checking
is done and because error conditions are reported through standard
interfaces to the user. This will allow a reasonable transition until 64 bit
systems are ubiquitous. It is important to not force legacy systems to
upgrade all at once to 64 bits just because EPICS supports 64 bit data
sources, or there are a few isolated 64 bit data sources.

IMHO the issue isn't whether we can restrict types or not - we can always do
that if we choose to, it's what we will do when we have a heterogeneous
system of 32 and 64 bit systems. That will eventually occur, and with DA we
can still function in a degraded mode, and report range error safely, when
the server architecture size is bigger than the client architecture size. We
make a smooth transition between 32 and 64 bit arcjitectures.

Jeff

PS: BTW, personally I do think that saving space is important and it would
be nice to allow definition of records of variable precision (C++ templates
would be nice for that). Note that if the VAL field changes precisions then
many other fields could change also.

> -----Original Message-----
> From: Dalesio, Leo `Bob` [mailto:[email protected]]
> Sent: Monday, August 08, 2005 3:38 PM
> To: Jeff Hill; Bob Dalesio; [email protected]
> Subject: RE: Channel Access Client Interface
> 
> If we do support a limited range of types and 32 bit floats are what is
> supported - when 64 bit ones arrive, isn't it a simple matter to add them?
> Bob
> 
> -----Original Message-----
> From: Jeff Hill [mailto:[email protected]]
> Sent: Monday, August 08, 2005 1:50 PM
> To: 'Bob Dalesio'; [email protected]
> Subject: RE: Channel Access Client Interface
> 
> 
> Hi Bob,
> 
> > ADO handles all conversions
> 
> First, ADO is probably a misleading label (presuming this stands for
> abstract data object). IMHO a better name (thanks Ralph) for the
> functionality is DA (Data Access) - better labeling it is an interface -
> an accessor interface. There *is* an associated library of conversion and
> indexing functions. There *isn't* an implantation of storage - an object.
> GDD was an ADO. DA isn't.
> 
> Concerning DA's interface with the user:
> ----------------------------------------
> 
> 1) DA will tell the user what the server's native type is {boolean,
> signedInteger, unsignedInteger, enumerated, real, time, string, array,
> container}, and what the native type size is in bytes.
> 
> 2) DA will allow the client side user to select the largest practical size
> of a particular type, and tell the user if a range error occurs when
> converting the server's type to the type of the client side user. I
> believe that this is the model employed by many clients today (except that
> there is no range checking).
> 
> 3) DA will allow the user to select a size locked type, and tell the user
> if a range error occurs when converting the server's type to the type of
> the client side user.
> 
> 4) DA will allow the user to select the exact same type used by the server
> or else the largest available size of that same type, and tell the user if
> a range error occurs when converting the server's type to the type of the
> client side user.
> 
> This appears, at the interface level (presumably that is what we are
> designing here), to allow both camp's positions with the only exception
> possibly being that the above *does* allow for 64 bit types to be
> gradually introduced.
> 
> The other camp appears to be advocating that 64 bit types are dangerous,
> and should not be allowed. I can predict that initially no one will
> consider 64 bits servers to be important, then there will be a transition
> period where there will be a mixture of both (64 bit servers are essential
> in certain select situations and 64 bit workstations are ubiquitous), and
> finally we will see a period where 32 bit servers are rare in the
> mainstream but possibly common in embedded systems.
> 
> > In the first place - the ADO is big and handles a lot. In the second
> place,
> > it is small and does not support everything.
> 
> The biggest job of DA is to map between heterogeneous containers of
> properties whose content is indexed by traverse and find at compile time,
> but otherwise not known at compile time. I presume that both camps agree
> that this is a requirement for implementation of the server's event queue.
> The portable server uses GDD for this purpose at this time. See previous
> papers concerning the lack of popularity of GDD with users when using it
> implement a service.
> 
> Furthermore, DA must have a conversion matrix, but this is already
> necessary in the existing system. DA's conversion matrix is better because
> it range checks before converting.
> 
> > Our clients will be about 70% JAVA, and 30% C. How much work is
> > required to get the functionality in the first option into all of these
> platforms?
> > How much is it in the second options?
> 
> Yes, for funded future clients this Java predominated ratio might prove to
> be accurate, but for IOC's C/C++ is essential and we will not have a
> system if the C/C++ code isn't running - unless of course we were to code
> IOC core in Java.
> 
> IMHO there is no "voodoo C++ templates" in DA which can't be implemented
> in other languages. The most important issue is making certain that the
> interface is correct. Since a functionally equivalent interface can be
> expressed in the different source languages then I don't see a problem.
> Sites w/o unlimited money will probably just choose to wrap the C/C++
> implementation with the target languages interface - the predominating
> approach in the past. Perhaps a Java JNI version (a C/C++ implementation
> wrapper) can bridge the gap until a native version is produced? We *will*
> of course provide backwards compatibility for existing Java CA client
> interfaces. That is how we have solved such problems in the past. It may
> be difficult to get the next generation clients funded if they don't
> initially use backwards compatible interfaces.
> 
> The template approach to code development makes the library source code
> smaller however there are many other reasonable approaches including code
> that generates source code as was done with the implementation of GDD and
> its predecessor. Given that Java now has templates I assume that we can
> start there.
> 
> > Where is the example codes that implement the various client functions
> > with the proposed libraries?
> 
> Needless to say, I can't give you an implementation at this time. I did
> present an example client code at the last meeting?
> 
> > Where is the protocol that was going to be placed on the wiki?
> 
> I do have such a document in rough form, but I am still working on it. I
> did try to present this at the last meeting, but it was eliminated form
> the agenda. I will put this up on the wiki ASAP.
> 
> Jeff
> 
> > -----Original Message-----
> > From: Bob Dalesio [mailto:[email protected]]
> > Sent: Monday, August 08, 2005 1:02 PM
> > To: [email protected]
> > Subject: Channel Access Client Interface
> >
> > My understanding is that we are stuck at this place:
> >
> > One position:
> >     We support all data types native to the machine on which the
> > client is run. The ADO handles all conversions, gives native type for
> > each channel connected, gives sizeof infromation for allocating
> > storage, and returns the value in that type of variable - where the
> > space is provided by the user.
> >
> > The other position:
> >     We support a limited number of types that support all of the data
> > that we need to support. The server puts the data into one of these
> > limited
> set.
> > Otherwise, it is the same as above.
> >
> > The difference in the two, is that the ADO handles many different
> > types in the first position and in the second position the server has
> > to put data into one of the limited set and the ADO only handles the
> limited set.
> >
> > Is this right?
> >
> >
> > In the first place - the ADO is big and handles a lot. In the second
> place,
> > it is small and does not support everything.
> >
> >
> >
> > Our clients will be about 70% JAVA, and 30% C. How much work is
> > required to get the functionality in the first option into all of
> > these platforms? How much is it in the second options?
> >
> > Where is the example codes that implement the various client functions
> > with the proposed libraries?
> > Where is the protocol that was going to be placed on the wiki?
> >
> > Thanks,
> > Bob

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System