GCC drops support for older ARM CPUs

I am terribly disapointed at what is announced in the GCC 6.1 changelog.

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?

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.

The fact arm7tdmi was explicitly singled out of the group sounds like they're intending to keep that one case.


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?


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

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.


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?

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.


Well, GNU or not, fuck this mentality.


+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.


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.



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

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?

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,

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.

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.

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.

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.

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.

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)

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).

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.

Yes, as a temporary measure. Eventually I'll separate the two once I'm confident we have nearly all the ARM CPU bugs quashed. Since it's backward-compatible and the ST018 ROM is fixed, there's no harm to emulator accuracy (well, maybe timings, but they're a giant unknown on the ST018 anyway.)

That said, higan does let you substitute your own ARM program/data ROMs, so you can run your own pograms. The major downside that makes the chip near-useless is that there's no DMA bridge. Getting data in and out of the ST018 greatly limits its utility.

I have thought about an ARM+ mode, where you get a nice DMA bridge and full ARM7 functionality (THUMB, etc.) Combined with setting the clock rate to whatever your PC can handle (it's an interpreter so 21MHz is probably the limit for most people anyway), it could serve as the "CPU muscle" behind MSU1 to push the SNES to its absolute theoretical limits.

You could call it "I wish this was a GBA" mode, especially if you limit active display to 160-176 lines to get more video memory bandwidth and fit modern widescreen TVs. When exactly do Thumb-related patents expire? Wikipedia says the first ARM7T was in 1997, and the ARM7TDMI was in 1998.

"Super GBA"? That's not really going to net you enough bandwidth to do it, would it? Seems contrary to all the "no, Super GBC is not possible" discussion results…

When I built mine, I went through the patches. The gcc patches weren't necessary, and I don't think I applied them.

The difference is that in what byuu describes, the cart wouldn't be generating video. Instead, the game would run on the ARM, using the S-CPU and S-SMP just for I/O. A DMA-driven planar/packed converter would even allow for software rendering.

I would imagine it could be used for 3D rendering instead of the SuperFX. I'd assume you'd get about the 3D processing power of a 32X if so (yes, it's two CPUs, but if you do 3D rendering you'll probably just use one... well, maybe the other to do the vertex calculations instead of plotting pixels), albeit with an obvious hit to color depth, that is.

...OK I'm bullshitting, it'd still be noticeably less powerful than a 32X in all metrics =P but should allow more polygons than what a SuperFX 2 can push. And it's probably easier to get an ARM CPU than a SuperFX clone if you make cartridges.

How well would an ARM CPU manage blitting into 4bpp interleaved bitplane format?

From SNES wiki:

The SA-1 includes it own DMA controller that is part of the character conversion logic that can convert bitmap-formatted graphics to the SNES PPU’s character format (ie: tiled) graphics.

Didn't Drakkhen have a similar converter? Fullsnes doesn't list it.

Well, I could pretend I was asking about native capabilities because a specialized DMA unit might be difficult to source and complicated to integrate.

But I wasn't. Shouldn't have posted when in a hurry...


Dungeon Master reportedly used the DSP-2 for graphics conversion. No idea about Drakkhen; superfamicom.org doesn't list anything either.

Done.

The main difference is that there is many instructions present in ARM7TDMI which aren't present in ARM3 architecture. The most relevant ones are the long multiplication instructions (UMLL and SMLL), and the BX instruction, which is extremely frequently used, which has to be written as MOV R15, R14. (GCC currently supports a way to tun BX LR into MOV R15, R14 automatically, but it appears this'll be dropped).

This is related to Thumb mode, as a MOV R15, R14 on a modern ARM processor will always stays in the same mode, potentially crashing the processor when returning from one mode to another.

26-bit adressing is only used in ARM1 and ARM2, and those are largely not binary compatible with ARM3+. The instruction set is the same (exept maybe lacking instructions) but the processor status word works in a completely different way, being stored in the unused bits of R15. This means the link register also stores/restores the status word when entering/leaving a routine.