| 2002 2003 2004 2005 2006 2007 2008 2009 2010 <2011> 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 | Index | 2002 2003 2004 2005 2006 2007 2008 2009 2010 <2011> 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: [Merge] lp:~epics-core/epics-base/epicsR3.15-atomics into lp:epics-base |
| From: | Michael Davidsaver <[email protected]> |
| To: | Jeff Hill <[email protected]> |
| Cc: | EPICS core-talk <[email protected]>, [email protected] |
| Date: | Wed, 10 Aug 2011 18:19:11 -0400 |
On 8/10/2011 3:24 PM, Jeff Hill wrote:
...What other CPU-based code acceleration capabilities are we missing out on if we build for 22 year old 486 CPU architecture.
Agreed.
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, ...
Unfortunately -march=i586 sets both a minimum and maximum.
Windows XP requires a 586 processor or better. Suspect that Linux distros have similar minimum requirements.
From what I can tell, most recent linux distributions have toolchains defaulting to 586 or 686. Beyond that is the Intel/AMD split.
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.
The reason I hesitate to add a "-march=*" entry to the linux-x86 target is that it is (mostly) redundant now, and would be a restriction in the future. I would rather use the default that my linux distributor has chosen. This is one less thing in Base that needs to be kept up to date.
Michael http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options