EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  <19951996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  <19951996  1997  1998  1999  2000  2001  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: Observations on EPICS Alpha port & DEC support of VxWorks
From: Tony Cox - (415)926-3105 <[email protected]>
Date: Thu, 09 Feb 1995 11:34:57 PST
As I reported in the Tucson meeting, the EPICS port to the Alpha OSF-1 
platform is coming along, if rather slowly. I have successfully built
the IOC code under DEC VxWorks, loaded the mvme-167, and loaded databases.

The port of the host components to OSF is bringing up some systemic problems
with the design of the EPICS software. I'm mentioning this now since it
occurs to me that people involved in `work in progress' should at least be
aware of these problems so that their finished products port simply to
other architectures. I hope to have `fixed up' the existing products as part
of my porting efforts, and will make these available as fast as I can.

The problems with the Alpha/OSF port are twofold. One is the question of
endianness (Alphas are little-endian, existing support is for big-endian
machines). The second is the 64-bit architecture. The former has ramifications
for other porting efforts (VAXes are little endian too); the latter is
basically a problem which we will have to solve generically over the coming
years as other manufacturers get into the 64 bit age.


The endianness problem itself has a number of components.

First, when considering programs which run exclusively in the context of a
little-endian host, one has to pay particular attention to inherent assumptions
which big-endian developers make on the layout of bytes within data structures.
I'm finding various manifestations of this as I go along. One example is in
DCT, where record field names are looked up through the sortFldName structure.
'sortFldName' is an array consisting of 4-byte integers which contain ascii
bytes which name the fields. Little-endian systems store the bytes in reverse
order, so the binary tree searches do not work without some fiddling (the
integer representation of "STAT" is < "SVAL" on a BE system; the reverse is 
true on a LE system). No doubt I'll find other instances of this....

Second, and potentially more worrisome, is when considering programs running
on little-endian hosts which generate binary datafiles which are to be
downline loaded onto big-endian IOC's (and of course, BE hosts and LE IOC's).
Here, the problems are that the fields as written by the host do not make sense
in the IOC's (except for some special cases, like `0'). I'm fixing this problem
temporarily through a stand-alone conversion program which will do the byte
swapping after the fact, but this is clearly not the way to go long term (Marty
says that the exclusive ascii database loading protocols are still several
months away).

Finally, there is the question of channel access, which we have thrashed out
before. Final generic support for LE-BE and BE-LE systems will not be
implemented until R4 (correct me Jeff if I'm wrong here). In the interim, CA
runs on other LE systems (eg VAXes), so I'm not expecting too much trouble
here.


Now for the problems with 64-bit architecture, which will require some
considerable recoding and some careful thought.

The implicit assumption within all data structures and much of the code of
EPICS is that short=2, int=4, long=4 and void*=4. On Alpha/OSF systems,
short=2, int=4, long=8 and void*=8. ANSII C (and the C++ ARM), BTW, merely 
specify that sizeof(short) <= sizeof(int) <= sizeof(long). Further, there is no
guarantee that a void* can be stored even in a long, although I havn't seen 
such a machine (yet). Note especially that as we proceed to develop C++ epics
code, some implementation dependencies in pointer <-> integer conversion might
creep in, since void*'s are required to be able to contain arbitrary object
pointers (and these pointers might include some context other than simply
object addresses in high-performance implementations). Unlike ANSII C,
statements like "char* cp = vp" are illegal without casts in C++; such casts
may not perform similarly on all architectures.


EPICS code (especially database access routines) make fast-and-loose with the
pointer/integer conversions, using fields as offsets when databases are written
out to disk, expanding them to actual structure addresses when in memory.
Another good reason to do away with binary database altogether.

I propose that we change all field references within EPICS data structures to
explicitly sized elements, so that (for example) :-

	struct recTypDes {
		..
		short 	no_links;
		short	*link_ind:
		unsigned long *sortFldName:
		...
	};

becomes

	struct recTypDes {
		..
		EPICS_16BIT	no_links;
		EPICS_16BIT	*link_ind;
		EPICS_U32BIT	*sortFldName:
	};

and a generic include file produces the appropriate typedefs for each
architecture. This file should also have endian-ness byte swapping macros
defined, similar to 'htons'. (I hesitate to suggest merely taking advantage
of the internet header files to accomplish this, since at some point we may
have implementations of EPICS channel access which are divorced from TCP/IP).



Finally, I have been clarifying DEC's position re: VxWorks. The latest word is
that DEC and WRS have concluded a deal where BOTH get to sell VxWorks Alpha/OSF
support. I presume that WRS will sell the Alpha support under there current
terms and conditions. I have a call in to the fellow who negotiated this deal
to find out if DEC's terms and conditions have changed (as you know, my DEC
VxWorks licenses were less than $4K for a 1-seat license). I'll post this info
when I get it.

regards
Tony Cox

--------------------------------------------------------------------------------
Dr Anthony D Cox
Computer Systems Specialist
Stanford Synchrotron Radiation Laboratory
Stanford Linear Accelerator Center
MS 69, Box 4349
Stanford CA 94305
[email protected]
--------------------------------------------------------------------------------

Navigate by Date:
Prev: Re: string to binary conversion in the db William Lupton
Next: Re: Observations on EPICS Alpha port & DEC support of VxWorks Jeff Hill
Index: 1994  <19951996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: string to binary conversion in the db Marty Kraimer
Next: Re: Observations on EPICS Alpha port & DEC support of VxWorks Jeff Hill
Index: 1994  <19951996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·