@matthey

I didn't know the Amiga came out in 1979, that's 45 years ago.

_________________
Sent from my Quantum Computer.

@Gunnar

Quote:

Using 020 code will result in smaller binaries. If you review the code changes 3.2 then you see that a number changes had not purpose except to save a few bytes! This mean the Rom size limit gives a serious problem. Using 020 code would help a lot to save bytes.

And this is a non-issue with the current model
- all 020+ systems already have their own kickstarts for various reasons
- all 68000 systems share kickstart
- _very_ few components are different in the above, but optimizing kickstarts that are already targeting specific hardware is a non-issue

Quote:

With memcopy you sometimes have misaligned cases. That you can NOT resolve on the 68000. And you need to fallback to use BYTE loops. The 68020+ do not have this problem. This means you can on them use LONG WORD loops. This can make a huge difference. Not just 1% but for some cases 400% speed.

Great - which OS components on disk likely to be occupied with memcopy?

exec.library and scsi.device are already "custom" for each kickstart, and I presume already optimized for their relevant "baseline" CPUs.

graphics.library is not
layers,library is not
intuition.library is not
gadtools.library is not
version.library is not
dos.library is not
icon.library is not
workbench.library is not
math libs are not
filesystem is not (and CPU-dependent fs on RDB would suck)

Quote:

You want to use those features to get good speed - not only in memcopy, also in IDE driver, or GFX functions. This is the reason that p96 Code is 20+ only

Another good reason is that adding RTG graphics to the 68000 systems has not been trivial and rather obscure. Except for the A2000.

But P96 isn't the OS, it is third party.

People are arguing that the operating system should be 020+ optimized, and I am asking what components would that be (which aren't already, or are patched at boot by SetPatch) - like I wrote, it would suck if removing a CPU card in a 68000 system also would require replacing the entire OS. I am not talking about third party add-ons and software, I am talking about the base OS, that lets you enter early startup boot menu, select to boot without startup sequence, provide a shell and working DOS commands, maybe load workbench and use tools like HDToolBox - _also_ when the CPU is just a 68000.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@matthey

Quote:

You don't experience a performance difference because you use an AmigaOS compiled for a 45 year old 16 bit CPU and a cheap FPGA that can only simulate a 45 year old 16 bit 68000 CPU.

What's that meant to imply?

I want to know what OS components (disk) optimized for 020+ would work faster on actual 020+ systems than the equivalent (current) 68000 components. I would expect 020 optimization gains to be most visible on slower 020 systems. Where does "a cheap FPGA that can only simulate a 45 year old 68000 CPU" come in here? I don't even know of any such system today, since many, many years they all use TG68/020.

I know that some binaries in 3.2 already are "fat" in that they detect if CPU is 68020+ and then use "optimized" 020 code (iirc, datatype.library and its sublibs... "classes"), similarly to how the math libs also are CPU+FPU aware. From my POV, that's the best way to go about this.

Last edited by kolla on 10-Apr-2024 at 02:19 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@matthey

Quote:

matthey wrote: I see both sides. Some AmigaOS users need 68000 compatibility and the 68k Amiga market is retro so it makes sense to provide it. Some AmigaOS users want the advantages of improved support, improved performance and reduced footprint of a 32 bit AmigaOS for their 32 bit hardware. My suggestion was to provide both a 68000 and 68020+ AmigaOS.

This seems fair & reasonable if:

1. OS3.2/3 had lots of unnecessary demanding components like OS3.9.
2. It didn't lead to real world problems (see my post #14 & kolla's posts).
3. There wasn't a good more advanced alternative OS for the V4 (be surprised if PiStorm doesn't get some good AROS support soon as well).
4. Someone had already stated or will now state in plain English (not coding speak) what actual tools, utilities etc. (apart from IDE driver) would gain a genuine substantial speed up for the end user!
5. The OS3.3 development team (who are volunteers) hadn't already made an informed decision.

Last edited by Tpod on 10-Apr-2024 at 12:01 PM.

_________________
A1200+Mediator+Voodoo3+040+130mbRAM+0S3.9
A2000+Supra28mhz+9mbRAM+OS3.2.2, CD32 & WinUAE

@kolla

Quote:

Well, I have yet to see any real optimization for 68020. Even with the slowest 020 systems around, the speed difference between 68000 code and so called optimized 020+ code seem negligible. So what’s the point? 020+ binaries just create silly incompatibilites and extra work, for extremely little gain.

Some optimisations are in hardware. For example a full 32 bit move will be split into two 16 bit bus moves on a 68000. On a 68020 it has a full 32 bit bus so isn't crippled and the same code can run at full speed.

There are other OS optimisations in places like exec and utility.library. Things like moving memory and 32 bit math routines. The OS can and does patch these functions on demand. Allowing base OS code to function as always on 68000.

32-bit support in Amiga land was not a problem before with this system. The only difference used to be in installed software and drivers. Where usually an installer installed the best version for your CPU. Since Amiga didn't have the concept of fat binaries with extra optimised code in binaries, we didn't see binaries with all supported CPU versions embedded, but redundant data wasted on most installs wasn't suitable on Amiga any way. The only problem with this current system of installing on demand is that if you need to drop back to a lesser CPU the system will have incompatible code and will crash. And there is no system in place here to fall back to base code compatible with all CPUs. A 68020/68030/+ dir could be created in Libs and optimised versions put there that the system would load first but that wasn't implemented. It could still be possible to do that with an assign list but that shouldn't be up the the user. On top of this are the complication of 68040 and 68060.library binaries needed or newer CPUs would crash on boot.

Last edited by Hypex on 10-Apr-2024 at 03:44 PM.

DiscreetFX Quote:

I didn't know the Amiga came out in 1979, that's 45 years ago.

The 16 bit 68000 was over 5 years old when the Amiga launched. The 32 bit 68020 was released in 1984 but was expensive ($487 vs $15 for 68000) and had limited availability due to high demand and fab problems.

1979 68000
1982 68010
1984 68020
1985 Amiga

The Amiga is nearly 40 years old too.

kolla Quote:

What's that meant to imply? I want to know what OS components (disk) optimized for 020+ would work faster on actual 020+ systems than the equivalent (current) 68000 components. I would expect 020 optimization gains to be most visible on slower 020 systems. Where does "a cheap FPGA that can only simulate a 45 year old 68000 CPU" come in here? I don't even know of any such system today, since many, many years they all use TG68/020.

I expect slower clocked 68020 systems to have more noticeable gains too. A 68060 often has larger percentage gains but they often aren't noticeable for lightweight AmigaOS code. I hand optimized some components AmigaOS components but I didn't have the newer AmigaOS. One exception is ThoR's layers.library which is on Aminet. It has been several years but I recall some improvements with the largest gains coming from 68020+ index register scaling. There was a nice code reduction (10%-20%?) in the layer sort function but I don't recall this using any 68020 instructions and the 68060 handled it well where a lower clocked 68k CPU may see a more noticeable improvement. I did see improvements in the P96Speed benchmark but I did other optimizations too. P96 uses its own memory copy routine which is less than optimal by the way. I also did large optimizations in Warp3D which had major code optimization problems. Warp3D.library suffers from lack of index register scaling and may have been compiled for a 68000 target but the compiler used was horrible too. I was able to reduce the size of the library to about 60% and half of the original size is likely possible. The largest performance gain was for indirect rendering which made most OpenGL demos run with double the frame rate. For Quake using direct rendering, there was a couple of frames/sec increase (~10%) but most of this came from optimizations in the Voodoo libraries which were compiled for the 68040 avoiding the FINT(RZ) instructions that are present on the 68060 and I added back. There was a substantial memory savings of tens of thousands to hundreds of thousands of bytes. I optimized the AmigaOS 3.9 Genesis user interface saving similar large amounts of memory which may have been compiled for the 68000 and had optimizations problems.

Performance improvements from 68020 code are generally modest. I expect 5%-15% performance improvements on average with 5% being a 68020 and 15% a 68060 but 5% on a low clocked 68020 may be more noticeable than 15% on a high clocked 68060. I expect memory savings to be 10%-20% on average. Assembler optimizations could give further gains. I expect the AmigaOS could be shrunk by 15%-30% with 68020 code and assembler optimizations. With ColdFire optimizations added, a 20%-40% AmigaOS size reduction may be possible giving a tiny footprint. AmigaOS using SAS/C (mediocre code generation quality) and a 16 bit 68000 target is far from optimal.

kolla Quote:

I know that some binaries in 3.2 already are "fat" in that they detect if CPU is 68020+ and then use "optimized" 020 code (iirc, datatype.library and its sublibs... "classes"), similarly to how the math libs also are CPU+FPU aware. From my POV, that's the best way to go about this.

Calling 68020 functions help but is partially offset by call overhead. Some of the optimized code is not really optimal like the 68020+ CopyMem() and CopyMemQuick() functions which is why they are often patched with visible results. If you have a 68060 system, try my CopyMem patch and scroll windows in AWeb to see a performance difference.

http://aminet.net/package/util/boot/CopyMem

Other AmigaOS enhancements and improvements, especially algorithm improvements, have higher priority and should be performed before most optimizations. Premature optimization of poor quality algorithms is best avoided. Compiling for a 68020 target is relatively easy with nice improvements now though.

@matthey

Being a non-coder (just an Intermediate user) I believe it's just dawned on me that I hadn't grasped the range of things affected by an 020+ optimised version; also why there has been, to quote myself, all the “code speak� !

Am I right in thinking a large amount of the OS would gain a speed up (however small), which would effect almost any program launched speed wise (not just programs that comes with the OS)?

If that's the case, I now understand why it would be tricky to give clear examples of what Software would benefit. The issues remain (so I've not changed opinion) but I can see things from both sides myself now.

Last edited by Tpod on 11-Apr-2024 at 02:09 AM.

_________________
A1200+Mediator+Voodoo3+040+130mbRAM+0S3.9
A2000+Supra28mhz+9mbRAM+OS3.2.2, CD32 & WinUAE

Tpod Quote:

Being a non-coder (just an Intermediate user) I believe it's just dawned on me that I hadn't grasped the range of things affected by an 020+ optimised version; also why there has been, to quote myself, all the “code speak� ! Am I right in thinking a large amount of the OS would gain a speed up (however small), which would effect almost any program launched speed wise (not just programs that comes with the OS)?

Correct. Individual AmigaOS optimization performance advantages may be modest but there are multiple and cumulative advantages to more optimal code which is smaller on the 68k. Small code increases performance due to improved cache efficiency, memory is decreased giving a smaller system footprint and programs load faster from disk including modules like libraries. AmigaOS is the shared code base many programs are built on. It is desirable for developers to use it rather than avoid it because their own code has better performance which was not unusual in the early days of the Amiga (AmigaOS patches are also undesirable as they can introduce bugs). Cumulative performance improves as layers of code in libraries improve as you have pointed out, even in the AmigaOS itself. A higher performance graphics.library may improve intuition.library and layers.library performance which can also be improved. Amiga GUIs, datatypes, RTG and 3D APIs are built on this. Then there are the programs which use all these layers of what should be optimal AmigaOS code and can be optimized themselves. Poor performance due to layer upon layer of poorly optimized code is often a problem on the Amiga. It isn't easily solved as 68k Amiga compilers need improvement but using a 68020 target compiler switch when compiling may raise the AmigaOS code optimization grade from C- to a C for 68020+ systems with minimal problems. Further improvements are possible but more difficult and the AmigaOS needs higher priority improvements. The 68k AmigaOS is stuck way in the past in some ways and will take time to improve if development continues which is likely.

Tpod Quote:

If that's the case, I now understand why it would be tricky to give clear examples of what Software would benefit. The issues remain (so I've not changed opinion) but I can see things from both sides myself now.

Yea, there are many variables when measuring performance improvements.

Last edited by matthey on 11-Apr-2024 at 06:29 PM.

@matthey

Thanks for the nice clear summary. Do you know of any C compilers for Amiga getting updates currently? With a much greater proliferation of cheap 020+ accelerators, I could see the case at least getting stronger for 020+ version, when combined with an excellent compiler available, by the time we get to OS3.4+.

_________________
A1200+Mediator+Voodoo3+040+130mbRAM+0S3.9
A2000+Supra28mhz+9mbRAM+OS3.2.2, CD32 & WinUAE

@Tpod Quote:

Thanks for the nice clear summary. Do you know of any C compilers for Amiga getting updates currently? With a much greater proliferation of cheap 020+ accelerators, I could see the case at least getting stronger for 020+ version, when combined with an excellent compiler available, by the time we get to OS3.4+.

The 68k Amiga compiler situation is not so simple. There is continued but sometimes limited support for 68k in Vbcc, GCC, Bebbo's unofficial GCC and Clang/LLVM. Bugs are likely to be fixed but improvements are less common. Hyperion's 68k AmigaOS 3.x, like most of the C= AmigaOS, uses SAS/C which is no longer supported. It is used because of special Amiga support that was added. SAS/C is a solid compiler that is mostly bug free but the front end is primitive by today's compiler standards and the backend is simple. Early 68k support is better than later support for the 68040 and 68060 including poor FPU support for these later CPUs (Lightwave was compiled with SAS/C which ran fine on 68030+68882 but poorly on 68040 and 68060). AmigaOS 4 was upgraded to use GCC even in early alpha/beta versions that still ran on the 68k so it is possible to remove the SAS/C Amiga support although it is likely replaced by GCCisms that are not C standard compliant and GCC has minimal Amiga support which requires some effort to adapt to the Amiga. GCC originally had poor 68k support and code generation but it was replaced by EGCS which was renamed GCC. GCC 2.95.3 through about GCC 3.3 generate some of the best 68k integer code for the Amiga. These early versions of GCC are fast, lightweight and still used for the Amiga but they are not up to date for C standards and lack newer GCCisms. GCC code generation grew worse, the compiler more bloated and bugs were introduced from about 3.4 through 4. The newest versions of GCC are resource hogs but supposedly generating better code again. GCC goes through versions with significant changes quickly which is difficult to keep up with, adapt for the Amiga and know about bugs. GCC is not Amiga friendly even though it is practically a standard for development. The GCC compiler code is a mess which is why Bebbo forked it and tried to make improvements with some success but the changes are now to an older version of GCC and it is doubtful his changes will ever be added to the official GCC. LLVM has relatively new 68k support and I'm not aware of any success for a 68k Amiga target. The LLVM code is more serviceable than for GCC but it is written in C++ which makes it slower than GCC. Vbcc is a nice little niche compiler that has good support for the Amiga and is Amiga friendly. It even has most of the support SAS/C provides and potentially could be updated with other missing SAS/C support. The C compiler front end is surprisingly advanced but the 68k integer backend is simplistic and not much better than SAS/C although it supports more modern 68k CPUs and FPUs better. Vbcc does not support C++ and GCCisms rather preferring to stick to C standards which are more up to date than SAS/C and old versions of GCC but not up to date with modern standards like GCC and LLVM support (Vbcc has good C99 support but little C11 support). Vbcc is supported by Amiga fans and has the potential to become a SAS/C replacement but it is unlikely to be improved for emulation of the 68k. Even 68k cores in FPGAs are unlikely to receive full support as they are limited to relatively small production compared to ASICs and they are a moving target as features and timings can change. Without new 68k ASIC hardware, it is likely that 68k compiler support will continue to decline. Most code is developed and tested under emulation with the goal of working on original hardware rather than being optimized for it. This is EOL compiler support for the 68k and Amiga without higher production hardware than is available currently.

@matthey

As well as the cheap accelerators I mentioned, I forgot about the significant & ever increasing number of V4's (along with others), they all add up.

Quote:

The 68k Amiga compiler situation is not so simple.

Never a truer word spoken, by the looks of it! Vbcc seems the best hope for some improvement; reminds me a bit of the Amiga Web Browser problem … a constantly moving target.

_________________
A1200+Mediator+Voodoo3+040+130mbRAM+0S3.9
A2000+Supra28mhz+9mbRAM+OS3.2.2, CD32 & WinUAE

Tpod Quote:

As well as the cheap accelerators I mentioned, I forgot about the significant & ever increasing number of V4's (along with others), they all add up.

The V4 core may not even be in 10,000 systems. This may be competitive with the entire installed base of PPC AmigaOS 4 systems but it is not enough to attract developers either. THEA500 Mini likely sold enough systems to start to interest developers but they use emulation which compilers generally do not support and have limited general purpose expandability for sales of other software. It's too bad they couldn't swing a custom ASIC like they wanted which should have reduced the production cost thus increasing sales and an ASIC system can be a compiler target. The lack of the AmigaOS and Amiga branding added risk and discouraged better hardware though.

Tpod Quote:

Never a truer word spoken, by the looks of it! Vbcc seems the best hope for some improvement; reminds me a bit of the Amiga Web Browser problem … a constantly moving target.

Mass produced affordable 68k ASIC hardware could solve both problems. Send Dr. Volker Barthelmann (Vbcc) and Chris Young (NetSurf) nice little systems that impress them and they may be inspired to continue their development for the 68k Amiga. There may be motivation for meetings between the AmigaOS developers and vbcc developers and between AmigaOS developers and NetSurf developers to solve problems holding up the projects. The Amiga momentum is currently declining with lack of competitive Amiga hardware sales, Amiga lawsuits and Amiga shenanigans which needs to be turned around before it all dies.

@matthey

You keep ignoring the communities that truly keep m68k support in the tool chains alive.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

kolla Quote:

You keep ignoring the communities that truly keep m68k support in the tool chains alive.

Ignoring 68k Linux/BSD? Not anymore than V4SA and preferably less. The V4SA is usually thought of as a 68k Amiga but it can also be a 68k Atari. It could even use embedded Linux without a MMU but there is minimal support for that from Linux developers. Most want a MMU which would be more practical to provide in an ASIC core than a FPGA core. The Amiga 3000UX is an Amiga with a MMU that supports Unix. Does hardware need a few letters tacked on to keep communities from feeling "ignored"?

Ignoring GNU/GCC? I don't ignore it even though it practically has ignored the Amiga from day one. There has never been an official version of GCC that supports the Amiga out of the box. GCC feels foreign on the Amiga compared to most compilers I know. In my experience, the GCC developers primarily care about the popular architectures (and OSs) and not much for ones like the 68k, which I get the impression they would like to get rid of. Yet, the importance of GCC as practically a standard can't be denied. It is a standard partially because it expands C standards necessitating its use for GCCism compatibility. It has its charm too like compiling completely slop code into a program if at all possible which many programmers have come to expect as part of the GCC standard.

@kolla

Quote:

kolla wrote: @matthey Also, most FPGA systems have the option of setting what CPU to use, typically 68000 and 68020 - it’s darn annoying when OS stops working just because you changed to 68000 CPU to be compatible with some software you wish to run. Likewise on real 68000 Amiga, to have the OS crash because you have a need to remove 020+ acc board for whatever reason. IMO, the OS should _always_ be fully functional on 68000, ThoR has demonstrated how software can detect what CPU it’s running on and load code accordingly.

IMO a 68000 platform can just run the original OSes which were released and the new versions can use at least a 68020.

It's a non-sense continue supporting a 68000 system at the OS level / applications level: take what you already have and enjoy it.

Everything else --> 68020 (or even more) based.

@matthey

Quote:

matthey wrote: Mass produced affordable 68k ASIC hardware could solve both problems. Send Dr. Volker Barthelmann (Vbcc) and Chris Young (NetSurf) nice little systems that impress them and they may be inspired to continue their development for the 68k Amiga. There may be motivation for meetings between the AmigaOS developers and vbcc developers and between AmigaOS developers and NetSurf developers to solve problems holding up the projects. The Amiga momentum is currently declining with lack of competitive Amiga hardware sales, Amiga lawsuits and Amiga shenanigans which needs to be turned around before it all dies.

Unfortunately VBCC is still too much limited. You really need a much modern C AND C++ compiler, which means basically upgrading GCC to better support 68k or switch to LLVM.

@kolla

Quote:

kolla wrote: @matthey You keep ignoring the communities that truly keep m68k support in the tool chains alive.

Then they should not have problems by FINANCING all needed development that this support requires.

cdimauro Quote:

Unfortunately VBCC is still too much limited. You really need a much modern C AND C++ compiler, which means basically upgrading GCC to better support 68k or switch to LLVM.

Embedded C++ was planned for VBCC at one point so new front end languages are possible. It wouldn't take much to surpass the old experimental C++ that was in SAS/C for the Amiga, not that the AmigaOS uses C++. Perhaps you expect VBCC to become the standard Amiga compiler and not just the AmigaOS compiler? My point was that a few VBCC additions could give the missing functionality the AmigaOS uses from SAS/C. VBCC already follows many SAS/C pseudo standards like object file and debugging formats, similar object format naming conventions, SAS/C compatible predefined macros and geta4() support. Some of the SAS/C tools work with VBCC generated executables like the CodeProbe debugger. VBCC is likely the most compatible compiler with SAS/C. VBCC has advantages over SAS/C like active support, more advanced front end, open source and better cross platform support, newer C standards, better assembler with the best 68k peephole optimizer, better support code using optimized assembler inlines and better 68040-68060 CPU and FPU support. The simplistic 68k backend sabotages the effort with the code generation quality not being much better than SAS/C. Besides bug fixes, there isn't much motivation to improve the 68k backend with the 68k Amiga standard becoming emulation of the 68k. There is also not much motivation to optimize the AmigaOS for the same reason.

I believe other compilers are important and deserve support. Every compiler has advantages and disadvantages with tradeoffs. GCC is likely to remain the porting standard and 68k support was updated in newer versions with a bounty. Clang/LLVM 68k support is progressing with an open developer in charge. It's surprising the 45 year old 68k architecture has this much support but it doesn't have much momentum. The same is true of the nearly 40 year old AmigaOS which is blessed to have active development even though momentum is stalling. New mass produced hardware drives development momentum which is what is lacking for the 68k and Amiga.

Last edited by matthey on 15-Apr-2024 at 11:22 PM.

@cdimauro

Quote:

cdimauro wrote: IMO a 68000 platform can just run the original OSes which were released and the new versions can use at least a 68020. It's a non-sense continue supporting a 68000 system at the OS level / applications level: take what you already have and enjoy it. Everything else --> 68020 (or even more) based.

So would I be right in thinking it's been a long time since you used anything less than a 68020 based Amiga? Also if you do or did use such a low spec machine do you think of it as inadequate or just frustratingly slow? If so I don't blame you, but we all use our Amigas differently (plus some of the plain 68000 accelerators are pretty good) & like it or not all Amigas are retro. Its important to remember that Amiga users don't grow on trees!

To quote myself (post #35) -

Quote:

Tpod wrote: The more you try to abandon low spec classic Amiga machines, the more interest & customers you loose. Once they have experienced such an improved OS on these low spec machines I'm sure quite a few folks will go on to upgrade their hardware .

Last edited by Tpod on 15-Apr-2024 at 11:36 PM.

_________________
A1200+Mediator+Voodoo3+040+130mbRAM+0S3.9
A2000+Supra28mhz+9mbRAM+OS3.2.2, CD32 & WinUAE

@matthey

Quote:

matthey wrote: cdimauro Quote: Unfortunately VBCC is still too much limited. You really need a much modern C AND C++ compiler, which means basically upgrading GCC to better support 68k or switch to LLVM. Embedded C++ was planned for VBCC at one point so new front end languages are possible. It wouldn't take much to surpass the old experimental C++ that was in SAS/C for the Amiga, not that the AmigaOS uses C++. Perhaps you expect VBCC to become the standard Amiga compiler and not just the AmigaOS compiler? My point was that a few VBCC additions could give the missing functionality the AmigaOS uses from SAS/C. VBCC already follows many SAS/C pseudo standards like object file and debugging formats, similar object format naming conventions, SAS/C compatible predefined macros and geta4() support. Some of the SAS/C tools work with VBCC generated executables like the CodeProbe debugger. VBCC is likely the most compatible compiler with SAS/C.

Yes, if you need a SAS/C replacement. That should be the way to go.
Quote:

VBCC has advantages over SAS/C like active support, more advanced front end, open source and better cross platform support,

Not that much. Only a few architectures have a good support, but many others not (which includes even the most mainstream ones).

And improving them requires really too much time (sorry, but the quality of the code base isn't that good) that, at the very end, it's better to spend that time to acquire the knowledge to the most important compilers and work with them, instead.
Quote:

newer C standards, better assembler with the best 68k peephole optimizer, better support code using optimized assembler inlines and better 68040-68060 CPU and FPU support. The simplistic 68k backend sabotages the effort with the code generation quality not being much better than SAS/C. Besides bug fixes, there isn't much motivation to improve the 68k backend with the 68k Amiga standard becoming emulation of the 68k. There is also not much motivation to optimize the AmigaOS for the same reason.

But at least it's one of the best 68k compiler/toolchain and it's active. So, it can be improved requiring not that much time for the ones which are already working on it.
Quote:

I believe other compilers are important and deserve support. Every compiler has advantages and disadvantages with tradeoffs. GCC is likely to remain the porting standard and 68k support was updated in newer versions with a bounty. Clang/LLVM 68k support is progressing with an open developer in charge.

Which are the ways to go. My point before was that those compilers are the most complete ones and enable the software to be easily ported or written. It's a must for an architecture for being supported from least one of them.

It's like a modern browser: if you don't have one, then your platform is obsolete by definition. And doomed to fade and disappear.
Quote:

It's surprising the 45 year old 68k architecture has this much support but it doesn't have much momentum.

LLVM's backend is still experimental and isn't suggested to be used in production (at least 'til some months ago, when I've checked it).

For GCC I've no idea, but if Bebbo's fork of the old version (6.5?) generates the best 68k code, then it's a no go: those changes should be upstreamed and merged to the master, for the above reasons (no modern compiler -> obsolete platform).
Quote:

The same is true of the nearly 40 year old AmigaOS which is blessed to have active development even though momentum is stalling.

Well, active development is a big word: they continue to slightly evolve the same obsolete OS architecture and, in general, platform.

As I've said, you need a modern compiler. Which one is supported by AmigaOS 3.2?
Quote:

New mass produced hardware drives development momentum which is what is lacking for the 68k and Amiga.

Here I disagree: it should be enough to have mass produced systems.

Producing software for them requires updated toolchains, despite the hardware under the wood is running native or emulated 68k code. As a developer, you need something to support 68k platforms, and that should be enough.