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  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: Re: EPICS base V4: iocCore database
From: Benjamin Franksen <benjamin.franksen@bessy.de>
To: Jeff Hill <johill@lanl.gov>
Cc: 'Marty Kraimer' <mrk@aps.anl.gov>, 'Andrew Johnson' <anj@aps.anl.gov>, 'Bob Dalesio' <ldalesio@lanl.gov>, 'Ralph Lange' <Ralph.Lange@mail.bessy.de>, 'Eric Norum' <norume@aps.anl.gov>, 'Ken Evans' <evans@aps.anl.gov>, 'Ned Arnold' <nda@aps.anl.gov>, 'Matej Sekoranja' <matej.sekoranja@ijs.si>
Date: Wed, 23 Feb 2005 13:15:11 +0100
Some comments regarding the signed/unsigned conversion issue:

On Wednesday 23 February 2005 04:29, Jeff Hill wrote:
> > From: Marty Kraimer [mailto:mrk@aps.anl.gov]
> > >Jeff Hill wrote:
> > >o Data access supports safe conversion between all of the
> > >primitive types available in C. If the source is out of range
> >
> > for
> >
> > >the destination the operation is not performed and an error is
> > >returned to the user. This has already been implemented.
> >
> > Is this what we want?
> > Let me give an example
> >
> > An IOC has a field that is an unsigned 32 bit integer.
> > A java application asks for the fields as a signed 32 bit
> > integer. The java application only uses the field as a
> > bit mask.
> >
> > Should CA return an error if the value happens to have the high
> > order
> > bit = 1?
> > I say no.
>
> I say yes. No doubts from my perspective. How would the IOC know
> what the client is using the data for? This isn't close enough is
> good enough environment. We are coding a control system. We don't
> want intermittent failures that occur only when the data has
> certain magnitudes.
>
> If the bit field is an unsigned number and higher order bits are
> set then this would be a very high magnitude unsigned number. If
> this exceeds the magnitude of the signed type in the Java client,
> and if there is even the slightest possibility that any Java
> client might use the result as a signed number, and not as a bit
> field, then a disaster will eventually occur. A code that is
> sourcing out bit fields should be providing a way to specify the
> starting bit and the field length so that bit fields anywhere
> within a 32 bit unsigned number can be accessed, and the Java
> client upon encountering conversion problems could request the 32
> bit field as two 16 bit fields with complete safety and no loss
> of functionality.

Yes. Marty, in your proposal there is a data type to request in this 
case: an array[4] of octets. Octet is explicitly specified to be used 
in cases where the raw bit pattern is what is wanted, as opposed to an 
integral /number/.

A predictable (immediate) exception is definitely better than eventual 
failure when values go out of range.

Regarding the current use of unsigned types, there are three cases to 
consider:

(a) A raw value that gets written to or read from hardware and that is 
specified by the manufacturer to be an unsigned number.

(b) Any other integral number, that has a natural lower bound of zero.

(c) A bit field or enumeration.

I think the only real justification for using unsigned integral types is 
case (a).

In almost all cases of (b), we can use a signed type (if strictly 
necessary take the next larger variant), without losing anything 
important.

As regards case (c), for enumerations we can and should create a menu of 
choices. Bit fields should have either a dedicated basic type (bitfield 
with a configurable number of elements) or else be just an array of 
booleans, that gets automatically optimized into a bitfield.

The bottom line is that unsigned types should be used only in the very 
few cases where they are essential to faithfully represent raw hardware 
values.

Ben


Replies:
RE: EPICS base V4: iocCore database Jeff Hill
References:
RE: EPICS base V4: iocCore database Jeff Hill

Navigate by Date:
Prev: RE: EPICS base V4: iocCore database Jeff Hill
Next: Re: EPICS base V4: iocCore database Marty Kraimer
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: RE: EPICS base V4: iocCore database Jeff Hill
Next: RE: EPICS base V4: iocCore database Jeff Hill
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
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 ·