It is currently Fri Jun 22, 2018 9:45 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 25 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Fri Jun 17, 2016 2:43 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7438
Location: Chexbres, VD, Switzerland
I am terribly disapointed at what is announced in the GCC 6.1 changelog.
Quote:
Support for a number of older systems and recently unmaintained or untested target ports of GCC has been declared obsolete in GCC 6. Unless there is activity to revive them, the next release of GCC will have their sources permanently removed.
[...]
Support for revisions of the ARM architecture prior to ARMv4t has been deprecated and will be removed in a future GCC release. [...] The value arm7tdmi is still supported.

This means that they probably plan to drop the ARM7tdmi in the future, which means doing GBA development with a future version of GCC might not be possible any longer.

What I really do not understand is that this decision is completely opposite to GNU philosophy. They're basically as much microsoft or apple like as they could, forcing users to move on and not use older hardware at all. They drop support for older hardware just because they think it's not needed anymore for new users, and even though old ARMs are basically like newer ARMs but with less instructions, so supporting them shouldn't be such a big problem, is it?


Top
 Profile  
 
PostPosted: Fri Jun 17, 2016 3:35 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 747
It's as it says, nobody was interested in maintaining the older, <1995 or so arm code. Companies lost interest more than a decade ago, and it's clear no volunteers who have that hw are interested in maintaining it. No need for conspiracies, not many even have hw that old to test things on.

No longer getting bugfixes or new standards/features for a 20 year old core is not a big loss, IMHO. If you have such an old core, you can just use the latest gcc 6.

Arm7tdmi is sufficiently popular I doubt it's going away in gcc 7. If it is, they will post adequate warning like that one, and folks with that hw can take up the maintenance.


Top
 Profile  
 
PostPosted: Fri Jun 17, 2016 5:03 am 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
The fact arm7tdmi was explicitly singled out of the group sounds like they're intending to keep that one case.

Bregalad wrote:
What I really do not understand is that this decision is completely opposite to GNU philosophy. They're basically as much microsoft or apple like as they could, forcing users to move on and not use older hardware at all.

What are you talking about, in my experience GNU is notorious for dropping old stuff and telling people to update their scripts for no reason other than "you should stay updated". Heck, they explicitly say they do this with autotools (there's a slideshow around mentioning this) >_<

GCC has been the exception to the rule mostly due to keeping Emacs on old systems (hence why 68000 is still supported)... which means no systems running Emacs use those old ARM processors possibly?

Bregalad wrote:
They drop support for older hardware just because they think it's not needed anymore for new users, and even though old ARMs are basically like newer ARMs but with less instructions, so supporting them shouldn't be such a big problem, is it?

Maintaining their RTL files may be a problem? (the files that indicate how to map each virtual opcode into a real CPU opcode)


Top
 Profile  
 
PostPosted: Fri Jun 17, 2016 7:04 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20165
Location: NE Indiana, USA (NTSC)
Bregalad wrote:
I am terribly disapointed at what is announced in the GCC 6.1 changelog.
Quote:
Support for revisions of the ARM architecture prior to ARMv4t has been deprecated and will be removed in a future GCC release. [...] The value arm7tdmi is still supported.

This means that they probably plan to drop the ARM7tdmi in the future, which means doing GBA development with a future version of GCC might not be possible any longer.

The ARM7TDMI processor implements the ARMv4t architecture (ARM architecture version 4 with Thumb). This means the GBA's CPU and the DS's IOP won't be affected. I worry more about Amber, a Free processor implementing ARMv2.

calima wrote:
No longer getting bugfixes or new standards/features for a 20 year old core is not a big loss, IMHO.

The fact that ARMv2 is 20 years old should be an advantage, as it means all the patents have expired. ARM architectures newer than ARMv2 are still patented, which makes free programs designed for them subject to a form of the Java Trap (free software with non-free dependencies).

This deprecation wasn't suggested by ARM in an attempt to make Amber less useful, was it?


Top
 Profile  
 
PostPosted: Fri Jun 17, 2016 7:30 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7438
Location: Chexbres, VD, Switzerland
Sik wrote:
The fact arm7tdmi was explicitly singled out of the group sounds like they're intending to keep that one case.

Could be, but for me the fact it is explicitely mentionned made it sound like they considered dropping it, but decided against it for now.

Quote:
in my experience GNU is notorious for dropping old stuff and telling people to update their scripts for no reason other than "you should stay updated".

Well, GNU or not, fuck this mentality.

Quote:
The fact that ARMv2 is 20 years old should be an advantage, as it means all the patents have expired.

+1. This is especially considering older ARMs are largely compatible with new ones, just with less instructions. The ARM1/2 with 26-bit PC are the exeption, as they have major difference in how the processor stauts word works.

Quote:
I worry more about Amber, a Free processor implementing ARMv2.

One of my student projects was to create an ARM clone, similar (but simper) to Amber. I was very glad to so something like that, and very proud to make something that could run C code compiled with GCC. With this new update this is no longer true.

What is the most enraging is that code generation should work almost exactly the same for those old ARMs, exept some instrucitons are lacking and should be replaced by more instructions to accomplish the same task (i.e. multiplications that lead to a 64 bit result should be done by several instructions instead of one). All else is exactly the same, so support of those processors should be a matter of adding a couple of "if/else" statements in the code generator, not something worth dropping in order to progress on the GCC project.

Quote:
No need for conspiracies,

Quote:
This deprecation wasn't suggested by ARM in an attempt to make Amber less useful, was it?

Sound like we just got one conspiration theory, at least. :)


Top
 Profile  
 
PostPosted: Fri Jun 17, 2016 8:34 am 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 1542
Location: Fukuoka, Japan
I may still be green about linux but my guess is even though it could be removed in a recent version, it doesn't mean you cannot still use the older one too. I don't think there will be a new update for that code anyway so an older compiler shouldn't be an issue. Or is there something to prevent older version of the compiler to work on newer os?


Top
 Profile  
 
PostPosted: Fri Jun 17, 2016 9:24 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20165
Location: NE Indiana, USA (NTSC)
Bregalad wrote:
What is the most enraging is that code generation should work almost exactly the same for those old ARMs, exept some instrucitons are lacking and should be replaced by more instructions to accomplish the same task (i.e. multiplications that lead to a 64 bit result should be done by several instructions instead of one). All else is exactly the same, so support of those processors should be a matter of adding a couple of "if/else" statements in the code generator, not something worth dropping in order to progress on the GCC project.

The problem is that when you change the architecture of the compiler, such as in order to be able to support a particular kind of optimization, you have to refactor all the code generators to support the new architecture. The more code generators you have, the more if/else statements you have to touch in each refactoring.

As for "new standards/features", today I learned that a standard called "C2x" is in development, whose draft charter adds "The evolution of safety-critical software development" as a source of influence. Microsoft's Checked C is an effort toward this, whose compiler is based on Clang,


Top
 Profile  
 
PostPosted: Fri Jun 17, 2016 9:28 am 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 985
tepples wrote:
... I worry more about Amber, a Free processor implementing ARMv2.
That is what I thought too; I would hope Amber to remain supported. Hopefully someone will revive them? I think that the newer ARM is not only full of patents but is also way too complicated! (There are other Free processors though, and I think RISC-V is supported by both GCC and LLVM, so you could still use that.)

But a lot of GNU software tends to be too bloated (like Microsoft is too), but at least the GNU software is Free. And there is also many better software that still uses GNU license, so it is still worth that too.

_________________
.


Top
 Profile  
 
PostPosted: Fri Jun 17, 2016 9:55 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 747
If any of you caring about ARMv2 have such cpus, and maybe some C experience, report in to maintain that. That's how it works, and then it won't be removed.


Top
 Profile  
 
PostPosted: Fri Jun 17, 2016 9:58 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20165
Location: NE Indiana, USA (NTSC)
Toward that end, I encourage anyone reading this who also has an opencores.org account to notify the Amber project of this deprecation through the core's forum topic.


Top
 Profile  
 
PostPosted: Fri Jun 17, 2016 10:27 am 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 4051
So besides adding thumb mode, what's the difference between the older ARM cpus and ARM7TDMI?
edit: Appears to be the 26-bit addressing that is the main difference. But besides that, is there a significant difference between ARM7TDMI and other ArmV3 if thumb mode is not used?

Also Wikipedia claims that ARM7TDMI was the most widely used ARM core in 2009, so it's probably not going anywhere.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Fri Jun 17, 2016 10:50 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20165
Location: NE Indiana, USA (NTSC)
SNESdev relevance: Fullsnes describes the ST018 coprocessor in Hayazashi Nidan Morita Shogi 2 as containing a CPU core implementing ARMv3. It's less relevant because ST018 uses an internal ROM, unless someone finds a total control exploit in its ROM. Last time I checked, higan was emulating it as an ARM7TDMI (which implements ARMv4) reusing GBA CPU code.


Top
 Profile  
 
PostPosted: Fri Jun 17, 2016 2:42 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
tepples wrote:
This deprecation wasn't suggested by ARM in an attempt to make Amber less useful, was it?

If GNU had accepted something like this then everything that isn't modern x86, ARM or PPC would have been deprecated as well. (EDIT: OK and maybe 68000 because of a lot of clones around being used as microcontrollers)


Top
 Profile  
 
PostPosted: Fri Jun 17, 2016 6:07 pm 
Offline
User avatar

Joined: Sat Jan 03, 2015 5:58 pm
Posts: 370
Location: ...
tepples wrote:
The ARM7TDMI processor implements the ARMv4t architecture (ARM architecture version 4 with Thumb). This means the GBA's CPU and the DS's IOP won't be affected.

This means devkitPro can stay updated, right? Hope so because the developers of it seem to be all about discouraging usage of deprecated software, so who knows what they'd do being stuck on old gcc.

(Okay honesty time, I don't even know how devkitPro's versions of gcc divert from the main version, this is just a guess).


Top
 Profile  
 
PostPosted: Fri Jun 17, 2016 6:08 pm 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2261
I don't see the issue. Want to do GBA dev? Just stay on the last version supporting like others have said. Otherwise, it's great to remove the bloat and pave the way for any new ARM infrastructure improvements to help everyone in the future. You never wanna keep support for anything that has no purpose and you can't test to make sure it does still actually have support.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 25 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Majestic-12 [Bot], Revenant and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group