@matthey
Quote:

Sure. RPi Pico RP2040 SoC is less than $1 USD. Original RPi and RPi Zero SoC maybe $2 for the SoC. The RPi 3 SoC maybe $3, RPi 4 SoC maybe $5 and RPi 5 SoC maybe $10. A 68060+AA+ SoC would use fewer transistors than the $1 RP2040 SoC and is more interesting as it could support HDMI unlike the RP2040 which has no video output. Enhancements are in order, especially increased CPU caches, extra CPU cores (68060x2, 68000?), more modern I/O and a 3D GPU would increase this and likely be worthwhile but may push it into the $3-$7 range.

FYI, Raspberry Pi is party-funded by ARM Ltd e.g. https://www.cnx-software.com/2023/11/03/arm-makes-strategic-investment-in-raspberry-pi/


Quote:

Avoiding ARM royalties is a competitive advantage for chip production. The royalties may not sound like much but they are significant in a competitive market.

That's a RISC-V argument, but Apple M3 and Qualcomm Oryon have ARMv8.6A and ARMv9 (at least matching current Qualcomm Snapdragon 8 Gen 3's ARM Cortex X3) clones respectively.

Western Digital has the engineering capability to design/customize their microcontroller CPU cores, hence why RISC-V ISA is selected for single-purpose data storage devices.

NVIDIA's Grace CPU uses ARM Neoverse V2 since their CPU design team is inferior to ARM Ltd's. NVIDIA has a custom RISC-V microcontroller CPU implementation for RTX GeForce products and this custom RISC-V microcontroller CPU is hidden.

Designing a "big fat" CPU core needs economics of scale.

For example,
Tenstorrent (custom fat core RISC-V, led by Jim Keller) has at least $100 million in funding from Hyundai and Samsung https://techcrunch.com/2023/08/04/ai-chip-startup-tenstorrent-lands-100m-investment-from-hyundai-and-samsung/
Tenstorrent’s total fundraising is $334.5 million.

Last edited by Hammer on 20-Feb-2024 at 03:07 AM.

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

@Kronos

Quote:

Kronos wrote: @matthey Look at THEA500Mini or rPi are priced, do some reasonable guesswork and realize that the ARM SoC can't be more than 5-10$. Thats what you would need to compete against. Both products are 100% CPU agnostic on the SW side, so sure you could enter that market with an 68k, PPC, MIPS or x86 SoC. But that also means that those have 0 advantage from not being ARM so would either compete on price or performance. Competing on performance means a good multicore design running on a current node, not viable when you are the new kid, Competing on price would require large economics of scale hitting before you have even come close to hitting those numbers. A cycle correct 68000 would only fix a small amount of issues in THEA500Mini while adding complexity (since it won't be able to run the extra and you'd also need a HW/FPGA chipset). A non fix for a non issue. There isn't really much demand for 68k outside of retro computing, which always also need additional HW to be emulated, something that can be done with 1 chip ARM board, a bit of SW and x variations of plastic cases for each 68000 (and non 68000) system you want to mimic. FreeScale could have done an rPi style HW back with ColdFire, they could have done it with some of the later PPC (one might say bPlan's EFIKA did aim in that direction) but they failed to realize that market. The last meaningful updates to 68k or PPC core were decades ago and you can't expect to leapfrog all that by putting old or untested hobbiest core on a smaller node. And you surely can't expect the markets that buying ARM in masses to switch just because you have something that MIGHT be almost as good for almost as cheap. Ergo, Amiga fantasy land ist still going strong 30 years later.

Yet another incompetent cache-coherency episode

https://bbrv.blogspot.com/2009/06/warningto-all-interested-parties.html
Jun 21,

The 5121e did not (does not) support cache-coherency, making the 5121e impractical for a consumer device that required the use of multiple applications simultaneously. We discovered this on our own. This major and unreported design change made most of the software developed for the 5200B based EFIKA/Open Client practically useless. The Product Manager for the 5121e (and even some of his technical staff) never understood the implications. We wasted more than a year of resources on the 5121e. In conclusion, the e300 PowerPC core has a brighter past than future -- too bad!

Nevertheless, the Limepc still made it to CES 2008. The handhelds displayed did not work and the desktop and HDTV versions were actually running on hidden Intel based machines. In the aftermath of CES 2008 and knowing we had been cheated by Limepc, we published Read All About It!

In the Spring of 2008, the Limepc management and the Freescale 5121e Product Manager began to realize they had problems actually doing what they were promising. It is a wonder that Tsinghua Tongfang (THTF - Public, SHA:600100) based in Beijing and the parent company of Limepc never understood the level of the deception. The Limepc was actually featured in the Freescale CEO's Keynote at FTF 2008. All the way around, THTF and Freescale C-level management was bamboozled. It was at this moment that Cherrypal stepped into international acclaim, riding on the crest of a wave of false technology claims and hyped up marketing.


--------------
The small details can cause a train wreck.

Last edited by Hammer on 20-Feb-2024 at 03:46 AM.
Last edited by Hammer on 20-Feb-2024 at 03:43 AM.

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

@matthey

Quote:

Efika may have been the best chance AmigaOS 4 had for affordable hardware. Low end PPC hardware has always been disappointing though. The PPC e300 CPU is based on the 603 which also was poor. There is only one CPU integer unit, the SoC is only clocked at 400MHz and there is only 128MiB of memory which is too little for fat PPC

You mix something up here.
The e300 has 2 full integer units - not only one as you say


The e300=5121 can execute 2 normal operations without problems as you see in the CPU fingerprint.
As you see in the test it can execute 2 ADD, or 2 SUB, 2 SHIFT, 2 AND .. it can even do 2 MUL !

The e300 has 2 integer units

Here is a finger print of the e300.


* As you see the e300 is exceptionally strong in Integer MUL !!!

* The e300 can 2 ALU operations,
or 1 ALU and 1 LOAD or STORE.

It can not do 2 memory in the same cycle.
(Doing one memory access per cycle is normal,
also the 750 G3 and 74xx G4 can do 1 memory access per clock only )

* As you see in the Loop-test the e300 has a relative high loop overhead
which means small loops will run relative slow on the e300.


I think the e300 is an average PowerPC core - with 2 instructions per cycle and no major weaknesses.
The e300 is similar to the G3, the G3 (750) has a small advantage in having less loop overhead.

Last edited by Gunnar on 20-Feb-2024 at 09:04 PM.
Last edited by Gunnar on 20-Feb-2024 at 06:02 PM.
Last edited by Gunnar on 20-Feb-2024 at 05:38 PM.

@Kronos & @Karlos

Quote:

Kronos wrote: >Those guys had over 30 years for switching and the option to go ColdFire. Karlos wrote: > There is zero market for a high end ASIC 68K solution outside of the retro enthusiast community ...

I think that's true, even those Coldfire users, that might need more than 300Mhz or those that where left behind by NXP and their marketing decisions, would need a MCU with a lot of I/O, I2C, SPI, Timers or CAN, I don't think the Apollo team has that in their product portfolio.

They will prefer a switch to ARM (iMX93 iMX8) instead of an unknown 68k variant.

@kolla

Quote:

kolla wrote: What’s funny is how active m68k support in Linux (and NetBSD) is, as well as in gcc and llvm tool chains, ...

A lot of Linux distributions have ceased their 32 Bit support, and it was the Amiga community that paid for further GCC support, normally it would have been NXPs task to support its hardware.

https://www.phoronix.com/news/GCC-11-m68k-Is-Safe

Without actual GCC you won't get an actual OS.



We should face reality 32bit and 68k are dying:

Quote:

FreeBSD is deprecating 32-bit platforms over the next couple of major releases. We anticipate FreeBSD 15.0 will not include the armv6, i386, and powerpc platforms, and FreeBSD 16.0 will not include armv7.

https://lists.freebsd.org/archives/freebsd-announce/2024-February/000117.html

@Hammer

Quote:

Hammer wrote: The 5121e did not (does not) support cache-coherency, making the 5121e impractical for a consumer device that required the use of multiple applications simultaneously.

Back in those days, the 5121e seemed to be a perfect MCU for an RasPi like device, just like an Efika on speed but Freescale failed with the PPC, has since been bought by NXP and only supports ARM today.

@Gunnar

Quote:

Gunnar wrote: The e300 has 2 integer units - not only one as you say The e300=5121 can execute 2 normal operations without problems as you see.

It doesn't matter any more, NXP is going ARM and this MCU has good OS support.

Last edited by OneTimer1 on 20-Feb-2024 at 06:39 PM.

Hammer Quote:

FYI, Raspberry Pi is party-funded by ARM Ltd e.g. https://www.cnx-software.com/2023/11/03/arm-makes-strategic-investment-in-raspberry-pi/

RPi Ltd. (non-profit RPi hardware business) had been looking at RISC-V where there are no ARM royalties.

https://www.cnx-software.com/2023/11/03/arm-makes-strategic-investment-in-raspberry-pi/ Quote:

There was no detail about the amount invested or further details about the agreement so that’s about all that we know. I don’t usually write about business news, but in this case, Raspberry Pi has also been a RISC-V member since January 2019, and it’s unclear how Arm’s investment may influence future development of RISC-V chips and boards by Raspberry Pi.

The RP2040 SoC uses ARM Cortex-M0+ cores which have reduced royalties compared to Cortex-A CPU cores. I wonder if the investment includes an agreement with reduced royalties and/or licensing fees. ARM has agreements with large strategic partners making them more competitive while they stealthily increase royalties and practically require POP IP blocks that are indirectly billed by chip foundries. It is interesting to see a low cost producer receiving special deals but this is likely a recognition of how successful RPi hardware has become, especially for IoT, and the risc of royalty free RISC-V cores and IP blocks.

Hammer Quote:

That's a RISC-V argument, but Apple M3 and Qualcomm Oryon have ARMv8.6A and ARMv9 (at least matching current Qualcomm Snapdragon 8 Gen 3's ARM Cortex X3) clones respectively.

Apple has old favorable licensing agreements and has negotiated newer licensing agreements that are likely significantly better than any new or small businesses can get. Qualcomm bought a business to use their more favorable licensing agreement with ARM only to have ARM try to end and/or renegotiate the agreement resulting in Qualcomm suing ARM. Qualcomm is looking at RISC-V too.

Hammer Quote:

Western Digital has the engineering capability to design/customize their microcontroller CPU cores, hence why RISC-V ISA is selected for single-purpose data storage devices. NVIDIA's Grace CPU uses ARM Neoverse V2 since their CPU design team is inferior to ARM Ltd's. NVIDIA has a custom RISC-V microcontroller CPU implementation for RTX GeForce products and this custom RISC-V microcontroller CPU is hidden.

RISC-V is more competitive for customized integrated embedded cores. Avoiding royalties and licensing issues is a plus, especially where performance is not so important and the core lifespan is planned to be long.

Hammer Quote:

Designing a "big fat" CPU core needs economics of scale. For example, Tenstorrent (custom fat core RISC-V, led by Jim Keller) has at least $100 million in funding from Hyundai and Samsung https://techcrunch.com/2023/08/04/ai-chip-startup-tenstorrent-lands-100m-investment-from-hyundai-and-samsung/ Tenstorrent’s total fundraising is $334.5 million.

Development costs need to be distributed into the cost of each produced chip. Development costs of "big fat" uoped OoO CPU cores are insanely expensive and the fat chips cost more. The development costs of in-order CPU cores are a fraction of the cost and the chips are a fraction of the size with a fraction of the cost. These two factors have synergies where a higher performance in-order core that is smaller and cheaper can be appealing. This is where I believe a modernized 68060 like core could be competitive after seeing the performance of the similarly designed SiFive U74 core using a weaker RISC-V ISA. The SiFive U74 core is approaching the performance of the highest performance limited OoO PPC cores and a CISC ISA with this core design should be significantly higher performance.

Last edited by matthey on 20-Feb-2024 at 06:57 PM.
Last edited by matthey on 20-Feb-2024 at 06:51 PM.

@matthey

Quote:

matthey wrote: Kronos Quote: As for "Gunnar" being "MEGA_RJ_MICAL" I see 3 options: 1. the similarities are only in your mind 2. MEGA has far more technical expertise as he had shown previously 3. MEGA was Gunnar's troll account from day 1 MEGA is sadly an intelligent person with mental issues. Much of the information Gunnar has posted here is copied from the AC forum and correct. There are lies, some copied from the AC forum, and major tech blunders made as I have pointed out in my previous post. Gunnar did not answer my questions because he can't and attacked instead as I predicted (I won't respond to his trolling unless he can answer my questions). The real Gunnar is a narcissist but isn't so irritable that he attacks everyone endlessly. Don't be fooled.

He's the real one. This time even you can easily verify that.

Take a look at this thread on AC.

He opened it AFTER that he reported the same information here.

Now become at peace with that and accept it, finally.

Gunnar Quote:

You mix something up here. The e300 has 2 integer units - not only one as you say

Ok. I see that is correct and I was mistaken. This is a big upgrade from the 603 which often made instruction scheduling impossible with one integer unit and one load/store unit. A 2nd integer unit barrel shifter is not as cheap as an ALU and is not as useful without being able to use it for addressing mode calculations like the 68060 and SiFive U74 cores. Even the RISC-V U74 core has this advantage even though it never uses both the address calculation stage (AGU/EA calc) and execution stage of the execution pipeline for the same RISC instruction unlike many CISC instructions. Of course the main motivation of using this design was likely to remove the load-to-use stalls that kill RISC performance.

OneTimer1 Quote:

I think that's true, even those Coldfire users, that might need more than 300Mhz or those that where left behind by NXP and their marketing decisions, would need a MCU with a lot of I/O, I2C, SPI, Timers or CAN, I don't think the Apollo team has that in their product portfolio. They will prefer a switch to ARM (iMX93 iMX8) instead of an unknown 68k variant.

SiFive has SoCs that can be licensed with about everything needed. Their U74 CPU core is similar to the 68060, very good and could likely be changed to a different architecture. On one of the SoCs with U74 cores, the L2 is 2MiB and can be configured as SRAM for a MCU (no external memory required). Starting with already tested IP like this is very valuable and it sounded like there were no royalties unlike ARM IP. In any case, there is licensable IP available. Most 3D GPUs require royalties but it is difficult to avoid royalties altogether.

OneTimer1 Quote:

A lot of Linux distributions have ceased their 32 Bit support, and it was the Amiga community that paid for further GCC support, normally it would have been NXPs task to support its hardware. https://www.phoronix.com/news/GCC-11-m68k-Is-Safe Without actual GCC you won't get an actual OS. We should face reality 32bit and 68k are dying:

Linux is resource hungry so the developers bump requirements. This is an opportunity for a minimalist 32 bit AmigaOS. ARM64/AArch64 increased resource requirements while ARM32/Thumb2 is being dropped. This is an opportunity for compressed architectures like the 68k. Put them together and there are synergies. OSs supporting 32 bit are going away faster than 32 bit CPUs cores. The resources difference between a 32 bit and 64 bit OS is substantial.

https://techexplorations.com/guides/rpi/begin/rpi-os-32bit-vs-64bit/ Quote:

If you have a more memory-starved Raspberry Pi, like the Raspberry Pi Zero 2 W (512MB of RAM) or the 1GB Raspberry Pi 3 or 4, you might be better off using the 32-bit OS. Phoronix reports that, at idle/boot, the 64-bit OS takes up 196MB of RAM while the 32-bit uses 103MB.

GUIs may be disabled and Linux distributions cut down, reducing compatibility, in order to reduce memory usage. The 68k AmigaOS can operate with a full GUI and OS in a fraction of the space of Linux on a RPi Zero.

Compiler support for an architecture is relative to hardware supporting it. Compilers usually don't support emulation targets. It is surprising how much 68k support there is considering the many years without new hardware available.

OneTimer1 Quote:

Back in those days, the 5121e seemed to be a perfect MCU for an RasPi like device, just like an Efika on speed but Freescale failed with the PPC, has since been bought by NXP and only supports ARM today.

The original RPi only had a single 32 bit scalar CPU core which is less than the Efika 32 bit superscalar 5121e PPC CPU core and 68060 core. The RPi had Thumb2 with 68k like code density where PPC was fat. The cramped original RPi has more memory along with much better code density than the Efika which was very cramped. The low cost RPi Zero with the same CPU core as the original RPi remains popular for embedded use although the RPi Zero 2 W with 4xCortex-A53 superscalar in-order cores is also very popular.

I'm not so sure the cache coherency issues were the major reason for lack of success. RPi hardware also has cache coherency issues.

Does the Pi 2/3/4 support cache coherency in L1?
https://forums.raspberrypi.com/viewtopic.php?t=345224

Low cost SoC hardware is often not integrated as well as it could be. It would sure be nice to have HSA systems like PS and XBox consoles where all caches are always coherent.

Last edited by matthey on 21-Feb-2024 at 01:00 AM.

@matthey

Quote:

matthey wrote: OneTimer1 Quote: I think that's true, even those Coldfire users, that might need more than 300Mhz or those that where left behind by NXP and their marketing decisions, would need a MCU with a lot of I/O, I2C, SPI, Timers or CAN, I don't think the Apollo team has that in their product portfolio. They will prefer a switch to ARM (iMX93 iMX8) instead of an unknown 68k variant. SiFive has SoCs that can be licensed with about everything needed. Their U74 CPU core is similar to the 68060, very good and could likely be changed to a different architecture. On one of the SoCs with U74 cores, the L2 is 2MiB and can be configured as SRAM for a MCU (no external memory required). Starting with already tested IP like this is very valuable and it sounded like there were no royalties unlike ARM IP. In any case, there is licensable IP available. Most 3D GPUs require royalties but it is difficult to avoid royalties altogether.

Who'll develop the new 68060++ core using SiFive's core/IPs?
Quote:

OneTimer1 Quote: A lot of Linux distributions have ceased their 32 Bit support, and it was the Amiga community that paid for further GCC support, normally it would have been NXPs task to support its hardware. https://www.phoronix.com/news/GCC-11-m68k-Is-Safe Without actual GCC you won't get an actual OS. We should face reality 32bit and 68k are dying: Linux is resource hungry so the developers bump requirements. This is an opportunity for a minimalist 32 bit AmigaOS. [...] GUIs may be disabled and Linux distributions cut down, reducing compatibility, in order to reduce memory usage. The 68k AmigaOS can operate with a full GUI and OS in a fraction of the space of Linux on a RPi Zero. Compiler support for an architecture is relative to hardware supporting it. Compilers usually don't support emulation targets. It is surprising how much 68k support there is considering the many years without new hardware available.

For doing what, with all the big limits that it has (and I've reported on my last article)?

The Amiga OS is just a hobby/toy OS. If you use it like that (for your hobby) then it's perfectly fine since you're a passionate of the old machines and OS and you enjoy it even with all those big limits. But going beyond that is not possible and doesn't even make sense.

BTW, Linux is a mammoth, but there are other fully-fledged modern OSes which are much more lightweight.

You can also take some microkernel and build a new, MODERN (read: with all bells and whistles) Amiga-inspired OS. But definitely NOT the Amiga OS "per sé", because it's a toy, as I've said.

P.S. I agree about the in-order cores & code density discussions.

However not for the 64-bit discussion: 64-bit systems aren't "fat" by definition. It depends on the ISA for/on which they are running.

Last edited by cdimauro on 21-Feb-2024 at 05:19 AM.

@OneTimer1

Quote:

OneTimer1 wrote: @kolla A lot of Linux distributions have ceased their 32 Bit support

Yes, but this has nothing to do with Amiga - what’s being dropped is support for 32bit x86, by distros that never did 68k anyways. With one exception, Debian.

Quote:

it was the Amiga community that paid for further GCC support, normally it would have been NXPs task to support its hardware.

It was a joint effort between all 68k communities, also the Atari folks and more. GCC and LLVM are *ix first, so the ones who truly benefit are those doing Linux and NetBSD for 68k. AmigaOS developers are limping behind, I think Bebbo’s at gcc-6, wth attempts to get it more modern. Some years ago there was effort to overcome TLS support, threading local storage, which also was bountied… no Amiga user benefit from this.

Quote:

Without actual GCC you won't get an actual OS.

AmigaOS 3 isn’t built with gcc, they use SAS/C running in Vamos iirc.

Quote:

Quote: FreeBSD is deprecating 32-bit platforms over the next couple of major releases. We anticipate FreeBSD 15.0 will not include the armv6, i386, and powerpc platforms, and FreeBSD 16.0 will not include armv7. https://lists.freebsd.org/archives/freebsd-announce/2024-February/000117.html

FreeBSD never ran on m68k, why do you even bring it up? I clearly wrote NetBSD.

Last edited by kolla on 21-Feb-2024 at 06:43 AM.
Last edited by kolla on 21-Feb-2024 at 06:42 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@cdimauro

Wheb you link with urls that contain & make sure to replace the & with &,

http://apollo-core.com/knowledge.php?b=4&note=40539

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@cdimauro

Quote:

However not for the 64-bit discussion: 64-bit systems aren't "fat" by definition. It depends on the ISA for/on which they are running.

Programs contains many addresses.
Programs work all the time with Adresses: adresses of Labels, of Variables, Adresses of System calls.
Using 32bit memory addressing the addresses are 32bit long = 4 Byte
If you have a system with 64bit addresses then they are 8 Byte long.

Its easy to see how this makes programs bigger.

@OneTimer1

Quote:

Well if you have a 1GHz 68k core with ~512MB of cache

Lets not forget that AMIGA OS is _very_light_ compared to Windows or Linux.

Many of the AmigaNG PPC systems have not stellar performance.
And they feel slow with Linux or would feel slow with Windows (if they could run it)

But with the much lighter Amiga OS they feel fast and swift.


The Apollo Systems running Amiga OS feel lightning fast.
They can boot in seconds and using Amiga Os feels great.


If you want to run AMIGA OS 3/4 and use Amiga programs that exist today for 68k or PPC
Then you not need a 6 GHz CPU to have a good working system.

The Pegasos and AmigaOne CPU of 600MHz is actually more than enough for many use cases.
The biggest problem of many PPC NEo Amiga Systems was their bad memory performance.
If the Memory Performance would have been "fixed" then in many case the AmigaOnes would feel 2 times faster.
And be pretty good systems for running the light AmigaOS

@matthey

Quote:

This is a big upgrade from the 603 which often made instruction scheduling impossible with one integer unit and one load/store unit.

Yes the e300 has a clear advantage.


Of course we have to mind that the 603 is stone age old.
It was one of the first chips and its focus was entry level and low power.


To improve INTEGER performance the 603 can cheat a little.
As you know the load/store unit does ADD/SUB for EA calculation.
This ADD/SUB can be "borrowed" to do one more ADD/SUB for INTEGER math instead a load.

This allows to get 2 ADD/SUB instructions done per cycle.


You can see the effect of this "cheat" nicely on the 5200 fingerprint



As you see it can with ADD / SUB benchmark do well over 1 ADD per cycle

Last edited by Gunnar on 21-Feb-2024 at 10:59 AM.
Last edited by Gunnar on 21-Feb-2024 at 10:58 AM.

@kolla

Quote:

kolla wrote: @cdimauro Wheb you link with urls that contain & make sure to replace the & with &, http://apollo-core.com/knowledge.php?b=4¬e=40539

Thanks kolla. I was in hurry this morning and I didn't check it.


@Gunnar

Quote:

Gunnar wrote: @cdimauro Quote: However not for the 64-bit discussion: 64-bit systems aren't "fat" by definition. It depends on the ISA for/on which they are running. Programs contains many addresses. Programs work all the time with Adresses: adresses of Labels, of Variables, Adresses of System calls. Using 32bit memory addressing the addresses are 32bit long = 4 Byte If you have a system with 64bit addresses then they are 8 Byte long. Its easy to see how this makes programs bigger.

It's not that easy.

The primary thing which is contributing on the overall size is about the instruction length of the specific ISA (and, of course, how many instructions are generated / executed).
That can be easily verified, because we know that CodeDensity(ARM/Thumb-2) is > CodeDensity(ARM64/AArch64). We also know that CodeDensity(x86) > CodeDensity(x64). This is just an example, to simplify the discussion.

However other aspects of an ISA can influence how much memory, in general (so, not only about the code, but also about the data structures), is used. This depends also on the specific context. Specifically, about for what purpose a data / pointer is being used.

For example, we can have different program models. We can have the "large" model where code and data can be freely located on every possible address of the 64-bit address space.
However, we can have a "small" program model where both code and data pointers use only 32-bit pointers, despite the possibility to manipulate 64-bit data.
Or we can have a "medium" program model where code uses 32-bit pointers and allocated memory structures use 64-bit pointers. And viceversa, of course (but it's much rarer).
On top of that, you can also define how the stack should work: the minimum stack size for data to be pushed. For example, you can decide to align data to 8-bit / byte, to minimize the usage of such memory.

That's some trivial stuff to understand because it's part of the common literature. But some other things aren't immediate like those and can influence as well the overall memory usage.

A simple example: the immediates. Not all architectures support them and only some allow to encode/embedded large constants. An architecture which allows to do it has a clear advantage, because a single instruction can, for example, define & use the immediate without requiring additional instructions to do the same or such data moved to the data section (and loaded by specific instructions).
This is trivial and a pleasure for CISCs aficionados, but not for L/S architectures (former RISC architectures).

On the same page, there could also be the possibility to broadcast / splat immediates or values read from the data section. This reduces the number of instructions and/or the space on the data section.

More tricky is the possibility to use "packed" / "compact" pointers. Whatever is the register size of an architecture, there could be the possibility to use much smaller space for encoding pointers. Think about the jump tables for switch/case instructions, for example: you can avoid using the integral pointer size and just use an offset to the current PC. Architectures can have specific instructions for those cases, which reduce the usage of data space even if pointers are 64-bit in size.

Even more trickier, some architectures could define "other ways" to implement the same things in a more efficient or faster way. And this includes OOP constructs (calls or jumps to the VMT).

So, and to close here because it's becoming too long, you can see that there are many ways where even 64-bit architecture can use much less memory, in general.

Yes, if you need to encode any arbitrary memory location, then you need 8 bytes on a 64-bit architecture. No question here.

However, some architecture could address / implement all above use cases / contexts and can even use less memory compared to 32 or even 16 bit architecture.
Quote:

Gunnar wrote: @OneTimer1 Quote: Well if you have a 1GHz 68k core with ~512MB of cache Lets not forget that AMIGA OS is _very_light_ compared to Windows or Linux. Many of the AmigaNG PPC systems have not stellar performance. And they feel slow with Linux or would feel slow with Windows (if they could run it) But with the much lighter Amiga OS they feel fast and swift.

But it's also severely limited and can crash with a breath...

cdimauro Quote:

Who'll develop the new 68060++ core using SiFive's core/IPs?

There are options including assembling a small development team and paying SiFive for development. An experienced chief architect or technical consultant would be valuable. Perhaps the fastest development, most compatible option and best respected option would be to license the 68060 and enhance it with the licensed SiFive SoC IP. Having both the 68060 and U74 core would be super depending on licensing costs. Both the SiFive IP and 68060 core are written in Verilog with modularity as a goal. I expect licensing and development costs would be in the $1-3 million USD range but it would need further exploring. This does not include ASIC production related costs and a 3D GPU could push this higher.

It would likely be significantly cheaper to create an AC68080 ASIC. The AC68080 would need further development like a multilevel caching system (low clock speeds in FPGA allow a single large cache to be used). The core is written in VHDL meaning the SiFive IP could not as easily be used but there is at least an open hardware VHDL L2 implementation available. I have serious doubts about the development professionalism of this core, IP and ISA, especially for use in an ASIC, but an ASIC core could likely reach similar clock speeds while costing millions less with the cooperation of the AC team. While modern I/O support is lacking, SAGA development is a positive although there are plenty of Amiga chipset implementations available and talented developers who can work on them.

cdimauro Quote:

For doing what, with all the big limits that it has (and I've reported on my last article)? The Amiga OS is just a hobby/toy OS. If you use it like that (for your hobby) then it's perfectly fine since you're a passionate of the old machines and OS and you enjoy it even with all those big limits. But going beyond that is not possible and doesn't even make sense.

The 68k AmigaOS is a nice responsive, modular, small footprint and standard OS. These are very good attributes for a small OS where other attributes are more important for a larger desktop like OS where AmigaOS 4 fails to compete. SMP, memory protection and 64 bit support have become more important for smaller OSs but it is not unusual that some of these features are discarded with a small footprint and/or low CPU performance. The original RPi (and RPi Zero) does not support SMP with only one core or even superscalar execution yet 700,000 units were sold in the first year alone and likely millions of units all time if counting the RPi Zero. Most of these RPis have 512MiB of memory and use a 32 bit OS with Thumb2 used to minimize resources used. This could have been 68k AmigaOS if cheap enough hardware was available. The 68k AmigaOS had a more standard OS with more software at this footprint. It still has an advantage in footprint and certain kinds of software, especially retro games.

The 68k AmigaOS could still provide a sizeable niche with affordable hardware but would be limited in how far it could scale up without addressing SMP, memory protection and 64 bit support. I believe SMP with compatibility can be addressed with custom hardware without affecting the performance or use of other OSs on the hardware. I have hinted that private memory can be used while a core is using Forbid(). Flushing/syncing the pipelines of cores which have accessed shared memory is not as expensive as the inter-core communication and syncing of cores which can be reduced with simple hardware customizations. There is a significant cost for traditional SMP code that uses sync/fence instructions and locking and/or non-locking mechanisms to protect structures including reduced performance, increased code size, deadlocks and priority inversion problems. Improved memory protection including zero page protection and code protection are already possible as used in some 68k AmigaOS compatible OSs. This is likely not good enough for some high end applications like servers but may be good enough up to budget desktop use. We already discussed 64 bit support which can be compatible with 32 bit support. A 32 bit AmigaOS with limited 64 bit support is likely possible while maintaining compatibility. It would be nice to develop an incompatible NG AmigaOS that addresses modern features in the best way rather than in compatible ways but the importance of compatibility makes exploring compatible ways important. How crazy is it that NG AmigaOS like OSs didn't address the lack of important desktop features. Neither have FPGA Amiga hardware projects chosen to use a large FPGA to research AmigaOS solutions as well as develop toward an ASIC as FPGAs are traditionally used. It doesn't help that NG AmigaOS businesses have ignored and practically blocked 68k AmigaOS FPGA development that has a better chance to be NG than PPC PC hardware.

cdimauro Quote:

BTW, Linux is a mammoth, but there are other fully-fledged modern OSes which are much more lightweight. You can also take some microkernel and build a new, MODERN (read: with all bells and whistles) Amiga-inspired OS. But definitely NOT the Amiga OS "per sé", because it's a toy, as I've said.

The choices for standardized lightweight OSs are not that good, at least for free OSs. The RPi has 15+ OSs available but most of them are cut down lightweight Linux. The following thread lists many lightweight Linux distros.

Unofficial list of Raspberry Pi distributions
https://forums.raspberrypi.com/viewtopic.php?t=328911

RISC OS, Windows 10 IoT Core and Windows 11 are the best known standard non-Linux OSs. Windows is not lightweight and RISC OS is less advanced than AmigaOS. FreeRTOS is used for embedded use but isn't even listed because there isn't a standard install/distribution. There are other embedded RTOSs but most of them are not free and not standard. One thing that is interesting is how many Pi OSs are retro gaming oriented including Retropie, Recalbox, Batocera and Lakka. These are your toy OSs but I would be surprised if they didn't each have a larger install base than AmigaOS 4. It's alright to have a toy OS on toy hardware. The RPi was sometimes considered a toy when introduced due to the low cost but it is much more.

@matthey

Quote:

matthey wrote: cdimauro Quote: Who'll develop the new 68060++ core using SiFive's core/IPs? There are options including assembling a small development team and paying SiFive for development. An experienced chief architect or technical consultant would be valuable. Perhaps the fastest development, most compatible option and best respected option would be to license the 68060 and enhance it with the licensed SiFive SoC IP. Having both the 68060 and U74 core would be super depending on licensing costs. Both the SiFive IP and 68060 core are written in Verilog with modularity as a goal. I expect licensing and development costs would be in the $1-3 million USD range but it would need further exploring. This does not include ASIC production related costs and a 3D GPU could push this higher.

That's really too much. You've to find a rich benefactor (former Amiga/Atari happy user) to sustain this project.
Quote:

It would likely be significantly cheaper to create an AC68080 ASIC. The AC68080 would need further development like a multilevel caching system (low clock speeds in FPGA allow a single large cache to be used). The core is written in VHDL meaning the SiFive IP could not as easily be used but there is at least an open hardware VHDL L2 implementation available. I have serious doubts about the development professionalism of this core, IP and ISA, especially for use in an ASIC, but an ASIC core could likely reach similar clock speeds while costing millions less with the cooperation of the AC team. While modern I/O support is lacking, SAGA development is a positive although there are plenty of Amiga chipset implementations available and talented developers who can work on them.

That's a no-go, you know: Gunnar is the sole one which decides on that project.
Quote:

cdimauro Quote: For doing what, with all the big limits that it has (and I've reported on my last article)? The Amiga OS is just a hobby/toy OS. If you use it like that (for your hobby) then it's perfectly fine since you're a passionate of the old machines and OS and you enjoy it even with all those big limits. But going beyond that is not possible and doesn't even make sense. The 68k AmigaOS is a nice responsive, modular, small footprint and standard OS. These are very good attributes for a small OS where other attributes are more important for a larger desktop like OS where AmigaOS 4 fails to compete. SMP, memory protection and 64 bit support have become more important for smaller OSs but it is not unusual that some of these features are discarded with a small footprint and/or low CPU performance. The original RPi (and RPi Zero) does not support SMP with only one core or even superscalar execution yet 700,000 units were sold in the first year alone and likely millions of units all time if counting the RPi Zero. Most of these RPis have 512MiB of memory and use a 32 bit OS with Thumb2 used to minimize resources used. This could have been 68k AmigaOS if cheap enough hardware was available. The 68k AmigaOS had a more standard OS with more software at this footprint. It still has an advantage in footprint and certain kinds of software, especially retro games. The 68k AmigaOS could still provide a sizeable niche with affordable hardware but would be limited in how far it could scale up without addressing SMP, memory protection and 64 bit support.

To me SMP and 64-bit aren't the major problems with the AmigaOS: it's everything else (which I've reported on my last article).

We know that it's very lightweight, super-responsive, and consumes less resources (but pay attention: that's because the graphic/audio assets of the time were also very limited and uses much less space compared to nowadays. And we didn't have very complicated but user-friendly software using technologies like HTML/CSS/JS), but let's say that you put in on a Set-Top-Box (so, competing with Android TV, Fire TV, WebOS, HarmonyOS, etc.): do you think that it works out well on this market?

I don't, and for the reason that I've explained: it crashes with a breath. And you cannot sell this stuff to the general customers.

You can't even sell it to other customers on different markets for exactly the same reasons.

Is there any market where do you think that it can be used? I mean: large enough (in the millions ballpark) to justify an investment.
Quote:

I believe SMP with compatibility can be addressed with custom hardware without affecting the performance or use of other OSs on the hardware. I have hinted that private memory can be used while a core is using Forbid(). Flushing/syncing the pipelines of cores which have accessed shared memory is not as expensive as the inter-core communication and syncing of cores which can be reduced with simple hardware customizations.

That's like cheating: you're not fixing the problem but just moving it a little bit ahead the problem.

First of all, it's not that efficient (see below).

Second, and most important, this works as long as you can have a single SoC with everything inside. It doesn't work if you have multiple chips, because synchronizing them will become a nightmare to implement.
Quote:

There is a significant cost for traditional SMP code that uses sync/fence instructions and locking and/or non-locking mechanisms to protect structures including reduced performance, increased code size, deadlocks and priority inversion problems.

While blocking all other cores to run the critical section on just one isn't even a much higher cost?
Quote:

Improved memory protection including zero page protection and code protection are already possible as used in some 68k AmigaOS compatible OSs. This is likely not good enough for some high end applications like servers but may be good enough up to budget desktop use.

To whom would you sell such budget desktop which still crashes like a breath, since this memory protection is too simple and not enough?
Quote:

We already discussed 64 bit support which can be compatible with 32 bit support. A 32 bit AmigaOS with limited 64 bit support is likely possible while maintaining compatibility.

So, the MacOS X Tiger model, I assume. It lasted only a couple of years AFAIR, because of its all big limits.

Anyway, 64 bits aren't the most important feature.
Quote:

It would be nice to develop an incompatible NG AmigaOS that addresses modern features in the best way rather than in compatible ways but the importance of compatibility makes exploring compatible ways important. How crazy is it that NG AmigaOS like OSs didn't address the lack of important desktop features. Neither have FPGA Amiga hardware projects chosen to use a large FPGA to research AmigaOS solutions as well as develop toward an ASIC as FPGAs are traditionally used. It doesn't help that NG AmigaOS businesses have ignored and practically blocked 68k AmigaOS FPGA development that has a better chance to be NG than PPC PC hardware.

Well, they are all on the same position: too limited.

Removing the backward compatibile is a need, nowadays. The legacy can run on a sanbox.

Otherwise there cannot be any possibility for the future.
Quote:

cdimauro Quote: BTW, Linux is a mammoth, but there are other fully-fledged modern OSes which are much more lightweight. You can also take some microkernel and build a new, MODERN (read: with all bells and whistles) Amiga-inspired OS. But definitely NOT the Amiga OS "per sé", because it's a toy, as I've said. The choices for standardized lightweight OSs are not that good, at least for free OSs. The RPi has 15+ OSs available but most of them are cut down lightweight Linux. The following thread lists many lightweight Linux distros. Unofficial list of Raspberry Pi distributions https://forums.raspberrypi.com/viewtopic.php?t=328911 RISC OS, Windows 10 IoT Core and Windows 11 are the best known standard non-Linux OSs. Windows is not lightweight and RISC OS is less advanced than AmigaOS. FreeRTOS is used for embedded use but isn't even listed because there isn't a standard install/distribution. There are other embedded RTOSs but most of them are not free and not standard. One thing that is interesting is how many Pi OSs are retro gaming oriented including Retropie, Recalbox, Batocera and Lakka. These are your toy OSs but I would be surprised if they didn't each have a larger install base than AmigaOS 4. It's alright to have a toy OS on toy hardware. The RPi was sometimes considered a toy when introduced due to the low cost but it is much more.

I was thinking more at some microkernels: https://en.wikipedia.org/wiki/Microkernel

For example:
https://en.wikipedia.org/wiki/Minix_3
https://en.wikipedia.org/wiki/QNX
https://en.wikipedia.org/wiki/Redox_(operating_system)

So, taking one of them as the foundation for new Amiga-ispired OS.

@matthey

Quote:

RPi Ltd. (non-profit RPi hardware business) had been looking at RISC-V where there are no ARM royalties.

You missed the line context.

https://www.anandtech.com/show/21120/arm-acquires-minority-stake-in-raspberry-pi
In November 2023,

Arm Holdings has acquired a minority stake in Raspberry Pi Ltd, reinforcing a partnership that began in 2008. This strategic investment is designed to support development of Raspberry Pi's low-cost low-power Arm-based platforms aimed at edge computing and IoT applications, leveraging Raspberry Pi's ability to deliver affordable, high-performance computing globally


Raspberry Pi Ltd's RISC-V commitment has been questioned.

ARM Holdings is using its financial strength to influence its ARM-related distribution channels.


Quote:

It is interesting to see a low cost producer receiving special deals but this is likely a recognition of how successful RPi hardware has become, especially for IoT, and the risc of royalty free RISC-V cores and IP blocks.

Arm Holdings acquired a minority stake in Raspberry Pi Ltd in November 2023.

Quote:

Apple has old favorable licensing agreements and has negotiated newer licensing agreements that are likely significantly better than any new or small businesses can get.

Apple has designed its M series Firestorm (p-cores) and Icestorm (e-cores) microarchitectures which is an ARMv8.x clone.

Key M1 engineers left Apple and formed NUVIA.

Quote:

Qualcomm bought a business to use their more favorable licensing agreement with ARM only to have ARM try to end and/or renegotiate the agreement resulting in Qualcomm suing ARM. Qualcomm is looking at RISC-V too.

Qualcomm has the Oryon (at least) ARMv9 clone. Qualcomm Completes Acquisition of NUVIA in March 2021. The NUVIA team designed Oryon.

https://www.theregister.com/2022/11/17/qualcomm_nuvia_arm/
Qualcomm teases custom Arm-compatible Oryon CPU cores designed by Nuvia (Nov 2022)

Qualcomm Oryon is the insurance against ARM Holdings e.g. Qualcomm SnapDragon 8 Gen 4 SoC.

With future ARM Cortex X series CPU licenses, ARM Holdings attempts to force bundle ARM-designed GPU and NPU IP.

Qualcomm Snapdragon 8 Gen 4 does NOT need ARM Cortex X5.

https://www.techpowerup.com/319330/alleged-arm-cortex-x5-underperformance-linked-to-power-consumption-concerns
Alleged ARM Cortex-X5 Underperformance Linked to Power Consumption Concerns.

ARM Holdings will face against the ARM clones from Apple and Qualcomm.

Samsung's current Exynos 2400 SoC has ARM Holdings Cortex X4/A720/A520 CPU IP with AMD's RDNA 3 IGP.

Microcontroller CPU is different from the application CPU market.

Last edited by Hammer on 22-Feb-2024 at 07:40 AM.

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