@Tpod

Quote:

Tpod wrote: @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?

I have no Amiga since long time (1996: when the video output of my beloved 1200 got broken), but yes: 68020 was the last processor and I don't step back from it.

After my 1200 I use WinUAE and here my Amiga system is configured as 68030 + 68882, which offers the best compatibility with the existing software (to me it's a non-sense configuring it as 68040 or 68060, since there are only problems with those processors and no advantage under emulation).
Quote:

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!

Sure, and what's the problem with using a 68000 system as it is, with the existing software which was created for it?

My point is: do you want some new software? Then consider to upgrade to at least a 68020, because developers cannot be forced to support a super obsolete system like a 68000.

It's like asking support for an 8086 when the baseline systems for PCs is represented by an 80386 since end of 80s: it's a non-sense.
Quote:

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 .

Those folks can directly go for new, more advanced hardware.

cdimauro Quote:

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.

I think the VBCC code quality is fine. Dr. Volker Barthelmann is highly knowledgeable about compilers and C standards. The code readability of the Dr. could certainly be improved and the real problem is what is missing.

cdimauro Quote:

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

For all Bebbo's work, the effort may do nothing to improve GCC. After criticizing the code quality of VBCC, GCC code is complex and more difficult to work with. I'm not the most experienced programmer but I was able to make meaningful contributions to VBCC like 68k FPU support code improvements, added and improved 68k assembler inlines and macros, added header files for improved C99 support, vasm peephole optimization suggestions, bug fix reports, etc. Bebbo is likely a more experienced programmer than me. Granted, I did not try to tackle the 68k backend or a 68k instructions scheduler which is more difficult even though I looked into them.

cdimauro Quote:

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?

Hyperion 68k AmigaOS has more core development work than AmigaOS 3.5-3.9 which added more 3rd party contributions that didn't integrate as well. I like the development direction and philosophy of the current developers better even though I haven't tried it because I refuse to support Hyperion. One place where Hyperion 68k AmigaOS and AmigaOS 3.9 diverge is support for low end vs high end hardware. AmigaOS 3.9 requires a 68020, 6MiB of memory, hard drive and is targeted at RTG systems. This did leave a significant percentage of Amiga users behind but offered improved performance for higher spec users. More Amiga users likely use higher end systems today than when AmigaOS 3.9 was released yet a 68000 is the minimum requirement for Hyperion's 68k AmigaOS. The AmigaOS is modular and scalable. I doubt it would be much more difficult to offer both a 68000 and 68020 version (likely compiled for 68060 so no trapped instructions and instruction scheduling for a 68060 not that it is available).

cdimauro Quote:

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.

If most targets use emulation, the compiler developers will not waste time improving code generation other than fixing bugs. Performance varies with the host hardware and emulator version when using emulation making performance improvements from code unpredictable. Code simplification and code density improvements should provide some performance benefits even for emulation but performance is more dependent on upgraded hardware and emulation optimizations.

cdimauro Quote:

I have no Amiga since long time (1996: when the video output of my beloved 1200 got broken), but yes: 68020 was the last processor and I don't step back from it. After my 1200 I use WinUAE and here my Amiga system is configured as 68030 + 68882, which offers the best compatibility with the existing software (to me it's a non-sense configuring it as 68040 or 68060, since there are only problems with those processors and no advantage under emulation).

The 68040 introduced FSop and FDop FPU instructions which are used by compilers. GCC code compiled for the 68040 or 68060 will usually generate these instructions although VBCC will not (GCC chooses single and double precision IEEE result consistency while VBCC retains more precision which is also IEEE compatible). For this reason, a WinUAE 68040 with 68882 support code (no traps) may be preferable. Maybe WinUAE has an option to add FSop and FDop support code to 68030+68882 too?

cdimauro Quote:

Sure, and what's the problem with using a 68000 system as it is, with the existing software which was created for it? My point is: do you want some new software? Then consider to upgrade to at least a 68020, because developers cannot be forced to support a super obsolete system like a 68000. It's like asking support for an 8086 when the baseline systems for PCs is represented by an 80386 since end of 80s: it's a non-sense.

Code for the 16 bit 68000 is likely better performance on 32 bit 68k CPUs than 16 bit 8086 code on 32 bit x86 CPUs. This is mostly due to the 32 bit ISA. Address register writes are always 32 bit which is a big advantage. The 68000 still has no 32x32=32 multiply, no barrel shifter, practically no pipelining, no caches and 16 bit integer datatypes are preferred (resulting in partial register writes in data registers and no result forwarding on the 68060). Sometimes the 68000 will use a memory wasting lookup table or a fat function to replace a single 68020+ instruction but other times it performs surprisingly well.

https://mikro.naprvyraz.sk/docs/Optimize/68OPT.TXT

The guide linked above makes 68000 code sound better than it really is on later 68k CPUs. In my experience, it is much easier to optimize for 68020-68060 than 68000-68060. It would be even easier if the 68060 had left the 64 bit MUL and DIV instructions as 68020, 68030 and 68060 optimization would be very close with the addition of 68060 instruction scheduling.

cdimauro Quote:

Those folks can directly go for new, more advanced hardware.

Provided there is adequately advanced, affordable and competitive enough 68k hardware, most Amiga users could finally stop using their old 68000 hardware. Emulation of the 68k comes the closest to "advanced" but this is not 68k Amiga hardware and does not attract developers as it is EOL.

Last edited by matthey on 16-Apr-2024 at 11:03 PM.

@cdimauro

Sorry to hear about your 1200; I went WinUAE only, for a while after I was a bit with my A2000's CPU socket (bent one single pin socket which was enough to make it unreliable). WinUAE was a very good stopgap, until I got the 2000 out of the loft 2 years later & successfully used a dental pick to bend the connector back!

Being a WinUAE only user all those years & having an A1200 before is bound to have an influence on your views of a sensible minimum. I don't think it would be a great move going 020+ but I see where you (& others) are coming from.

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

During the lifetime of this thread, Bebbo has put together the first modern incarnation of ssh for 68k Amiga.

And guess what - he made sure it also works on 68000.

Last edited by kolla on 17-Apr-2024 at 11:33 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@matthey

Quote:

matthey wrote: cdimauro Quote: 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. I think the VBCC code quality is fine. Dr. Volker Barthelmann is highly knowledgeable about compilers and C standards. The code readability of the Dr. could certainly be improved and the real problem is what is missing.

Which is also a lot, and that's another problem.
Quote:

cdimauro Quote: 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. ... 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). For all Bebbo's work, the effort may do nothing to improve GCC. After criticizing the code quality of VBCC, GCC code is complex and more difficult to work with.

Yes, GCC is much more difficult and complex, but there's also A LOT of documentation, books, blogs, etc., which help understanding and working on it. Same for LLVM (which is much better from this PoV, albeit using C++ makes it hard to write code for/with it).
Quote:

I'm not the most experienced programmer but I was able to make meaningful contributions to VBCC like 68k FPU support code improvements, added and improved 68k assembler inlines and macros, added header files for improved C99 support, vasm peephole optimization suggestions, bug fix reports, etc.

Right, but it's also because 68k has the best support and many things are already there.

Now take x86 (not even x64) and try to bring it at the same level of 68k: even just updating vasm takes considerable time.
Quote:

Bebbo is likely a more experienced programmer than me. Granted, I did not try to tackle the 68k backend or a 68k instructions scheduler which is more difficult even though I looked into them.

It's difficult even for GCC and LLVM.

However, the thing is that both are modern compilers that bring all new standards. So, time is well spent here, because you get back modern tools, which is my point.
Quote:

cdimauro Quote: 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? Hyperion 68k AmigaOS has more core development work than AmigaOS 3.5-3.9 which added more 3rd party contributions that didn't integrate as well. I like the development direction and philosophy of the current developers better even though I haven't tried it because I refuse to support Hyperion. One place where Hyperion 68k AmigaOS and AmigaOS 3.9 diverge is support for low end vs high end hardware. AmigaOS 3.9 requires a 68020, 6MiB of memory, hard drive and is targeted at RTG systems. This did leave a significant percentage of Amiga users behind but offered improved performance for higher spec users.

Which is OK, since you can't stick developers to very old platforms: it's called evolution. The hardware evolves and software supports it, whereas the old one fades and isn't supported anymore.
Quote:

More Amiga users likely use higher end systems today than when AmigaOS 3.9 was released yet a 68000 is the minimum requirement for Hyperion's 68k AmigaOS. The AmigaOS is modular and scalable. I doubt it would be much more difficult to offer both a 68000 and 68020 version

The main problem that I see is that a large part of the code is still written in assembly.

As long as you use C/C++, generating optimized binaries for specific hardware platforms should be very easy. Especially for the Amiga OS, which has a very small footprint. But this requires a bit of time from the developers, of course, and... testing.
Quote:

(likely compiled for 68060 so no trapped instructions and instruction scheduling for a 68060 not that it is available).

Why? This way you're crippling the 68020 systems, which needs more performance.

68060 is already MUCH faster and the trapping penalty can be easily absorbed during the execution of all other code.

For this reason the second supported platform should be the 68020.
Quote:

cdimauro Quote: 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. If most targets use emulation, the compiler developers will not waste time improving code generation other than fixing bugs. Performance varies with the host hardware and emulator version when using emulation making performance improvements from code unpredictable. Code simplification and code density improvements should provide some performance benefits even for emulation but performance is more dependent on upgraded hardware and emulation optimizations.

You got me wrong: I was talking about the development platform.

Think about the consoles: developing software for them is usually done on... PCs! NOT using the consoles' hardware themselves.

Developers should use (very) comfortable environments when they need to work. Their time is the most valuable one.

This clarified, even using a PC you can always address the issues that you mentioned. Checking (and testing!) the code generation shouldn't be a problem, as well as checking the performance improvements. Again, this happens even on consoles which have different hardware from the development platform.
Quote:

cdimauro Quote: I have no Amiga since long time (1996: when the video output of my beloved 1200 got broken), but yes: 68020 was the last processor and I don't step back from it. After my 1200 I use WinUAE and here my Amiga system is configured as 68030 + 68882, which offers the best compatibility with the existing software (to me it's a non-sense configuring it as 68040 or 68060, since there are only problems with those processors and no advantage under emulation). The 68040 introduced FSop and FDop FPU instructions which are used by compilers. GCC code compiled for the 68040 or 68060 will usually generate these instructions although VBCC will not (GCC chooses single and double precision IEEE result consistency while VBCC retains more precision which is also IEEE compatible).

It depends also on how much software is compiled for using such 68040 instructions. And don't forget that this processor is lacking an important FP instruction (conversion to int).
Quote:

For this reason, a WinUAE 68040 with 68882 support code (no traps) may be preferable. Maybe WinUAE has an option to add FSop and FDop support code to 68030+68882 too?

When I select 68040 it's not possible to select 68881 or 68882 for the FPU.

However, there's "Unimplemented FPU emu" which, as I understood, should emulate all missing FPU instructions, which is also selected for my 68030 configuration (so, FSop and FDop should be emulated -> no trap generated).

For this reason I still prefer to use 68030 as the base config, because it doesn't require loading external libraries for better supporting the processor (whereas 68040 and 68060 requires it).

Which IMO should be the best decision, since I doubt that's so much Amiga software which has a dynamic code dispatcher depending on the detected FPU. Usually you have binaries compiled for specific ISAs, and if I execute ones for 68040 or 68060, they should work (never tried) despite the emulated processor is a 68030.
Quote:

cdimauro Quote: Sure, and what's the problem with using a 68000 system as it is, with the existing software which was created for it? My point is: do you want some new software? Then consider to upgrade to at least a 68020, because developers cannot be forced to support a super obsolete system like a 68000. It's like asking support for an 8086 when the baseline systems for PCs is represented by an 80386 since end of 80s: it's a non-sense. Code for the 16 bit 68000 is likely better performance on 32 bit 68k CPUs than 16 bit 8086 code on 32 bit x86 CPUs. This is mostly due to the 32 bit ISA. Address register writes are always 32 bit which is a big advantage.

Yes, that's the clear advantage: 8086 and 80386 are effectively different processors/ISAs.
Quote:

The 68000 still has no 32x32=32 multiply, no barrel shifter, practically no pipelining, no caches and 16 bit integer datatypes are preferred (resulting in partial register writes in data registers and no result forwarding on the 68060). Sometimes the 68000 will use a memory wasting lookup table or a fat function to replace a single 68020+ instruction but other times it performs surprisingly well. https://mikro.naprvyraz.sk/docs/Optimize/68OPT.TXT The guide linked above makes 68000 code sound better than it really is on later 68k CPUs. In my experience, it is much easier to optimize for 68020-68060 than 68000-68060. It would be even easier if the 68060 had left the 64 bit MUL and DIV instructions as 68020, 68030 and 68060 optimization would be very close with the addition of 68060 instruction scheduling.

This nice guide also shows why optimizing should be done for specific processors. Which is something which cannot be made anymore when there's assembly code involved, since it takes too much effort.

Having high-level compilers which are able to take all this burden is the only reasonable way, as I've said above.
Quote:

cdimauro Quote: Those folks can directly go for new, more advanced hardware. Provided there is adequately advanced, affordable and competitive enough 68k hardware, most Amiga users could finally stop using their old 68000 hardware.

But... there is! Even the cheapest FPGA project offers a 68020 core, AFAIK (kolla?).
Quote:

Emulation of the 68k comes the closest to "advanced" but this is not 68k Amiga hardware and does not attract developers as it is EOL.

There's still development for several platforms which are officially died. I don't see a problem here. You can take a look at EAB and how many people still like to do not only Amiga, but assembly coding.

The lack of hardware doesn't stop them, albeit I understand your point.

But this is a very difficult thing to achieve, unfortunately. Unless a benefactor comes in.

P.S. No time to read, sorry. I've only some mins to reply to some other comment.

@Tpod

Quote:

Tpod wrote: @cdimauro Sorry to hear about your 1200; I went WinUAE only, for a while after I was a bit with my A2000's CPU socket (bent one single pin socket which was enough to make it unreliable). WinUAE was a very good stopgap, until I got the 2000 out of the loft 2 years later & successfully used a dental pick to bend the connector back! Being a WinUAE only user all those years & having an A1200 before is bound to have an influence on your views of a sensible minimum. I don't think it would be a great move going 020+ but I see where you (& others) are coming from.

@kolla

Quote:

kolla wrote: During the lifetime of this thread, Bebbo has put together the first modern incarnation of ssh for 68k Amiga. And guess what - he made sure it also works on 68000.

I don't see the problem. If Bebbo likes and has the time to still support 68000s, at the end it's his decision.

But this requires effort. And time is the only thing that you can't buy on the shop under the corner...

@cdimauro

Quote:

@kolla Quote: kolla wrote: During the lifetime of this thread, Bebbo has put together the first modern incarnation of ssh for 68k Amiga. And guess what - he made sure it also works on 68000. I don't see the problem. If Bebbo likes and has the time to still support 68000s, at the end it's his decision.

And likewise for Roadshow, the OS and lots more.

It almost seems "trendy" to ensure support for 68000 these days, and considering how the plain 68000 is the most accurately synthesised 68k, and currently the most available 68k, this makes totally sense IMO.

Quote:

But this requires effort. And time is the only thing that you can't buy on the shop under the corner...

Efforts put into better support for slower systems is more often than not also very beneficial for faster systems.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@cdimauro

Quote:

But... there is! Even the cheapest FPGA project offers a 68020 core, AFAIK (kolla?).

But not all FPGA projects use softcore CPU in the FPGA, some use real ASIC 68000 chips, like the original Minimig and it's various variants and revisions.

But yes, those projects that use softcore CPU typically use TG68 which does have a 68020 option (MiST, SiDi, FleaFPGA etc), or they use Fx68k for 68000 and TG68 for 68020 (MiSTer).

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@cdimauro

Quote:

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

That's mighty impractical - we have systems with _both_ 68000 and 68020+ CPUs installed, and which one is used at any given time can depend on many factors.

Quote:

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.

Luckily, very few (if any) of relevant programmers, coders and software developers think like you. Just about all aspects of the OS that truly benefit on 020+ optimisation already is optimised. No OS developers have any wish to hand-optimise components for this and that CPU with assembler anymore anyways.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Tpod

Quote:

So would I be right in thinking it's been a long time since you used anything less than a 68020 based Amiga?

If you ask me, it's been a mighty long time since he's actually used _any_ Amiga.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Asking for 020 plus optimized binaries (where applicable)
is not pushing that 00 support should be dropped.

Best of late Amiga tradition was that binaries for several CPU archs (00,020,030, 040 FPU ...)
where commonly available.

_________________
Future Acube and MOS supporter, fi di good, nothing fi di unprofessionals. Learn it harder way!

cdimauro Quote:

Which is also a lot, and that's another problem.

VBCC has a lot of tools missing but it gains a small, portable and dependency free code base in return. I was able to develop on my 68060 Amiga including building the whole VBCC distribution. VBCC targets embedded systems so this is a deliberate feature. Granted, it would be nice to have a few more basic tools but most cross platform CLI only tools are limited, especially in user friendliness.

cdimauro Quote:

It's difficult even for GCC and LLVM. However, the thing is that both are modern compilers that bring all new standards. So, time is well spent here, because you get back modern tools, which is my point.

GCC has a very old code base with many incremental and patch changes to go along with any major new and modern changes. One of the reasons Clang/LLVM was created was because of the condition of GCC code and it is not new anymore. VBCC is newer and has many of the optimizations that GCC and LLVM have and even some they don't have. It is targeted at embedded where some of the heaviest optimizations may be skipped but it is not much. For example, VBCC has the optimization to convert (compress) 68k fp constants from extended to double to single precision which GCC does not perform while it does not have the magic number generator to convert division by a constant using 32x32=64, shifts and adds, even though I wrote about as small of C code as possible to generate the emitted code hoping it would be added by the 68k backend.

cdimauro Quote:

The main problem that I see is that a large part of the code is still written in assembly. As long as you use C/C++, generating optimized binaries for specific hardware platforms should be very easy. Especially for the Amiga OS, which has a very small footprint. But this requires a bit of time from the developers, of course, and... testing.

I don't think that much of the AmigaOS is written in 68k assembly code anymore, the exec.library, graphics.library and FFS being exceptions. There may be C backported versions available to Hyperion 68k AmigaOS although they may not be compatible enough. Compiling for a particular CPU model, may not beat assembly code for 68000-68020. As I recall, most AmigaOS assembly code looked like it was optimized for the 68000 and never updated. Some was low quality and C code may outperform.

cdimauro Quote:

Why? This way you're crippling the 68020 systems, which needs more performance. 68060 is already MUCH faster and the trapping penalty can be easily absorbed during the execution of all other code. For this reason the second supported platform should be the 68020.

Maybe. The main difference with a compiler between a 68020 and 68060 target using integer only code is the 64 bit result MUL and DIV. A 68060 target already gives full 32 bit versions of MUL and DIV. There is unlikely to be many 64 bit result MUL and DIV instructions except for maybe a 64 bit file system. With a 68020 target, some compilers like GCC will use a 64 bit result MUL to convert division by a 32 bit constant using the magic number optimization. This is what made removing 32x32=64 from the 68060 one of the biggest mistakes of the 68060 as GCC was already using this valuable optimization. Granted, SAS/C and VBCC do not currently perform this optimization. The last version of SAS/C barely has 64 bit support at all where VBCC C99 64 bit support is mostly complete (my understanding is that SAS/C 6.58 does not have long long which was introduced in 7.x).

AmigaOS early startup would not be able to use trapped instructions before the CPU library trap handlers are installed. Specifying a 68020-68060 target with GCC may still use trapped instructions. Specifying a 68020 target may not schedule code for the 68060, if available.

cdimauro Quote:

When I select 68040 it's not possible to select 68881 or 68882 for the FPU. However, there's "Unimplemented FPU emu" which, as I understood, should emulate all missing FPU instructions, which is also selected for my 68030 configuration (so, FSop and FDop should be emulated -> no trap generated). For this reason I still prefer to use 68030 as the base config, because it doesn't require loading external libraries for better supporting the processor (whereas 68040 and 68060 requires it). Which IMO should be the best decision, since I doubt that's so much Amiga software which has a dynamic code dispatcher depending on the detected FPU. Usually you have binaries compiled for specific ISAs, and if I execute ones for 68040 or 68060, they should work (never tried) despite the emulated processor is a 68030.

Either 68030 or 68040 emulation should be fine if unimplemented FPU emulation works for the 68030+68882 too. Sometimes the CPU compile target is not given for software or is hidden in the manual. The Warp3D Avenger (Voodoo 3) libraries are a good example which require a 68040 as GCC uses FSop and FDop instructions. I converted them all to Fop instructions when I was fixing other bugs for the few users using a 68030+6888x. This was easier than replacing the frequent, long and ugly 68040 code for FINTRZ with FINTRZ.

cdimauro Quote:

There's still development for several platforms which are officially died. I don't see a problem here. You can take a look at EAB and how many people still like to do not only Amiga, but assembly coding. The lack of hardware doesn't stop them, albeit I understand your point. But this is a very difficult thing to achieve, unfortunately. Unless a benefactor comes in.

Dead compiler targets are mostly fading away before removal as the cob webs infest the minimal support. There may be some intermediate code and byte code compiler targets but they exist for living hardware. Emulation of dead hardware is EOL.

No benevolent benefactors can come in as a malevolent benefactor has made the Amiga uninvestable with over 20 years of malfeasance and failure.

Last edited by matthey on 19-Apr-2024 at 06:57 PM.

@vox

Quote:

vox wrote: @kolla Asking for 020 plus optimized binaries (where applicable) is not pushing that 00 support should be dropped.

Well, dropping 68000 support is exactly what cdimauro suggests.

Quote:

Best of late Amiga tradition was that binaries for several CPU archs (00,020,030, 040 FPU ...) where commonly available.

Yes, where it makes sense. And the OS already does this, that's why every kickstart for the various models have different variants of exec.library, and the disk based components - where it makes sense - are detecting CPU type on load and use appropriate code (math libs, and from what I recall, datatypes)

And for those who insist, there's plenty of third party options like half a dozen CopyMem/CopyMemQuick patches, PeterK's icon.library (which also does a lot, lot more) etc.

Most of the OS components are typically idling, only used every now and then, and doesn't make any sense to optimise in the first place. From what I have seen both from "fresh" OS install and from how people set up their systems, optimised OS binaries is really the least of their worries... people should be more mindful about the implications of resident commands, how to make good use of it and avoid disk access - we're maybe not on floppies anymore, but avoiding disk I/O is still a good thing! Do we want a situation where you need a 060 to be able to read the filesystem of a disk that was formatted with a 060 optimised filesystem in RDB? I don't think so!

IMO, the "weakest link" is Workbench, it sorely needs some rethinking, not just nilly-willy porting random "neat" features back from OS4. The ARexx port is super slow (always was), and if you tell it to "quickly" remove and add menus, you easily end up with a "hung" WB. The ReAction based ASyncWB and RAWBInfo doesn't really add much "optimisation", having the library path scanned for BOOPSI classes every time you do some file operation with WB shouldn't be necessary.

Last edited by kolla on 19-Apr-2024 at 08:43 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

kolla Quote:

During the lifetime of this thread, Bebbo has put together the first modern incarnation of ssh for 68k Amiga. And guess what - he made sure it also works on 68000.

Let's take a closer look at the work Bebbo may have done.

https://aminet.net/package/comm/net/amigassh Quote:

* optimized, modified to use 16 bit integers by Stefan "Bebbo" Franke

Usually a 16 bit CPU uses 16 bit integers which is usually the most efficient. The 16 bit 68000 ISA was 32 bit, at least for the time. It lacks 32x32=32 and 32/32=32 but at the time, and well into the RISC era, most CPUs lacked hardware MUL and DIV instructions (early ARM, MIPS, etc.). Some compiler developers could see that most later 68k CPUs would be 32 bit though and chose to make integers 32 bit sacrificing some performance on the 68000 for the future. SAS/C, Lattice early in life, chose 32 bit integers where Manx and some other early compilers chose 16 bit integers. SAS/C was adopted as a pseudo standard on the Amiga and the Amiga standard became 32 bit integers. The AmigaOS uses AmigaOS defined WORD, LONG and APTR datatypes so either C integer size is possible with the Amiga.

http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_3._guide/node0654.html

A 32 bit integer size is more standard for Amiga code and is the default for VBCC 68k Amiga targets (Atari 68000 target uses 16 bit integers) and unofficial GCC 68k Amiga targets. It looks like Bebbo changed the integer size to 16 bit integers to improve 68000 performance at the expense of 68020+ performance with half the performance or less expected where two 16 bit integers replace one 32 bit integer (at least two 16 bit operations are needed for each 32 bit operation). It may be possible to select 16 bit integers with a 68000 target and use 32 bit integers with a 68020+ target which would give the best of both worlds, if separate 68000 and 68020+ executables are available or sources are available to build any target desired.

It looks like there were 16 bit integer fixes. The minimum size of a C integer datatype is 16 bits so these should not be necessary but programmers often don't do testing for this and many don't care anyway as 32 bit and 64 bit datatypes are more common today for compiled code. If 16 bit integers are too small, C99 int_fast32_t would be a better datatype to use but the SSH code looks old and does not appear to use C99 datatypes.

https://github.com/bebbo/sftp4tc/blob/master/PuttyLib/putty/ssh.c

The code is pretty and perhaps he or the developers didn't want to change datatypes so he chose 16 bit integers instead and fixed 16 bit integer support which the developers hopefully accept.

https://aminet.net/package/comm/net/amigassh Quote:

* fixed some bus errors, now it really runs on 68000

These are likely odd mem loads or stores that require more code for the 68000 and are a pain to fix. In some cases, whole algorithms must be changed with a considerable code increase. This is why unaligned loads and stores are now mostly standard even though many RISC CPUs after the 68000 did not support unaligned loads and stores. The 68020+ helped set the standard of supporting unaligned loads and stores.

https://aminet.net/package/comm/net/amigassh Quote:

* enhanced C code with some asm statements

This is kind of a strange way of saying 68k assembly code was used. Neither did I find it but the project is large and I didn't search long. Even with an enhanced version of GCC to output better optimized code, assembly code is still out performing compiled code which is no surprise to me. The assembly code is likely optimized for 16 bit integers too although it would be possible to have separate 32 bit versions for the 68020+. VBCC uses separate 68000, 68020 and 68060 assembly inlines when needed.

kolla Quote:

And likewise for Roadshow, the OS and lots more. It almost seems "trendy" to ensure support for 68000 these days, and considering how the plain 68000 is the most accurately synthesised 68k, and currently the most available 68k, this makes totally sense IMO.

Cycle exact 68000 FPGA simulation is more important for early 68000 Amiga software (and often more important for other 68k based hardware). Later Amiga software for 68020+ hardware relied less on timing as timing ranges varied more with different CPUs and chipsets.

kolla Quote:

Efforts put into better support for slower systems is more often than not also very beneficial for faster systems.

Not necessarily as the example with SSH switching to 16 bit integers for the 68000 may demonstrate which is likely to decrease performance program wide for the 68020+.

kolla Quote:

Luckily, very few (if any) of relevant programmers, coders and software developers think like you. Just about all aspects of the OS that truly benefit on 020+ optimisation already is optimised. No OS developers have any wish to hand-optimise components for this and that CPU with assembler anymore anyways.

I expect the 68020+ optimization level is poor for the Hyerpion AmigaOS. The saving grace is that the AmigaOS is lightweight. Nobody is worried about the performance and size of the AmigaOS because it is EOL like 68k compiler support. Anyone that cares would quickly become frustrated by others that don't want to waste time for a dead platform. This is why most new Amiga software is a solo effort today. There is maybe another 10 years of Amiga life without proliferation from new hardware and users making any new software effort less and less worthwhile.

kolla Quote:

Yes, where it makes sense. And the OS already does this, that's why every kickstart for the various models have different variants of exec.library, and the disk based components - where it makes sense - are detecting CPU type on load and use appropriate code (math libs, and from what I recall, datatypes) And for those who insist, there's plenty of third party options like half a dozen CopyMem/CopyMemQuick patches, PeterK's icon.library (which also does a lot, lot more) etc.

We want to get away from the AmigaOS patch fest and toward a more enhanced AmigaOS without the need for patches. A more optimized AmigaOS would help but there are other priorities as well. I say this having written a Copymem patch that provides a ~35% performance improvement on the 68060 compared to AmigaOS 3.9 CopyMem() and CopyMemQuick() which required a 68020 and should have been optimized for the 68020.

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

I also helped PeterK a tiny bit with his icon.library. He uses my enhanced version of ADis as one of his development tools too. We want enhancements like these patches but we want them integrated and as standard as a modular AmigaOS allows.

kolla Quote:

Most of the OS components are typically idling, only used every now and then, and doesn't make any sense to optimise in the first place. From what I have seen both from "fresh" OS install and from how people set up their systems, optimised OS binaries is really the least of their worries... people should be more mindful about the implications of resident commands, how to make good use of it and avoid disk access - we're maybe not on floppies anymore, but avoiding disk I/O is still a good thing! Do we want a situation where you need a 060 to be able to read the filesystem of a disk that was formatted with a 060 optimised filesystem in RDB? I don't think so!

Some people need or want a 68000 compatible AmigaOS, mostly 68000 OCS/ECS hardware owners. Most other Amiga users including 68020+AGA based, Amiga 3000(T)-4000(T), FPGA based hardware and emulation Amiga users could benefit from more performance and lower memory usage. The best option would be for the AmigaOS to be capable of compiling for any 68k CPU target and for Amiga users to be able to download it and compile it for themselves. I'm surprised you haven't been advocating for an open source AmigaOS. Wouldn't it be possible to have one "official" AmigaOS and still have it be open source?

kolla Quote:

IMO, the "weakest link" is Workbench, it sorely needs some rethinking, not just nilly-willy porting random "neat" features back from OS4. The ARexx port is super slow (always was), and if you tell it to "quickly" remove and add menus, you easily end up with a "hung" WB. The ReAction based ASyncWB and RAWBInfo doesn't really add much "optimisation", having the library path scanned for BOOPSI classes every time you do some file operation with WB shouldn't be necessary.

Improved algorithms are the way to go before "premature" optimization, as ThoR would say. I find it useful to look at the disassembled output to see what could use improvement starting at an early stage of development though.

Last edited by matthey on 19-Apr-2024 at 10:08 PM.

@matthey

Well, I totally agree with ThoR on these things.

https://eab.abime.net/showpost.php?p=1409491&postcount=12

Of course I advocate for open sourcing the OS sources, but what’s the point of doing it here?

I’ve used copymem/copymemquick patches (CopyMemAIO lastly) and though benchmark scores showed great improvements, I didn’t notice much or anything, aside from some unwanted side effects with certain software (iirc, PPaint got more “sluggish�) When is copying memory so important anyways? Isn’t the Amiga way to pass pointers around instead?

Last edited by kolla on 19-Apr-2024 at 11:42 PM.
Last edited by kolla on 19-Apr-2024 at 11:41 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

kolla Quote:

Well, I totally agree with ThoR on these things. https://eab.abime.net/showpost.php?p=1409491&postcount=12

ThoR is a good developer and very smart but also eccentric. Other developers have showed that SAS/C 68000 compiled AmigaOS code is sometimes far from optimal on newer 68k CPUs. There is a trade off of project manageability including testing and debugging vs performance in some cases which usually results in the loss of some performance.

MOVE16 should not be used by default even on 68040 and 68060 Amigas because of buggy 68040s and accelerators. The MOVE16 performance advantage is clear for copying a whole cache line at a time including avoiding loading cache lines from memory for a copyback cache line partial cache write and not flushing the cache on large copies. However, the instruction is too CPU specific as it assumes the cache line size is 16 bytes where most CPUs use at least a 32 byte cache line size today and modern multi-level caches are more efficient by loading partial cache lines from higher level caches. It is good that MOVE16 is avoided by compilers and most programs by default. It would be possible to have more generic and future proof instructions like LMOV size,src,dst and LSET value,size,dst but they may be more difficult for CPU architects/developers to support.

kolla Quote:

Of course I advocate for open sourcing the OS sources, but what’s the point of doing it here?

The end of Hyperion may be a new opportunity for the AmigaOS to become at least partially open source. Amiga Corporation seems to be more open to the idea and negotiated with Hyperion for the updated 68k AmigaOS to be available for free.

The Raspberry Pi Foundation is the spiritual successor of Acorn Computers. They have supported the RISC OS which was already open source but likely proliferated due to RPi hardware and their support. The RPi Foundation, including subsidiaries, had a 2022 income of £157.3m using mostly open source OSs.

https://static.raspberrypi.org/files/about/RaspberryPiFoundationAnnualReview2022.pdf

The RPi Foundation proliferation tactic seems like a better pattern than the Trevor and Ben nefarious clenched fist hide the AmigaOS away for decades until everything Amiga related is dead tactic. It looks like the RPi Foundation income is primarily from their RPi Limited subsidiary producing competitive hardware, not that they need to be a nonprofit to produce competitive hardware.

kolla Quote:

I’ve used copymem/copymemquick patches (CopyMemAIO lastly) and though benchmark scores showed great improvements, I didn’t notice much or anything, aside from some unwanted side effects with certain software (iirc, PPaint got more “sluggish�) When is copying memory so important anyways? Isn’t the Amiga way to pass pointers around instead?

Most of the CopyMem() and CopyMemQuick() memory copies are small. Many of the tiny calls would be better off with their own inline MOVE instructions instead of calling the functions with their function call overhead, especially on the 68020+ where odd memory accesses are never a problem. Yes, 68000 support could be reducing 68020 performance even if we had both 68000 and 68020 compiles although it would be possible to conditionally call the functions for the 68000 only. There are many small CopyMem() and CopyMemQuick() memory copies which a Snoopy like utility can record but the file will grow quickly consuming memory or hard disk space which may run out in seconds for memory. Large copies are unusual and one of the reasons why MOVE16 memory copies are highly unlikely to make any performance difference. One of the largest memory copies I have seen is with newer versions of AWeb which performs a copy when scrolling and which the 68060 CopyMem patch made a noticeable different in scrolling performance on my system. CopyMem patches should never cause what you describe as “sluggish� behavior on a real 68k CPU if you use the correct version. A non-cycle exact 68k FPGA CPU core may have unknown timing and emulation has unknown and variable timing which is practically impossible to optimize the code for.

Last edited by matthey on 20-Apr-2024 at 07:22 PM.