Re: floating point problem in CA?

[Maren Purves <m.purves@jach.hawaii.edu>]

Hi Heinrich (and Rok),

I remember seeing this on one architecture (don't remember what it
was, it was about 8-10 years ago), only for doule precision types
(ai is/was double), and we got around it by converting to strings.
CA is very good about the conversion, so this never turned into
a problem (the application may still be running like that, I
don't remember what it was and whether we still have the device)

HTH,
Maren

On Fri, 29 Feb 2008, Rok ?abjan wrote:

> Hi Heinrich,
>
> I remember this problem as we had it in 2004. I remember that we were not 
> able to solve it, but it did not occur if we used a command-line client that 
> wrapped the CDEV library. At that time I did not care about that, but it may 
> help if you want to track down the problem.
>
> Regards,
> Rok
>
>
> On 28.2.2008, at 23:51, Heinrich du Toit wrote:
>
> > Hi
> >
> > This is weird and I'm not really sure how to track it down.
> >
> > I have an embedded ARM board. I've compiled EPICS onto that.
> >
> > I run vlinac (just to get something ) on my host PC (x86)
> >
> > Then I take an ai variable. (in other words a floating point thing)
> >
> > If I say from the ARM board caput  pvname value
> > Then the correct value gets into the pv on my host pc.
> > But.. the wrong value gets back via channel access.
> > if I caget the value I get the wrong answer.
> >
> > It seems that the network byte order is done wrongly maybe.. I'm not sure.
> > If I put 1.0
> > and then get again I get: 5.29981e-315
> >
> > Which is almost like the wrong network byte order but not exactly it seems.
> > It could be that somewhere along the lines something thinks double is 6 
> > bytes only (rather than 8) and then also swaps the byte order.
> >
> > Maybe there is an htons or something missing somewhere in the code?
> > But how this is possible baffles me. :/
> >
> > I've written a small program to test the structure and layout off "double" 
> From tech-talk-bounces@aps.anl.gov Thu Feb 28 16:38:18 2008
Received: from epics.aps.anl.gov (zora.aps.anl.gov [164.54.10.60])
	by o2.aps.anl.gov (8.13.8+Sun/8.12.9) with ESMTP id m1SMcI0A002994
	for <tech-talk.archive@oxygen.aps.anl.gov>; Thu, 28 Feb 2008 16:38:18 -0600 (CST)
Received: from zora.aps.anl.gov (localhost [127.0.0.1])
	by epics.aps.anl.gov (8.13.8+Sun/8.12.9) with ESMTP id m1SMZNDR029862;
	Thu, 28 Feb 2008 16:35:24 -0600 (CST)
Received: from herald.aps.anl.gov (herald.aps.anl.gov [164.54.50.61])
	by epics.aps.anl.gov (8.13.8+Sun/8.12.9) with ESMTP id m1SH2fot005792
	for <tech-talk@mailman.aps.anl.gov>;
	Thu, 28 Feb 2008 11:02:41 -0600 (CST)
Received: from aps.anl.gov (hestia.aps.anl.gov [164.54.98.20])
	by herald.aps.anl.gov (8.13.7/8.13.7) with ESMTP id m1SH1thE009602
	for <tech-talk@aps.anl.gov>; Thu, 28 Feb 2008 11:01:55 -0600 (CST)
Received: from ([128.171.90.17])
	by hestia.aps.anl.gov with ESMTP  id 4440338.11519070;
	Thu, 28 Feb 2008 11:02:21 -0600
Date: Thu, 28 Feb 2008 07:02:20 -1000 (HST)
From: Maren Purves <m.purves@jach.hawaii.edu>
To: =?ISO-8859-15?Q?Rok_=A6abjan?= <rok.sabjan@cosylab.com>
Subject: Re: floating point problem in CA?
In-Reply-To: <FF7453F8-E147-41A9-927D-9ABC7849967D@cosylab.com>
Message-ID: <alpine.LRH.1.00.0802280658240.1201@vb>
References: <47C6D883.8030003@tlabs.ac.za>
	<FF7453F8-E147-41A9-927D-9ABC7849967D@cosylab.com>
User-Agent: Alpine 1.00 (LRH 882 2007-12-20)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-esp: ESP<6>= RDNS:<0> SHA:<0> UHA:<6> BAYES:<0> SenderID:<0> DKIM:<0> 
	TS:<0> 
	SIG:<dNmpVi11AUGe0lxhHlWDZv-FksLSZQs__PGVYstSI8WyxSoPMWqzsu9TrqkT
	ghNobx-BiEfpwGHoyZb3obys6uzanfB6gyHVlyP1DHJ55fQUpUV-hJ23qte4
	Px84pBzq0zxVxH5mrMYr_JlIhjFRb7O772c3XgB2CkJ3Ku0uKjygz97xVGbQ
	AbJ12qp8X9PNEAm0i8NkrzCTkAsBtHpRewKSkbOOFOwVDlcNA> DSC:<0> 
	TRU_marketing_spam: <0> TRU_money_spam: <0> TRU_cn_political: <0>
	TRU_cn_entertainment_spam: <0> TRU_cn_business_spam: <0>
	TRU_scam_spam: <0> TRU_cn_profanity_spam: <0> TRU_adult_spam: <0>
	TRU_stock_spam: <0> TRU_phish_spam: <0> TRU_jp_misc_spam: <0>
	TRU_watch_spam: <0> TRU_cn_misc_spam: <0> TRU_profanity_spam: <0>
	TRU_jp_adult_spam: <0> TRU_medical_spam: <0> TRU_cn_class_ad: <0>
	TRU_html_image_spam: <0> TRU_legal_spam: <0>
	TRU_embedded_image_spam: <0> TRU_misc_spam: <0> TRU_lotto_spam: <0>
	TRU_cn_scam_spam: <0> URL Real-Time Signatures: <0>
X-Spam-Status: No, score=-500.0 required=500.0 tests=FROM_HESTIA,
	UNPARSEABLE_RELAY autolearn=unavailable version=3.1.3
X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on herald.aps.anl.gov
Cc: EPICS Techtalk <tech-talk@aps.anl.gov>
X-BeenThere: tech-talk@aps.anl.gov
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: EPICS Mailing List <tech-talk.aps.anl.gov>
List-Unsubscribe: <http://www.aps.anl.gov/mailman/listinfo/tech-talk>,
	<mailto:tech-talk-request@aps.anl.gov?subject=unsubscribe>
List-Post: <mailto:tech-talk@aps.anl.gov>
List-Help: <mailto:tech-talk-request@aps.anl.gov?subject=help>
List-Subscribe: <http://www.aps.anl.gov/mailman/listinfo/tech-talk>,
	<mailto:tech-talk-request@aps.anl.gov?subject=subscribe>
Sender: tech-talk-bounces@aps.anl.gov
Errors-To: tech-talk-bounces@aps.anl.gov

Hi Heinrich (and Rok),

I remember seeing this on one architecture (don't remember what it
was, it was about 8-10 years ago), only for doule precision types
(ai is/was double), and we got around it by converting to strings.
CA is very good about the conversion, so this never turned into
a problem (the application may still be running like that, I
don't remember what it was and whether we still have the device)

HTH,
Maren

On Fri, 29 Feb 2008, Rok ?abjan wrote:

> Hi Heinrich,
>
> I remember this problem as we had it in 2004. I remember that we were not 
> able to solve it, but it did not occur if we used a command-line client that 
> wrapped the CDEV library. At that time I did not care about that, but it may 
> help if you want to track down the problem.
>
> Regards,
> Rok
>
>
> On 28.2.2008, at 23:51, Heinrich du Toit wrote:
>
> > Hi
> >
> > This is weird and I'm not really sure how to track it down.
> >
> > I have an embedded ARM board. I've compiled EPICS onto that.
> >
> > I run vlinac (just to get something ) on my host PC (x86)
> >
> > Then I take an ai variable. (in other words a floating point thing)
> >
> > If I say from the ARM board caput  pvname value
> > Then the correct value gets into the pv on my host pc.
> > But.. the wrong value gets back via channel access.
> > if I caget the value I get the wrong answer.
> >
> > It seems that the network byte order is done wrongly maybe.. I'm not sure.
> > If I put 1.0
> > and then get again I get: 5.29981e-315
> >
> > Which is almost like the wrong network byte order but not exactly it seems.
> > It could be that somewhere along the lines something thinks double is 6 
> > bytes only (rather than 8) and then also swaps the byte order.
> >
> > Maybe there is an htons or something missing somewhere in the code?
> > But how this is possible baffles me. :/
> >
> > I've written a small program to test the structure and layout off "double" 
> > on both my PC and the ARM. it seems identical to me.
> >
> > If anybody has any idea how I can "check" this or try and find the problem 
> > it would be help full.
> > I am aware that the problem is not necessarily in epics but could be in the 
> > compiler options or something like that.
> >
> >
> > thanks
> > -Heinrich
>
> on both my PC and the ARM. it seems identical to me.
> > If anybody has any idea how I can "check" this or try and find the problem 
> > it would be help full.
> > I am aware that the problem is not necessarily in epics but could be in the 
> > compiler options or something like that.
> >
> >
> > thanks
> > -Heinrich