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: "Jeff Hill" <[email protected]>
To: "'Marty Kraimer'" <[email protected]>, <[email protected]>
Date: Thu, 16 Jun 2005 13:45:57 -0600

> -----Original Message-----
> From: Marty Kraimer [mailto:[email protected]]
> > 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

My point was that even if an unsigned 64 bit integer is used in the server
it's very rare that we will have a need for the magnitude of the number
stored therein to use the portion of the range that can't be expressed in a
64 built signed integer. We should use unsigned numbers because of their non
negative domain, and not because of their increased range. Since we have
good detection at runtime for rare situations where there is an out of range
violation, and this detection is based on the numbers magnitude, and not
just the source and destination data types, then I think that this is a
reasonable compromise.

> 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.

My point was that if the bit fields are addressable by starting bit and bit
width it will be very rare that we need a full 64 bit width bit field.

Note that in robust programs exceptions are caught. If an exception occurs
in the server it is always caught and an exception message is sent to the
client. That results in a IO completion failure callback to the user.

Jeff




References:
Re: Fundamental Types document Marty Kraimer

Navigate by Date:
Prev: Re: Fundamental Types document Marty Kraimer
Next: Re: Fundamental Types / Gateway Ralph Lange
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 Marty Kraimer
Next: Re: Fundamental Types document Ralph Lange
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 ·