Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Tue, 15 Nov 2005 14:31:44 -0700

> Jeff, should we make this more generic by adding a 
> CA_IMPURE_ENDIAN configuration macro?  

With integers there are of course simple ways to push/pull them on/off 
the wire w/o needing to configure the endian type at compile time. This 
includes even strange impure endian architectures. 

Unfortunately, with impure little endian architectures, double precision
floating point is harder. The ARM mods were well isolated within convert.c 
and net_convert.h. They missed also code in osiConvertToWireFormat.h
but it appears that this does not cause a failure because maybe all wire 
conversion of floating point currently occurs only in convert.c 
and net_convert.h. The intent was to eventually change convert.c 
and net_convert.h to use osiConvertToWireFormat.h so that all such
details are well isolated in libCom/osi/os/.

I had a very brief look at the ARM architecture. Perhaps I misunderstand, 
but it appears that at least modern arm can run as big endian,
little-endian, 
impure little endian, and in possibly other permutations. Basically whatever

you configure. In this case, configuration might mean a pull up/down
resistor
on a chip pin, or more-likely by specifying a parameter in a VHDL file.

Therefore, my initial conclusion was that _arm_ and _armv4l_ 
are probably both wrong. In the code we probably need something like 
the following.

_little_endian_float64_
_big_endian_float64_
_impure_little_endian_float64_
_impure_big_endian_float64_

This would of course be set on an arm architecture by configuration files, 
but I think that on most architectures in the code we might safely default 
_xxxxx_endian_float64_ to be what is done to byte swap a 64 bit
integer, and not require that the person porting to a new architecture
know about such arcane details. That's good considering that impure
endian double is probably on its way to extinction. 

> #153 - Jeff/Ralph - resolved?

Waiting for confirmation from Ralph

> #154 - Jeff - resolve as Not a Bug or Won't Fix?

Fixed it by improving documentation

> #207 - Jeff - mark as Feedback?

Did so, needs a stack trace (obtained on HPUX) to proceed.

> #208 - Jeff/Ralph - resolve as Won't Fix?

HPUX build issue - Ralph should decide

> #212 - Jeff - resolve as Won't Fix?

Marked as not-a-bug

> #223 - Why was this assigned to me?

There are other folks source code involved with this one (see the patch
Forwarded from Larry and saved under Mantis 223). Therefore, after
completing relevant changes in my stuff I feared that these additional 
issues would be neglected. Therefore, I reassigned to the release
captain for his future management of the issue.

Jeff

> -----Original Message-----
> From: Andrew Johnson [mailto:[email protected]] 
> Sent: Tuesday, November 15, 2005 12:18 PM
> To: EPICS core-talk
> Subject: R3.14.8 Status
> 
> 
> Ok folks, where are we with this release?  Marty has been 
> running some 
> of his tests, successfully so far, and is working on the rest.
> 
> It would be nice to get Banjamin's patch to the logClient library 
> included, which we're expecting tomorrow.
> 
> Peter Dennison from Diamond sent me a set of patches for 
> linux-arm which 
> included very similar changes to those that Peter Milne's patch (URL 
> sent to tech-talk on 11/8) supports, but with a different target 
> architecture name.  I'd prefer that we only have one linux-arm target 
> architecture if we can combine the two, possibly using the 
> same approach 
> we took for linux-x86 vs linux-386/486/586/686 targets as regards 
> optimization if that's necessary.  Neither set of configure files is 
> currently in CVS, and using  #ifdef _armv4l_  may not be the best 
> solution - Jeff, should we make this more generic by adding a 
> CA_IMPURE_ENDIAN configuration macro?  I'll ask the two Peters to try 
> and come up with a common set of configure files for 
> linux-arm if they 
> can for the R3.14.9 release.
> 
> I don't think we're ready for the 64-bit architectures yet, so they 
> should not hold up the release.
> 
> Ernest was reporting a segfault in epicsMessageQueueTestHost on 
> linux-x86 which Eric and he are looking into.
> 
> Are there any other outstanding issues that we should wait to 
> be fixed 
> before we release?
> 
> I'd like comments on the following Mantis bugs:
> 
> #153 - Jeff/Ralph - resolved?
> #154 - Jeff - resolve as Not a Bug or Won't Fix?
> #200 - Marty - is this fixed already?
> #204 - Marty - you may have just fixed this
> #207 - Jeff - mark as Feedback?
> #208 - Jeff/Ralph - resolve as Won't Fix?
> #212 - Jeff - resolve as Won't Fix?
> #223 - Why was this assigned to me?
> 
> Janet, do you have anything left to finish off for R3.14.8?
> 
> - Andrew
> -- 
> * * Matt Santos / / Leo McGarry * * For a Brighter America * *
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System