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: Int64 PV and caget |
From: | "Williams Jr., Ernest L. via Core-talk" <[email protected]> |
To: | "Kim, Kukhee" <[email protected]>, "Michael A. Davidsaver" <[email protected]>, "Hill, Bruce" <[email protected]> |
Cc: | "Slepicka, Hugo Henrique" <[email protected]>, "[email protected]" <[email protected]> |
Date: | Sat, 12 Jan 2019 04:14:36 +0000 |
Hi Kukhee,
I wanted to just loop in the core-talk list.
Indeed, I am looking forward to 64-bit support as we can take advantage of it for LCLS II timing system.
Cheers, Ernest From: Kim, Kukhee
Sent: Friday, January 11, 2019 1:42 PM To: Michael A. Davidsaver; Hill, Bruce Cc: Williams Jr., Ernest L.; Slepicka, Hugo Henrique Subject: RE: Int64 PV and caget Hi Michael,
Thank you so much for your explanation. I am thinking slightly different point of ivew. I think, we are better to allow the followings: (1) record(int64in, "test:ai64") { field(VAL, "0xffffffffffffffff") } Because, 0xffffffffffffffff means "-1" in 64bit signed integer. The "-1" is still inside of range and we can accept it to put into the int64 variable. But, we could not allow the followings: (2) record(long, "test:ai32") { field(VAL, "0xffffffffffffffff") } Because, the hex number includes information for bit 0 to bit 63 But there are not bit 63, bit 62, .... , and bit 32 in 32 bit integer. Thus, we are better to allow hex number if its number of bits can fit inside data type. Please, let me know your opinion. Best regards, Kukhee Kukhee Kim | Engineering Physicist Advanced Controls Department SLAC National Accelerator Laboratory | Menlo Park, CA p: 650.926.4912 | m: 669.300.8192 | email: [email protected] -----Original Message----- From: Michael Davidsaver <[email protected]> Sent: Friday, January 11, 2019 8:23 AM To: Kim, Kukhee <[email protected]>; Hill, Bruce <[email protected]> Cc: Williams Jr., Ernest L. <[email protected]>; Slepicka, Hugo Henrique <[email protected]> Subject: Re: Int64 PV and caget On 1/10/19 4:39 PM, Kim, Kukhee wrote: > Hi Bruce, > > > > Thank you for your discussion. > > 1. Yes, I agree VAL+1 issue came from the losing precession during type conversion to double. > > 2. “-0x8000000000000000” works. It looks like a parsing issue. Assignment of out of range field values is now generally not allowed. An exception is made for the common legacy case of assigning DBF_LONG from a value which is valid DBF_ULONG and vis. versa. eg. > record(longin, ....) { > field(VAL, "0xffffffff") > } strictly speaking is out of range for DBF_LONG, but is allowed as it has been found in the wild (I know I've done this). This is a legacy behavior for the existing 8, 16, and 32-bit integer fields. It doesn't extend to the new 64-bit field types, which must be assigned strictly in range. cf. dbPutStringNum() which is called through dbPutString(). https://github.com/epics-base/epics-base/blob/0ae50485cf3d46185501e18592921c74c8312e6e/modules/database/src/ioc/dbStatic/dbStaticRun.c#L383-L499
|