Quote:

Kronos wrote: To compile for 68000 or 68020 is the question of where your target is 3.14 and 3.2 exist in a time when plenty 68000s are of the fake kind and is looking backwards (aka 100% retro). 3.5/3.9 were done to run on real Amigas trying to stay relevant against Win/MacOS.

3.5 / 3.9 had some TCP/IP and RTG software and (AFAIK) even browsers that wouldn't run on an ECS Amiga with 8MHz and 8MB Ram.

Compiling software for 68000 could still make sense, because it is the absolute minimum even if the software made no sense on a 8MHz / 8MB system.

There where some discussion in the Natami Forum why an FPGA 68k should at least have 68020 compatibility, it's needed because many power hungry software was never compiled for 68000 only. At the other side a 68000 compatible core might be easier to build and might run on smaller FPGAs.

@kolla

Quote:

kolla wrote: 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.

There are some 68020 addressing modes that are very useful for tables (array of structs ?), the main benefit is the size of loops handling this. On an compiler this was just an option they selected.

@OneTimer1

Sure thats why I made a clear distinction between then and now. But....

If you were to make a pure 68000 in FPGA you would either target it at "just run some old OCS games at lowest possible cost" and not as useable Amiga capable of running applications.

Hence no need for OS3.anything or 100s of MHz.

If you would still do such a thing you would soon run into memory limitations.


-> 68000 support only makes sense if your product looks backwards.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

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.

Results will vary. There are places where 68020 optimizations are not needed and there is no performance improvement. There are other places where performance will be more than doubled. More modern CPU cores and better compilers will generally provide larger gains. Some compilers fail to do some 68020 optimizations with 68020 optimizations enabled. See the CoreMark thread above where GCC even fails to do normal common CISC optimizations. The AC68080 is expected to execute 68000 code without 68020 optimizations, without basic CISC optimizations, without ColdFire optimizations and without core specific superscalar instruction scheduling even though it could benefit from these optimizations. Then it is compared to modernized ColdFire and RISC-V benchmark results. Compatibility is important but ancient 68000 code is one of the reasons why the 68k is considered a low performance ISA when it is the opposite (another reason is ancient silicon and the use of FPGA simulation and emulation). Try executing 8086 code on a P5 Pentium or ARM2 code on a Cortex-A53 and these more modern cores will usually have double digit performance losses compared to processor specific compiles. The 68060 and AC68080 performance likely does not suffer as much compatibility performance loss despite more handicaps but this is a sign of good core designs and a good ISA. With enough handicaps, even miracles are not possible for the best cores and ISAs.

@Kronos

Quote:

If you were to make a pure 68000 in FPGA you would either target it at "just run some old OCS games at lowest possible cost" and not as useable Amiga capable of running applications. Hence no need for OS3.anything or 100s of MHz.

Yes, that's the sad truth behind the possibility to market an "Amiga Compatible" ...

Sell a Amiga Console with some major games that made the platform popular resulting in:
OCS / ECS chipset compatibility, HDMI output, AOS1.3 and games in ADFs on a flash ROM and USB connector wit HID for keyboard and joystick all on a platform that could be FPGA or a simulation running on ARM.

Sad results (for me):
- It will be good enough for ~90% of Amiga interested buyers
- It will not bring the Amiga platform any further, no competitive hardware, no new OS, no new applications, no new games.

@matthey

Quote:

There are other places where performance will be more than doubled.

Exactly where in 68k AmigaOS is this - please be specific.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

OneTimer1 Quote:

Yes, that's the sad truth behind the possibility to market an "Amiga Compatible" ... Sell a Amiga Console with some major games that made the platform popular resulting in: OCS / ECS chipset compatibility, HDMI output, AOS1.3 and games in ADFs on a flash ROM and USB connector wit HID for keyboard and joystick all on a platform that could be FPGA or a simulation running on ARM. Sad results (for me): - It will be good enough for ~90% of Amiga interested buyers - It will not bring the Amiga platform any further, no competitive hardware, no new OS, no new applications, no new games.

Yes, that is the problem with products like THEA500 Mini (~$100 USD) and FleaFPGA Ohm (~$45 USD). They are cheap enough to turn heads and offer some retro value but the hardware lacks value compared to ASIC hardware. In a way, hundreds of thousands of THEA500 Mini units sold are a missed opportunity to sell better mass produced hardware that would move the Amiga platform forward.

kolla Quote:

Exactly where in 68k AmigaOS is this - please be specific.

The 68000 only supports 16x16=32 bit MUL instructions and several of these building block MUL instructions are used for a 32x32=32 and 32x32=64 bit multiply which is available in the 68020 ISA. The 68k AmigaOS patches utility.library functions to use the 68020 MUL instruction when available but the overhead is still more than double compared to a 2 cycle inlined MUL on the 68060. The function call overhead is at least 15 cycles and then the 68020 MUL instruction is 2 cycles. The function call to use a 68020 MUL takes more than 8 times as many cycles as an inlined 68020 MUL on the 68060 but this is a significant savings over using 68000 MUL instructions instead. The 68020+ are 32 bit CPUs meaning compilers will usually prefer 32 bit datatypes using 68020 MUL instructions so 68020 MUL instructions are not uncommon in some code. The 68000 was a 16 bit CPU that came out in 1979 using only 68,000 transistors. Even 16x16=32 bit MUL was a luxury feature at that time. By 1994, the 68060 used ~2.5 million transistors and 32x32=64 bit MUL was still to much of a luxury feature to include in hardware for an embedded CPU. Today, there are CPUs using tens of billions of transistors with 64x64=128 bit hardware MUL but it doesn't do much good when using 8086 or ARM2 code where performance will be a fraction of using more modern hardware MUL instructions.

@OneTimer1

that is what I sometimes not understand.... people add new hardware like PiStorm or something from apollo range and then stick to the old OS because it is fast. If you add something with more modern features that is a little slower they are unhappy. For what do people want a more powerful system? Just to run some more demanding ports from PC world?

@OlafS25

I also don’t get it. For me, the main advantage of PiStorm isn’t the speed, it’s primarily the availability and the low cost. Secondly it adds lots of RAM and I/O like storage and networking, all very useful, RTG and darn fast CPU is bonus. When I get pistorm for my A1000 it’s because it’s the easiest and cheapest alternative to get fast ram and network presence, I won’t even bother with RTG.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@matthey

So utility.library, except that it’s already taken care of by SetPatch so it’s a non-issue?

What do I do to actually witness 020+ optimization manifest itself?

I want to see some software and OS operation done with 68000 OS components vs the exact same software and OS operations done with 020+ OS components, on exact same hardware, where the latter drastically outperforms the former. PeterK’s icon.library should be like prime example, but even there the performance between 020+ version and 68000 version isn’t super noticeable. And that’s also third party, even with 020+ OS3.9, icon.library and Workbench.library were not 020+.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@OneTimer1

Quote:

OneTimer1 wrote: - It will not bring the Amiga platform any further, no competitive hardware, no new OS, no new applications, no new games.

If you want to "bring the Amiga platform any further" 3.2 is clearly the wrong tree to bark too.

Which of the other trees needs to be used or whether they are all different levels of useless for that idea is another 200 page "discussion".

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Quote:

If you want to "bring the Amiga platform any further" 3.2 is clearly the wrong tree to bark too.

Yes, I know.

Right idea for the OS would have been:
- less hardware dependencies
- portability to other hardware
- RTG, AHI, TCP/IP, USB, integration.
- Better Filesystem
- Maybe a total rewrite and a conversion to a system hosted on Linux or whatever.

AmigaOS 3.3 will get:
- new partitioning tool (HD Toolbox)
- new shell with tabs and scrollbar
- some revised Prefs programs e.g. Locale
- Sticky menus, context menus similar to MagicMenu

Not bad but only a small step forward.

Last edited by OneTimer1 on 08-Apr-2024 at 05:26 PM.

@OneTimer1

it was never a goal to make a modern amigaos with 3.3, it is just a slightly updating and bugfixing. Basically it will be the same. What they do can already be mostly done with components from aminet and a better desktop like scalos or magellan.

I do not think that it is possible at all to make a modern platform based on current concepts. You would need a drastic cut and lots of efforts.

kolla Quote:

So utility.library, except that it’s already taken care of by SetPatch so it’s a non-issue?

...
mulu.l Dn,Dm ; 2 cycles
...

code: 1 instruction and 4 bytes of code executed, 2 cycles best case for 68060

vs

...
jsr (d16,a6) ; UMult32() function call 5 cycles
...

--- jmp table ---
jmp xxx.L ; jump table 0 cycles predicted or 3 cycles without branch cache entry
--- jmp table ---

xxx:
mulu.l Dn,Dm ; 2 cycles
rts ; 7 cycles

code: 4 instructions and 14 bytes of code executed, 14 cycles best case for 68060

Best case performance is 7 times longer for UMult32() compared to the MULU.L inline and worst case is much worse (two more cache lines to load and the absolute branch in the jump table is not folded away). This is bad but better than adding partial sums of 68000 16x16=32 that looks something like the following.

;unsigned d0.l * d1.l -> d2.l:d3.l (d2.l holds high part)
move.w d0,d3
mulu.w d1,d3 ;d3.l is Al*Bl now
swap d0
swap d1
move.w d0,d2
mulu.w d1,d2 ;d2.l is Ah*Bh now
swap d0
move.w d0,d4
mulu.w d1,d4 ;d4 is Al*Bh
swap d4
moveq #0,d5
move.w d4,d5
clr.w d4 ; d5:d4 is 0x0000:Nh:Nl:0x0000, where N is Al*Bh
add.l d4,d3
addx.l d5,d2 ;add Al*Bh*0x10000 to the partial result in d2:d3
swap d0
swap d1
move.w d0,d4
mulu.w d1,d4 ;d4 is Ah*Bl
swap d4
moveq #0,d5
move.w d4,d5
clr.w d4 ; d5:d4 is 0x0000:Nh:Nl:0x0000, where N is Ah*Bl
add.l d4,d3
addx.l d5,d2 ;add Ah*Bl*0x10000 to the partial result
;d2:d3 is now the result

The code above is 32x32=64 where 32x32=32 can be simplified some but some developers need 32x32=64 for 64 bit integer datatypes that utility.library does not support (64 bit AmigaDOS file support?). There is function call overhead for the above code using a utility.library function which can be replaced with a single 68020 instruction. The AmigaOS is primitive and good at avoiding slower code where modern OSs have more advanced features. Do we want the 68k AmigaOS to have more advanced features like AmigaOS 4 uses?

kolla Quote:

What do I do to actually witness 020+ optimization manifest itself?

Profile code. You can also use a program like Snoopy (http://aminet.net/package/util/moni/snoopy20) to monitor utility.library function calls.

kolla Quote:

I want to see some software and OS operation done with 68000 OS components vs the exact same software and OS operations done with 020+ OS components, on exact same hardware, where the latter drastically outperforms the former. PeterK’s icon.library should be like prime example, but even there the performance between 020+ version and 68000 version isn’t super noticeable. And that’s also third party, even with 020+ OS3.9, icon.library and Workbench.library were not 020+.

The 68000 was amazing technology for 1979 but it is a primitive 16 bit CPU in some ways despite the 16/32 bit ISA. Supporting 45 year old technology may be holding the Amiga back at some point. Compatibility with 68000 software is important but more modern 68k hardware that fully supports 32 bit should be preferred. Modern hardware like the Amiga has mostly moved to 64 bit hardware while we lack full 32 bit hardware support in the AmigaOS.

Last edited by matthey on 08-Apr-2024 at 09:02 PM.
Last edited by matthey on 08-Apr-2024 at 08:50 PM.
Last edited by matthey on 08-Apr-2024 at 08:48 PM.

Its easy for some to forget why most of us are still interested in Amiga OS in 2024. Thankfully the OS3.2/3 development team haven't!

I think its fair to say all 68K Amigas (060 included) became genuinely retro around 2002. This was the year of the final official boingbag for OS3.9 & also the year people could buy a Windows XP Pentium 4 Northwood PC, with DDR & AGP 2.0. Windows XP for me just had that special something that made it a pleasure to use (cant say that about any other version of Windows). Amiga ECS & AGA machines with OS 3.X also have that special something but even more so. There's list of appealing aspects (Gunner talks about several), the OS is a very important one for a lots of folks. That special something I believe is the reason (combined with nostalgia) most of us are still interested.

OS3.3 being developed to work well on a plain old 68000 means it's all inclusive i.e. from the person who finds his old A500 (with say an A590) & wants to update its OS (for nostalgia/fun or remembering there was just something special about it) all the way to a V4 Standalone owner. For those with a V4 there is also Apollo OS, a good option if wanting more modern features to take advantage of the 68080 etc. (I'm sure something AROS based will be available for PiStorm too).

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 09-Apr-2024 at 01:00 AM.
Last edited by Tpod on 09-Apr-2024 at 12:52 AM.
Last edited by Tpod on 09-Apr-2024 at 12:47 AM.

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

@matthey

Quote:

matthey wrote: 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. Results will vary. There are places where 68020 optimizations are not needed and there is no performance improvement. There are other places where performance will be more than doubled. More modern CPU cores and better compilers will generally provide larger gains. Some compilers fail to do some 68020 optimizations with 68020 optimizations enabled. See the CoreMark thread above where GCC even fails to do normal common CISC optimizations. The AC68080 is expected to execute 68000 code without 68020 optimizations, without basic CISC optimizations, without ColdFire optimizations and without core specific superscalar instruction scheduling even though it could benefit from these optimizations. Then it is compared to modernized ColdFire and RISC-V benchmark results. Compatibility is important but ancient 68000 code is one of the reasons why the 68k is considered a low performance ISA when it is the opposite (another reason is ancient silicon and the use of FPGA simulation and emulation). Try executing 8086 code on a P5 Pentium or ARM2 code on a Cortex-A53 and these more modern cores will usually have double digit performance losses compared to processor specific compiles. The 68060 and AC68080 performance likely does not suffer as much compatibility performance loss despite more handicaps but this is a sign of good core designs and a good ISA. With enough handicaps, even miracles are not possible for the best cores and ISAs.

It was Pentium Pro (P6) that had performance problems with 16-bit X86.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@matthey

You seem to miss the point

HOW DO I ... EXPERIENCE... THIS PERFORMANCE DIFFERENCE!

Because, I don't.

If the ONLY way to really measure it, is by careful profiling and timid timing of corner cases, and the results are measured in single digit percentages... then sorry, there are other factors that are much more important to address.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@OneTimer1

Quote:

AmigaOS 3.3 will get: - new partitioning tool (HD Toolbox)

I doubt that EditPartition will replace HDToolBox any time soon.
Yes, it may look nice, but it also seem to lack a lot of "advanced" features that aren't there just to confuse users, but also are necessary for such a tool. "But Windows... but macOS.... but Linux..." people say. Yes, but those operating systems do _also_ offer advanced partitioning tools. For Amiga, advanced settings for partitions have been present in HDToolBox, and for quick installation we have HDSetup, a tool I trust almost noone is using. Am I right?

Quote:

- new shell with tabs and scrollbar

That's not a new shell, it's just another Console handler, this time a Reaction one.

Quote:

- some revised Prefs programs e.g. Locale

Just more Reaction junk.

Quote:

- Sticky menus, context menus similar to MagicMenu

What, there is nothing "contextual" about MagicMenu (and 3.3 menus), it's just the regular menus in "popup" style.
(Context menus would be menus that change depending on what icons are selected)

Quote:

Not bad but only a small step forward.

I would have focused quite differently (but so would probably anyone else)

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla



Maybe some more information does help here to understand this.

What advantages do 020 and higher 68K CPUs have?
- Free Scale in EA/Index mode
- many advanced EA modes
- Long Branches!
- a number of new instrutions MUL64, BITFIELDS
- the possibility to access miss aligned memory.


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.


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.

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

Last edited by Gunnar on 09-Apr-2024 at 08:10 AM.

Tpod Quote:

Its easy for some to forget why most of us are still interested in Amiga OS in 2024. Thankfully the OS3.2/3 development team haven't! I think its fair to say all 68K Amigas (060 included) became genuinely retro around 2002. This was the year of the final official boingbag for OS3.9 & also the year people could buy a Windows XP Pentium 4 Northwood PC, with DDR & AGP 2.0. Windows XP for me just had that special something that made it a pleasure to use (cant say that about any other version of Windows). Amiga ECS & AGA machines with OS 3.X also have that special something but even more so. There's list of appealing aspects (Gunner talks about several), the OS is a very important one for a lots of folks. That special something I believe is the reason (combined with nostalgia) most of us are still interested. OS3.3 being developed to work well on a plain old 68000 means it's all inclusive i.e. from the person who finds his old A500 (with say an A590) & wants to update its OS (for nostalgia/fun or remembering there was just something special about it) all the way to a V4 Standalone owner. For those with a V4 there is also Apollo OS, a good option if wanting more modern features to take advantage of the 68080 etc. (I'm sure something AROS based will be available for PiStorm too). 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 .

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.

68000 AmigaOS
o compile for 68000 target
o legacy AmigaOS as is for 68000 only hardware
68020 AmigaOS
o compile for 68060 target (avoids 68060 trapped instructions, instruction schedule for 68060)
o 32x32=32 multiply instructions inlined with function call for hardware optimized 32x32=64

The AmigaOS is relatively small by modern standards. There are nightly AmigaOS compiles already where a 68020 build could be added. Network transfer bandwidth is cheap today. The biggest issue is creating the dual build system and testing. Maybe we need a poll to see if there is enough interest to encourage the volunteer AmigaOS developers.

Hammer Quote:

It was Pentium Pro (P6) that had performance problems with 16-bit X86.

In some ways, the P6 Pentium is better with 808x code because of OoO execution. The in-order P5 Pentium was more limited about executing instruction pairs than the 68060 and old code before superscalar CPUs often was not scheduled. In comparison, the in-order 68060 benefits from a more orthogonal ISA and has an impressive dual and triple instruction issue rate with unscheduled code. The 68060 also benefits from 16 bit 68000 code often using 32 bit registers (all address register writes are 32 bit) avoiding partial register writes and allowing 32 bit result forward/bypass which is another ISA advantage. Old 16 bit 68000 code executes well enough on 32 bit 68k CPU cores that few people complain but there are exceptions with poor performance and some nice 68020+ improvements for 32 bit are missed. Only supporting 16x16=32 bit multiply when most modern integer datatypes are 32 bit where compilers generate 32x32=32 is a good example. The most common datatype size in the AmigaOS is likely 32 bit but the AmigaOS is primitive enough that multiply is often avoided. Multiply is common in some algorithms and even RISC ISAs for embedded hardware usually have hardware integer 32x32=32 bit multiply instructions today.

kolla Quote:

You seem to miss the point HOW DO I ... EXPERIENCE... THIS PERFORMANCE DIFFERENCE! Because, I don't. If the ONLY way to really measure it, is by careful profiling and timid timing of corner cases, and the results are measured in single digit percentages... then sorry, there are other factors that are much more important to address.

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.