Subject: |
BURT available on Alpha/Unix platform, but a few problems |
From: |
Tony Cox - (415)926-3105 <[email protected]> |
To: |
[email protected] |
Date: |
Tue, 08 Aug 1995 13:16:07 PST |
Hello all,
I've just got BURT running on the Alpha (including the GUI), and it
appears to function correctly. Nice. However, I would not admit to having
performed a complete test at present - there are some problems with SDDS file
tie-in which are not critical to my problem, so I'm leaving them for now.
There were a few `generic' problems with the port which it makes sense
to bring up here.
"isinf" is a function (in the SDDS library code) which does not exist
on Alpha/Unix. Presumably, this is a function (macro?) which is specific to
Sun systems. Alpha does not have a direct equivalent, the function being
approximated with "!finite(double)" and "!finitef(float)".
There are a number of related `oddities' which have cropped up in
the Alpha porting which really warrant a more coherent approach. It would be
very nice if we could move to regularizing the code by having all source files
include a generic "base/include/epics.h" header file where such machine
specific nonsense can be solved once and for all. Looking at my modifications,
I see lots of "#if defined(__alpha) && defined(__osf__)" constructions, which
are both ugly (when nested) and potentially wrong (I use the test to detect
client `endian' conditional code, but actually, the alpha can be both little-
and big-endian according to PAL code).
Such a header file can be used to define specific symbols and macros,
and would centralize the management. For example, Jeff uses "CA_LITTLE_ENDIAN"
for channel access conditional code, but the endianness concept is generically
needed. Here, epics.h might contains a definition such as
"EPICS__HOST_LITTLE_ENDIAN". Should we make this a goal for 3.13?
The other problem which bit me with BURT has got me before in other
contexts. BURT is written in C++ using templates, and in my experience
different compilers seem to have different strategies for when they generate
code to support template methods. This is particularly problematic when code
for classes derived from template instances is compiled. For the Alpha, I
have had some success by forcing generation of code in ALL compilation units
using "-define_templates", but of course, the side effect of this is pages
of "symbol multiply defined" messages at the linker stage. In the long term,
this really should be solved properly (linker errors abort the make), but I'm
not sufficiently familiar with how other compilers handle templates to propose
a general solution.
Developers should to be aware of this, and try keep things tidy.
Methods I've used in the past include trying to split up code into smaller
compilation units which specifically define the templates which are being used
(and can have -define_templates turned on), by writing small `dummy'
routines which are never called but which refer to template instances, and by
liberal use of the 'inline' keyword in header files.
Tony
--------------------------------------------------------------------------------
Dr Anthony D Cox
Computer Systems Specialist
Stanford Synchrotron Radiation Laboratory
Stanford Linear Accelerator Center
MS 69, Box 4349
Stanford CA 94305
[email protected]
--------------------------------------------------------------------------------
- Replies:
- Re: BURT available on Alpha/Unix platform, but a few problems watson
- Navigate by Date:
- Prev:
Re: BURT available on Alpha/Unix platform, but a few problems watson
- Next:
Alpha/DigitalUNIX availability - a summary. 415
- Index:
1994
<1995>
1996
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:
Re: ca_pend_event question (VAX/VMS only) 415
- Next:
Re: BURT available on Alpha/Unix platform, but a few problems watson
- Index:
1994
<1995>
1996
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
|