EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Fundamental Types document
From: Marty Kraimer <[email protected]>
To: [email protected]
Date: Thu, 16 Jun 2005 13:08:16 -0500


Jeff Hill wrote:

The current definition of epicsTypes does NOT include unsigned types. The reason is Java. If we allow unsigned types it makes it very difficult to complely support Java.

There is possibly another way of looking at this. With Java we must use an
integer type that has sufficient range to hold the magnitude of the integer
number used in C. This statement is true irregardless of whether the C type
is a signed or unsigned integer. Data Access will of course detect problems
where the integer magnitude in the server does not map to the range of the
data type of the client, and report them as exception call backs.

Two comments.

1) If native type is an unsigned 64 bit, then there is no wider java type
2) If each end is just using the unsigned as a bit mask (Note that Java provides for this) then throwing exceptions in the intermediate layers is no good.

We use
unsigned integer types because their domain fits better with the arithmetic
that is being conducted, and not because of their slightly higher positive
range. Relying on the extra range would be flying too close to the trees
IMHO. With bit fields if we have the option to address the bit field by its
offset and length then we will almost never need to perform arithmetic
directly on an unsigned 32 or 64 bit field. That’s a good thing. Otherwise
Java might find itself pickled when communicating with hardware ;-)


I am again haunted by Doug's request for "hello world".

If we provide some basic types ala db_access.h that are already interfaced
by data access then data access shouldn’t need to be seen by naïve users. No
doubt that we will layer a caGet and a caPut which will take "hello world"
as a parameter.

If data is acessed as an epicsType or some combination of epicsTypes, then hello world should be easy to implement. epicsTypes is a layer between code and dataAccess.

Marty



Replies:
RE: Fundamental Types document Jeff Hill
References:
RE: Fundamental Types document Jeff Hill

Navigate by Date:
Prev: RE: Fundamental Types document Jeff Hill
Next: RE: Fundamental Types document Jeff Hill
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: Fundamental Types document Jeff Hill
Next: RE: Fundamental Types document Jeff Hill
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·