EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

<20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  Index <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022 
<== Date ==> <== Thread ==>

Subject: RE: RISC_pad in dbr_time_double
From: "TYLER, Paul" <[email protected]>
To: "'Marty Kraimer'" <[email protected]>, Jeff Hill <[email protected]>
Cc: "'Andrew Johnson'" <[email protected]>, "'Janet Anderson'" <[email protected]>, [email protected], Ralph Lange <[email protected]>, Eric Norum <[email protected]>
Date: Mon, 9 Dec 2002 15:27:23 +1100
Hi Marty & Jeff (and everyone else),

I have compiled R3.14.0 cvs release of 8th Dec 2002 on our alphastations, using gcc3.2 under Digital
Unix 4.0d.  Initial tests (all I'm capable of doing at the moment) indicate that it works just as my
patched R3.14.0beta2 version did.  So thanks for the work.  (And I heard a couple of days ago that
HP are discontinuing development of the alpha chip!  I suppose there will be new 64 bit machines
come along though.)

The steps I required to compile the CVS version were:
1) Install my configuration files.  I've used "alpha-osf-gnu" for the architecture
(EPICS_HOST_ARCH).
2) In src/libCom/osi/os, I made a directory "osf" and copied the contents of "alpha".  I'm not sure
what "alpha" is for but the scripts/Makefiles go looking for an "osf" directory.  I also added the
SD_BOTH definition to osdSock.h in the osf directory.  It use to be in that file in the "alpha"
directory for the beta2 release, but has gone in the cvs release.  I didn't look into what that did.
I just put it back and hoped for the best!
3) There are issues with osdMutex.c.  The test on _XOPEN_SOURCE and the default osf/digital Unix
settings in /usr/include/standards.h cause an error.  Under osf _XOPEN_SOURCE is defined but has no
value and for some reason, this caused cpp to give an error.  That doesn't happen under x86 linux.
I can't work it out.  Anyway, I inserted various -D options in the configuration files to use the
code for _XOPEN_SOURCE<=500.  I didn't assess whether the new code would work.

If someone wants a tar of the files I needed to add, I'm happy to supply it.

If you want me to run any tests, supply me with code or tell me what to do.  I'll happily try them
out.

Jeff:
I have confirmed that the alpha does align doubles on 8 byte boundaries.  A program called "enquire"
in the gcc source code gives lots of information about the platform it is running on.

Once again, thanks for those who have put time into this.

Paul


-----Original Message-----
From: Marty Kraimer [mailto:[email protected]]
Sent: Saturday, 7 December 2002 2:39 AM
To: Jeff Hill
Cc: TYLER, Paul; 'Andrew Johnson'; 'Janet Anderson';
[email protected]; Ralph Lange; Eric Norum; Marty Kraimer
Subject: Re: RISC_pad in dbr_time_double


I have committed the changes I mentioned in a previous message.

Paul,

I hope you get a chance to test on your alpha machine next week. Note that 
Andrew makes nightly copies of the CVS repository. We are planning to start 
testing next week in preparation for release R3.14.1.

Eric and Ralph,

I am sorry that I forgot to include you on the previous messages about this 
topic. It was about problems when a long is 64 bits. Look at core-talk. Some of 
the messages appear there. At least enough that you will see the problem.

All,

Remember that next week we start testing in preparation for 3.14.1. Also Andrew 
is planning on using 3.14.1 for the EPICS classes he and Bob Dalesio are giving 
the first full week in January. He MUST have a version he can use a couple of 
days before we leave for Christmas (Dec 21). Thus lets try really really hard to 
have a release ready on Dec 16.

Marty

Replies:
Re: RISC_pad in dbr_time_double Marty Kraimer

Navigate by Date:
Prev: Re: RISC_pad in dbr_time_double Marty Kraimer
Next: Re: RISC_pad in dbr_time_double Marty Kraimer
Index: <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022 
Navigate by Thread:
Prev: Re: RISC_pad in dbr_time_double Marty Kraimer
Next: Re: RISC_pad in dbr_time_double Marty Kraimer
Index: <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·