| Message ID | 56CDB728.1050300@arm.com |
|---|---|
| State | New |
| Headers | show |
On Wed, 24 Feb 2016, Richard Earnshaw (lists) wrote: > After discussion with the ARM port maintainers we have decided that now > is probably the right time to deprecate support for versions of the ARM > Architecture prior to ARMv4t. This will allow us to clean up some of Should this include -march=armv5 and -march=armv5e (the theoretical no-Thumb versions of v5, which may never have had any corresponding processors)?
On 24/02/16 17:38, Joseph Myers wrote: > On Wed, 24 Feb 2016, Richard Earnshaw (lists) wrote: > >> After discussion with the ARM port maintainers we have decided that now >> is probably the right time to deprecate support for versions of the ARM >> Architecture prior to ARMv4t. This will allow us to clean up some of > > Should this include -march=armv5 and -march=armv5e (the theoretical > no-Thumb versions of v5, which may never have had any corresponding > processors)? > It's a fair question, but the answer is no, this isn't necessary. The point is to permit the compiler to use interworking compatible sequences of code when generating ARM code, not to force users to use Thumb code. The necessary instruction (BX) is available in armv5 and armv5e, even though Thumb is not supported in those architecture variants. It might be worth deprecating v5 and v5e at some point in the future: to the best of my knowledge no v5 class device without Thumb has ever existed - but it's not a decision that needs to be related to this proposal. R.
On Thu, Feb 25, 2016 at 10:20 AM, Richard Earnshaw (lists) <Richard.Earnshaw@arm.com> wrote: > The point is to permit the compiler to use interworking compatible > sequences of code when generating ARM code, not to force users to use > Thumb code. The necessary instruction (BX) is available in armv5 and > armv5e, even though Thumb is not supported in those architecture variants. > > It might be worth deprecating v5 and v5e at some point in the future: to > the best of my knowledge no v5 class device without Thumb has ever > existed - but it's not a decision that needs to be related to this proposal. Slightly off topic, but related: What does the "e" stand for? Also, what does "l" stand for in armv5tel, which is what I usually get -- little endian? I have no idea if there is an authoritative source for these host specifications and cannot find any. config.guess seems to just rely on uname -m.
On 25/02/16 13:32, Stefan Ring wrote: > On Thu, Feb 25, 2016 at 10:20 AM, Richard Earnshaw (lists) > <Richard.Earnshaw@arm.com> wrote: >> The point is to permit the compiler to use interworking compatible >> sequences of code when generating ARM code, not to force users to use >> Thumb code. The necessary instruction (BX) is available in armv5 and >> armv5e, even though Thumb is not supported in those architecture variants. >> >> It might be worth deprecating v5 and v5e at some point in the future: to >> the best of my knowledge no v5 class device without Thumb has ever >> existed - but it's not a decision that needs to be related to this proposal. > > Slightly off topic, but related: What does the "e" stand for? Also, > what does "l" stand for in armv5tel, which is what I usually get -- > little endian? The 'e' represented some extensions to the original v5 ISA (you can make your own mind up as to what the 'e' stands for). The 'l' isn't anything to do with the architecture per-se. It simply means in the Linux context a little-endian device, as opposed to a 'b'ig-endian device. Most ARM based systems are little-endian so you'll see that far more often than 'b'. > I have no idea if there is an authoritative source for these host > specifications and cannot find any. config.guess seems to just rely on > uname -m. > For the AArch32 it's extremely ad-hoc. There's a bit more sanity in the AArch64 world, but it relies on people following some conventions and not just creating anarchy. R.
On 25/02/16 14:32, Stefan Ring wrote: > On Thu, Feb 25, 2016 at 10:20 AM, Richard Earnshaw (lists) > <Richard.Earnshaw@arm.com> wrote: >> The point is to permit the compiler to use interworking compatible >> sequences of code when generating ARM code, not to force users to use >> Thumb code. The necessary instruction (BX) is available in armv5 and >> armv5e, even though Thumb is not supported in those architecture variants. >> >> It might be worth deprecating v5 and v5e at some point in the future: to >> the best of my knowledge no v5 class device without Thumb has ever >> existed - but it's not a decision that needs to be related to this proposal. > > Slightly off topic, but related: What does the "e" stand for? Also, > what does "l" stand for in armv5tel, which is what I usually get -- > little endian? <https://community.arm.com/groups/processors/blog/2011/11/02/arm-fundamentals-introduction-to-understanding-arm-processors> <https://en.wikipedia.org/wiki/List_of_ARM_microarchitectures> The "t" is thumb, "e" means "DSP-like extensions", and I suspect the "l" is a misprint for "j", meaning the Jazelle (Java) acceleration instructions. > > I have no idea if there is an authoritative source for these host > specifications and cannot find any. config.guess seems to just rely on > uname -m. >
On 25/02/16 14:15, David Brown wrote: > On 25/02/16 14:32, Stefan Ring wrote: >> On Thu, Feb 25, 2016 at 10:20 AM, Richard Earnshaw (lists) >> <Richard.Earnshaw@arm.com> wrote: >>> The point is to permit the compiler to use interworking compatible >>> sequences of code when generating ARM code, not to force users to use >>> Thumb code. The necessary instruction (BX) is available in armv5 and >>> armv5e, even though Thumb is not supported in those architecture variants. >>> >>> It might be worth deprecating v5 and v5e at some point in the future: to >>> the best of my knowledge no v5 class device without Thumb has ever >>> existed - but it's not a decision that needs to be related to this proposal. >> >> Slightly off topic, but related: What does the "e" stand for? Also, >> what does "l" stand for in armv5tel, which is what I usually get -- >> little endian? > > <https://community.arm.com/groups/processors/blog/2011/11/02/arm-fundamentals-introduction-to-understanding-arm-processors> > > <https://en.wikipedia.org/wiki/List_of_ARM_microarchitectures> > > The "t" is thumb, Correct. "e" means "DSP-like extensions", Correct. But there were other bits as well. and I suspect the "l" > is a misprint for "j", meaning the Jazelle (Java) acceleration instructions. No. As I said earlier, it's nothing to do with the architecture, but means the system is running little-endian. R.
On Thu, Feb 25, 2016 at 3:15 PM, David Brown <david@westcontrol.com> wrote: > The "t" is thumb, "e" means "DSP-like extensions", and I suspect the "l" > is a misprint for "j", meaning the Jazelle (Java) acceleration instructions. I doubt that as "armv5tejl" is also quite common.
On Thu, Feb 25, 2016 at 3:15 PM, David Brown <david@westcontrol.com> wrote:
> <https://community.arm.com/groups/processors/blog/2011/11/02/arm-fundamentals-introduction-to-understanding-arm-processors>
Great link, thanks!
On 24/02/16 13:59, Richard Earnshaw (lists) wrote: > After discussion with the ARM port maintainers we have decided that now > is probably the right time to deprecate support for versions of the ARM > Architecture prior to ARMv4t. This will allow us to clean up some of > the code base going forwards by being able to assume: > - Presence of half-word data accesses > - Presence of Thumb and therefore of interworking instructions. > > This patch records the status change in the GCC-6 release notes. > > I propose to commit this patch later this week. > Now done. R. > R. > > > deprecate.patch > > > Index: htdocs/gcc-6/changes.html > =================================================================== > RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v > retrieving revision 1.61 > diff -u -r1.61 changes.html > --- htdocs/gcc-6/changes.html 19 Feb 2016 05:00:54 -0000 1.61 > +++ htdocs/gcc-6/changes.html 19 Feb 2016 14:47:31 -0000 > @@ -340,7 +340,14 @@ > <h3 id="arm">ARM</h3> > <ul> > <li> > - The arm port now supports target attributes and pragmas. Please > + Support for revisions of the ARM architecture prior to ARMv4t has > + been deprecated and will be removed in a future GCC release. > + This affects ARM6, ARM7 (but not ARM7TDMI), ARM8, StrongARM, and > + Faraday fa526 and fa626 devices, which do not have support for > + the Thumb execution state. > + </li> > + <li> > + The ARM port now supports target attributes and pragmas. Please > refer to the <a href="https://gcc.gnu.org/onlinedocs/gcc/ARM-Function-Attributes.html#ARM-Function-Attributes"> > documentation</a> for details of available attributes and > pragmas as well as usage instructions. >
On Wed, 24 Feb 2016, Richard Earnshaw (lists) wrote:
> I propose to commit this patch later this week.
+ Support for revisions of the ARM architecture prior to ARMv4t has
+ been deprecated and will be removed in a future GCC release.
+ This affects ARM6, ARM7 (but not ARM7TDMI), ARM8, StrongARM, and
+ Faraday fa526 and fa626 devices, which do not have support for
+ the Thumb execution state.
I am wondering whether this may be confusing for those not
intricately familiar with the older history of ARM platforms.
ARMv8 is pretty new, googling for it has
http://www.arm.com/products/processors/armv8-architecture.php
as first hit, for example, and the only difference versus ARM8
is that little lower-case "v".
Gerald
On February 28, 2016 3:20:24 PM CST, Gerald Pfeifer <gerald@pfeifer.com> wrote: >On Wed, 24 Feb 2016, Richard Earnshaw (lists) wrote: >> I propose to commit this patch later this week. > >+ Support for revisions of the ARM architecture prior to ARMv4t >has >+ been deprecated and will be removed in a future GCC release. >+ This affects ARM6, ARM7 (but not ARM7TDMI), ARM8, StrongARM, >and >+ Faraday fa526 and fa626 devices, which do not have support for >+ the Thumb execution state. > >I am wondering whether this may be confusing for those not >intricately familiar with the older history of ARM platforms. > >ARMv8 is pretty new, googling for it has > http://www.arm.com/products/processors/armv8-architecture.php >as first hit, for example, and the only difference versus ARM8 >is that little lower-case "v". I assume this means a number of values for the various -mXXX arguments will be removed. Would it be more helpful to list those values? I have to agree with Gerald. I think this will obsolete a few older RTEMS BSPs but based on that wording, I don't know which. >Gerald --joel
On 28/02/16 21:34, Joel Sherrill wrote: > > On February 28, 2016 3:20:24 PM CST, Gerald Pfeifer <gerald@pfeifer.com> wrote: >> On Wed, 24 Feb 2016, Richard Earnshaw (lists) wrote: >>> I propose to commit this patch later this week. >> + Support for revisions of the ARM architecture prior to ARMv4t >> has >> + been deprecated and will be removed in a future GCC release. >> + This affects ARM6, ARM7 (but not ARM7TDMI), ARM8, StrongARM, >> and >> + Faraday fa526 and fa626 devices, which do not have support for >> + the Thumb execution state. >> >> I am wondering whether this may be confusing for those not >> intricately familiar with the older history of ARM platforms. >> >> ARMv8 is pretty new, googling for it has >> http://www.arm.com/products/processors/armv8-architecture.php >> as first hit, for example, and the only difference versus ARM8 >> is that little lower-case "v". > I assume this means a number of values for the various -mXXX arguments will be removed. Would it be more helpful to list those values? > > I have to agree with Gerald. I think this will obsolete a few older RTEMS BSPs but based on that wording, I don't know which. ARM8 is a processor, whereas ARMv8-A is an architecture. I think Richard's link earlier in the thread: https://community.arm.com/groups/processors/blog/2011/11/02/arm-fundamentals-introduction-to-understanding-arm-processors gives a good explanation of the naming schemes. The -mcpu/-mtune arguments that would be deprecated can be found by looking at the file config/arm/arm-cores.def and finding all the ARM_CORE entries that have '4' or lower in their 4th field These would be: arm2,arm250,arm3,arm6,arm60,arm600,arm610,arm620,arm7,arm7d,arm7di,arm70,arm700,arm700i,arm710, arm720,arm710c,arm7100,arm7500,arm7500fe,arm7m,arm7dm,arm7dmi,arm8,arm810,strongarm,strongarm110, strongarm1100,strongarm1110,fa526,fa626. The arguments to -march that would be deprecated are: armv2,armv2a,armv3,armv3m,armv4. I personally think that list is a bit too long for changes.html. Do you think it would add more clarity for people who are not familiar with the situation? Thanks, Kyrill >> Gerald > --joel >
On 2/29/2016 5:37 AM, Kyrill Tkachov wrote: > > On 28/02/16 21:34, Joel Sherrill wrote: >> >> On February 28, 2016 3:20:24 PM CST, Gerald Pfeifer <gerald@pfeifer.com> wrote: >>> On Wed, 24 Feb 2016, Richard Earnshaw (lists) wrote: >>>> I propose to commit this patch later this week. >>> + Support for revisions of the ARM architecture prior to ARMv4t >>> has >>> + been deprecated and will be removed in a future GCC release. >>> + This affects ARM6, ARM7 (but not ARM7TDMI), ARM8, StrongARM, >>> and >>> + Faraday fa526 and fa626 devices, which do not have support for >>> + the Thumb execution state. >>> >>> I am wondering whether this may be confusing for those not >>> intricately familiar with the older history of ARM platforms. >>> >>> ARMv8 is pretty new, googling for it has >>> http://www.arm.com/products/processors/armv8-architecture.php >>> as first hit, for example, and the only difference versus ARM8 >>> is that little lower-case "v". >> I assume this means a number of values for the various -mXXX arguments will be removed. Would it be more helpful to list those values? >> >> I have to agree with Gerald. I think this will obsolete a few older RTEMS BSPs but based on that wording, I don't know which. > > ARM8 is a processor, whereas ARMv8-A is an architecture. > I think Richard's link earlier in the thread: > > https://community.arm.com/groups/processors/blog/2011/11/02/arm-fundamentals-introduction-to-understanding-arm-processors > > gives a good explanation of the naming schemes. > The -mcpu/-mtune arguments that would be deprecated can be found by looking at the > file config/arm/arm-cores.def and finding all the ARM_CORE entries that have '4' or lower in their > 4th field These would be: That you referred to code to know the impact seems to confirm my concern that this is not something most users would realize. > arm2,arm250,arm3,arm6,arm60,arm600,arm610,arm620,arm7,arm7d,arm7di,arm70,arm700,arm700i,arm710, > arm720,arm710c,arm7100,arm7500,arm7500fe,arm7m,arm7dm,arm7dmi,arm8,arm810,strongarm,strongarm110, > strongarm1100,strongarm1110,fa526,fa626. > > The arguments to -march that would be deprecated are: > armv2,armv2a,armv3,armv3m,armv4. > > I personally think that list is a bit too long for changes.html. It didn't seem that long and makes a nice checklist. FWIW I am one of the original RTEMS developers, 25+ years of embedded work, gcc, etc. and I couldn't have have evaluated the impact of the original statement easily. Those with more knowledge ARM GCC specifics (like you) gave a precise detailed answer with what sounds like just a few minutes. > Do you think it would add more clarity for people who are not familiar with the situation? Absolutely. That's an authoritative list. From that list, anyone can grep their build system to see which boards and configurations would be impacted. And honestly, when I saw the initial statement, I was concerned about how many older ARM RTEMS BSPs would be obsoleted. But seeing the specific list, I don't think we have any that are impacted. The extra information just makes it very precise and clear what's going away. FWIW I am on a standards group and one of the things I repeatedly say is that if we leave room for someone to ask a question, then they have a chance to get an answer we didn't intend. So try to avoid letting someone with less knowledge ask the question. :) --joel > Thanks, > Kyrill > >>> Gerald >> --joel >> >
Index: htdocs/gcc-6/changes.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v retrieving revision 1.61 diff -u -r1.61 changes.html --- htdocs/gcc-6/changes.html 19 Feb 2016 05:00:54 -0000 1.61 +++ htdocs/gcc-6/changes.html 19 Feb 2016 14:47:31 -0000 @@ -340,7 +340,14 @@ <h3 id="arm">ARM</h3> <ul> <li> - The arm port now supports target attributes and pragmas. Please + Support for revisions of the ARM architecture prior to ARMv4t has + been deprecated and will be removed in a future GCC release. + This affects ARM6, ARM7 (but not ARM7TDMI), ARM8, StrongARM, and + Faraday fa526 and fa626 devices, which do not have support for + the Thumb execution state. + </li> + <li> + The ARM port now supports target attributes and pragmas. Please refer to the <a href="https://gcc.gnu.org/onlinedocs/gcc/ARM-Function-Attributes.html#ARM-Function-Attributes"> documentation</a> for details of available attributes and pragmas as well as usage instructions.