2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 <2005> 2006 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: | Ralph Lange <[email protected]> |
To: | Marty Kraimer <[email protected]> |
Cc: | EPICS Core Talk <[email protected]> |
Date: | Fri, 17 Jun 2005 16:18:03 +0200 |
Marty Kraimer wrote:
The only place we see that V3 epics records need unsigned is for bit masks. However there is a big problem with the mask fields in the the mbbXXX records.The mask field is 32 bits. How do we handle a 64 bit I/O module? OK with V4 we can make the mask fields be 64 bits. But how do we handle a 128 digital I/O module? Also a 16 bit digital I/O module has many unused bits. A way to handle this is to make the mask fields an array of octets.The byte and bit order must still be decided but at least any multiple of 8 bits can be handled.
I see your line of argumentation and I do like the idea of handling all bitfield data as arrays of octets. I guess with that trick we can ship anything around that doesn't need to be used in calculations.
But what about real unsigned numbers? Like results of an ADC conversion that maps 0-10V to 0-65535 (not that uncommon)? Do we want to use 32bit integers in all these cases wasting ~50% of the bandwidth on CA? And wonder why writing a high number through a 32bit int to a 16bit DAC yields unpredictable results without the client getting an out-of-range exception? Transport it as an array of octets and reassembling it to an integer (unsigned or not) on both ends?
If Java was the only language that didn't use unsigned I would be less willing to adapt to it. But my impression is that the use of unsigned is coming from C/C++ and getting less popular in more recent languages. What will be fashionable in 5 years?
Ralph