EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: [Merge] lp:~epics-core/epics-base/epicsR3.15-atomics into lp:epics-base
From: "Jeff Hill" <[email protected]>
To: <[email protected]>
Cc: "'EPICS Core Talk'" <[email protected]>
Date: Wed, 10 Aug 2011 13:24:36 -0600
> Actually, where does the >=586 requirement come from?  

I made this (quick) decision originally based on some observed gcc preprocessor predefined macro differences (see attached below), but in fact that difference doesn’t matter if we are building for 32 bit architecture, and so it's true that i486 is sufficient for the gcc atomic intrinsic operations.

However we should ask ourselves another question. What other CPU-based code acceleration capabilities are we missing out on if we build for 22 year old 486 CPU architecture. IMHO 22 years is a long time in the tech business. As I recall, starting with the MS VS 2005 compiler MS dropped support for building for any processor before pentium II. Note also that this change is setting a minimum architecture for workstations, and has zero impact on the embedded platforms.

1989 486 introduced
1993 586 (Pentium I) introduced
1997 pentium II introduced
1999 pentium III introduced

Windows XP requires a 586  processor or better. Suspect that Linux distros have similar minimum requirements.

In the end it’s a judgment call on what minimum arch is appropriate so I defer to whatever consensus is arrived at. IMHO, our past practice of establishing no minimum x86 arch for workstations is probably not optimal, and setting 586 for R3.15 is unlikely to cause any substantive discomfort.

PS: While testing the performance on the various x86 versions I found a small ifdef bug (related to detecting sufficient x86 architecture on old gcc) in the gcc version of epicsAtomicCD.h for which I have pushed a fix to the atomics branch.

Jeff

g++ -march=i586 -E -dM -x c++ dog.cpp | sort

#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1

g++ -march=i486 -E -dM -x c++ dog.cpp | sort

#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1

With -march=i386

<none defined>
______________________________________________________
Jeffrey O. Hill           Email        [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA

With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925


> -----Original Message-----
> From: Michael Davidsaver [mailto:[email protected]] On Behalf Of
> Michael Davidsaver
> Sent: Wednesday, August 10, 2011 10:11 AM
> To: Jeff Hill
> Subject: Re: [Merge] lp:~epics-core/epics-base/epicsR3.15-atomics into
> lp:epics-base
> 
> On 08/05/2011 08:21 PM, Jeff Hill wrote:
> > I also made 586 (pentium circa 1995) the minimum architecture by default
> for mingw and linux so that we can have an efficient implementation.
> >
> 
> Actually, where does the >=586 requirement come from?  The only think I
> can find is:
> 
> http://gcc.gnu.org/wiki/Atomic
> 
> I just did a quick comparison of the generated code for -march=486 and
> -march=586
> 
> linux-486
> 
> > 00000020 <epicsAtomicTestAndSetUIntT>:
> >   20:   55                      push   %ebp
> >   21:   89 e5                   mov    %esp,%ebp
> >   23:   8b 45 08                mov    0x8(%ebp),%eax
> >   26:   ba 01 00 00 00          mov    $0x1,%edx
> >   2b:   87 10                   xchg   %edx,(%eax)
> >   2d:   85 d2                   test   %edx,%edx
> >   2f:   0f 94 c2                sete   %dl
> >   32:   31 c0                   xor    %eax,%eax
> >   34:   88 d0                   mov    %dl,%al
> >   36:   5d                      pop    %ebp
> >   37:   c3                      ret
> >   38:   90                      nop
> >   39:   8d b4 26 00 00 00 00    lea    0x0(%esi,%eiz,1),%esi
> 
> linux-x86 (with 586)
> 
> > 00000020 <epicsAtomicTestAndSetUIntT>:
> >   20:   55                      push   %ebp
> >   21:   ba 01 00 00 00          mov    $0x1,%edx
> >   26:   89 e5                   mov    %esp,%ebp
> >   28:   8b 45 08                mov    0x8(%ebp),%eax
> >   2b:   87 10                   xchg   %edx,(%eax)
> >   2d:   85 d2                   test   %edx,%edx
> >   2f:   0f 94 c2                sete   %dl
> >   32:   31 c0                   xor    %eax,%eax
> >   34:   5d                      pop    %ebp
> >   35:   88 d0                   mov    %dl,%al
> >   37:   c3                      ret
> >   38:   90                      nop
> >   39:   8d b4 26 00 00 00 00    lea    0x0(%esi,%eiz,1),%esi
> 
> The active ingredient "xchg   %edx,(%eax)" is the same in both cases.
> 
> For increment this is the same with "lock xadd %eax,(%edx)".
> 
> I think the >=586 statement from the gcc wiki might be for the full
> compare-and-swap operation.



Replies:
Re: [Merge] lp:~epics-core/epics-base/epicsR3.15-atomics into lp:epics-base Michael Davidsaver
References:
[Merge] lp:~epics-core/epics-base/epicsR3.15-atomics into lp:epics-base Jeff Hill

Navigate by Date:
Prev: Re: [Merge] lp:~epics-core/epics-base/epicsR3.15-atomics into lp:epics-base mdavidsaver
Next: Re: [Merge] lp:~epics-core/epics-base/epicsR3.15-atomics into lp:epics-base Jeff Hill
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: [Merge] lp:~epics-core/epics-base/epicsR3.15-atomics into lp:epics-base Jeff Hill
Next: Re: [Merge] lp:~epics-core/epics-base/epicsR3.15-atomics into lp:epics-base Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
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 ·