ZORRAM

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

@Kronos

Quote:

Kronos wrote: @cdimauro Quote: cdimauro wrote: If we talk about the 8086 Real mode (THE 8086 ISA), then I can easily exclude it: it doesn't hurt at all 32 or 64-bit (both are "protected modes"). I wasn't talking bout 32Bit SW using 16Bit libraries, but about the HW implementation of both being so interconnected that they can't kill one without the other.

They are "interconnected" because they share a good part.

However you can completely drop the 8086 mode without affecting the 32-bit (protected) mode if you also drop the Virtual 8086 mode (which is supported by 32-bit mode). This is only because, again, someone could use this special 8086 mode for running multiple 8086 virtual machines transparently under the 32-bit mode.

Anyway, this is old stuff. If the goal is to have a "clean" 32-bit (and/or 64) mode without caring about all legacy 16-bit stuff, then the answer is yes: it's possible.


@V8

Quote:

V8 wrote: @cdimauro Quote: Quote: The open-source nature has it's good and bad sides. One potential risk, is that the CPU architecture ends up with as many variants as Linux has distros, effectively killing binary compatibility. It's not a risk: it's a reality. They started at the beginning with a plan having some extensions on specific fields/areas, and in the recent years they ended-up with several new "sub-extensions" to fix the mistake that they did. Absolutely. But this is not a bug, this is a feature. You will have many different extensions developed for different use cases in parallel. Most of them will be either too nieche to be generally useful or will turn out to not be a good idea once they are implemented in silicon and these features will become a dead-end and die off. This means greatly accelerated rate of innovation compared to "single thread of development, driven by commite consensus". But some of these features will turn out to be genuinely useful and then can be folded back into "upstream". This is similar to how people fork a github project and develop patches / features. Most of these forks turns out to be shit and eventually are forgotten, but some of them are genuinely useful and eventually end up as a pull request to upstream so everyone can benefit from it.

Dealing with forks on the open source world is already a mess, but on an architecture it's much worse, because you've to deal with different binaries (including support at compiler level).

Believe me: it's better to have (much) less fragmentation here, and only a few extensions specifically tailored to proper "macro areas". As it was originally planned (and announced with trumpets) for RISC-V.
Quote:

Quote: Quote: matthey wrote: RISC-V can scale down very well but I have doubts that it can scale up for competitive performance on desktops, laptops, pads, etc. RISC-V is basically MIPS with a few modern improvements and baggage from mistakes thrown away. I fully agree. I also agree with this. For the primary reason that I do not see any of the current stakeholders having much interest in pushing toward desktop/server class CPUs. That could change, for example if Apple suddenly decides this should be the basis for their next laptops.

There can a company that puts a lot of effort / money, but this will not change the fact that the RISC-V architecture has it's own limits that cannot be overcome: they are there to stay.

So, those design decisions will also limit the maximum performances that any microarchitecture based on this ISA can reach.


@MEGA_RJ_MICAL

Quote:

MEGA_RJ_MICAL wrote: ULTIMATE PADDING

@MEGA_RJ_MICAL

Quote:

MEGA_RJ_MICAL wrote: ZORRAM

Wasn't the previous supposed to be the last?

@matthey

Alibaba Cloud launches RISC-V developer platform for edge SoCs
https://www.theregister.com/2022/08/25/alibaba_riscv_developer_platform/

Alibaba Cloud Unveils Chip Development Platform to Support Developers with RISC-V based High-Performance SoCs
https://riscv.org/blog/2022/08/alibaba-cloud-unveils-chip-development-platform-to-support-developers-with-risc-v-based-high-performance-socs-alibaba-cloud/

Open design for the chip can be found here :
https://github.com/T-head-Semi/openc910

Ubuntu is already available :
https://ubuntu.com/download/risc-v

How about AM PI Zero v RISC-V Mango PI Benchmarks / costs comparisons?
https://bret.dk/raspberry-pi-zero-vs-mangopi-mq-pro-benchmarks/#compute-performance

Simplified Instruction Set Architecture Accelerates Chip Development—and Wins the 2022 Draper Prize
https://www.sciencedirect.com/science/article/pii/S2095809922005690


Quote:

An optimum RISC-V core is like a piston internal combustion engine (ICE).

Cars are more than adequate to get around! Extra nice because you can add more RISC-V engines without too many downsides :)

GPUs I will cover in a later post!

xe54 Quote:

Alibaba Cloud launches RISC-V developer platform for edge SoCs https://www.theregister.com/2022/08/25/alibaba_riscv_developer_platform/ Alibaba Cloud Unveils Chip Development Platform to Support Developers with RISC-V based High-Performance SoCs https://riscv.org/blog/2022/08/alibaba-cloud-unveils-chip-development-platform-to-support-developers-with-risc-v-based-high-performance-socs-alibaba-cloud/ Open design for the chip can be found here : https://github.com/T-head-Semi/openc910 Ubuntu is already available : https://ubuntu.com/download/risc-v How about AM PI Zero v RISC-V Mango PI Benchmarks / costs comparisons? https://bret.dk/raspberry-pi-zero-vs-mangopi-mq-pro-benchmarks/#compute-performance

China is aiming for low hanging fruit. Yes, the RPi Zero is indeed vulnerable to competition with higher performance as it uses the same 65nm Broadcom BCM2835 SoC as the original RPi. The Mango Pi RISC-V CPU overall outperforms the ARM1176JZF-S CPU but not by much considering the Mango Pi Allwinner D1 SoC uses a 22nm process.

https://linux-sunxi.org/D1

The ARM1176JZF-S CPU is doing amazing considering the 65nm vs 22nm disparity which is huge. From another perspective, the RISC-V XuanTie C906 CPU benchmark results are disappointing. The Chinese advertising is brilliant here though and we can see that they are willing to use open designs like RISC-V to reduce the chip cost and move to more expensive chip fab processes to compete better. Still, they likely lost this battle because they had to use a more expensive process so their product costs considerably more which is very important for embedded use and the weak RISC-V CPU showing allows the Raspberry Pi Foundation to easily fend off such market share attacks. Enter the RPi Zero 2 W using a similar 40nm Broadcom SoC as the RPi3.

https://picockpit.com/raspberry-pi/everything-about-raspberry-pi-zero-2-w/

This article about the Pi zero 2 W mentions retro gaming at the top and further down the RetroPi.

https://picockpit.com/raspberry-pi/everything-about-raspberry-pi-zero-2-w/ Quote:

Having said that, at a price tag of $ 15 US (+ taxes), it’s a wonderful little product, useful for lots of projects (yay, retro-gaming!). You also get to keep all the accessories you already bought for the Pi Zero W: they are (mostly) compatible.

At least the RPi retro gaming revenue is going to a better destination than Amiga lawsuits. Maybe retro gaming needs more performance than a 65nm ARM1176JZF-S CPU for the emulation tax that wastes so many resources. Cost is very important for embedded but the 50% increase in cost of the RPi Zero 2 W over the RPi Zero is partially offset by increased performance and features while the better fab process makes the power downgrade low (.4W vs .6W at idle but the same .7W when using USB WiFi for example). The RPi Zero 2 W uses the same ARM Cortex-A53 as the RPi3 while their Pico model with a home made RP2040 SoC covers very low power embedded use. The Chinese Mango Pi quad switched away from RISC-V to the ARM Cortex-A53 for a "potential competitor to the Raspberry Pi Zero W 2".

https://bret.dk/faster-mango-pi-mq-quad-on-the-way/

Maybe it is better to pay the license fees for a competitive and professional CPU core. The funny thing is that the ARM Cortex-A53 really isn't that great. In order RISC processors have notoriously poor performance and it struggles to support AArch64. A competitive in order RISC-V core would have the advantage of better code density as even the RISC-V XuanTie C906 supports RV64IMAFDCVU (the C stands for compressed) but that core would need a lot of work to improve performance and RISC-V has to execute more instructions to keep up with ARM AArch64 cores. Ironically, the 68060 has a better combination of code density and minimizing instructions than either of these RISC architectures while the in order CISC design is very strong for the resources used. One of the most demanding and popular retro gaming uses is for 68k (and chipset) emulation where native 68k support would improve competitiveness while using fewer resources. The Amiga could take advantage of the opportunity but Amiga businesses are too busy trying to take over the desktop market with outdated embedded PPC SoCs and nuking each other from orbit.

xe54 Quote:

Simplified Instruction Set Architecture Accelerates Chip Development—and Wins the 2022 Draper Prize https://www.sciencedirect.com/science/article/pii/S2095809922005690

That reminds me of the time the Motorola MPC601 won the 1994 Times Magazine "Products of the Year" award. This was a great marketing and political achievement as the CPUs were relabeled chips produced by IBM. That was pretty much the high point for the once great Motorola before steady decline into obscurity as they threw the 68k baby out with the bathwater and relied more on politics and farmed out development instead of innovation. The 68060 should have been their 1994 CPU product of the year but the political decisions were already made in the 1991 AIM alliance agreement. The lesson to be learned is pay attention to the competitiveness of products as politics can't make them competitive and don't count on marketing to save an inferior product.

xe54 Quote:

Cars are more than adequate to get around! Extra nice because you can add more RISC-V engines without too many downsides :) GPUs I will cover in a later post!

Piston engines are great for low performance, energy efficient and cheap use. Most people just need cheap transportation and there are speed limits. RISC-V cores are good for small weak cores that use little power and open hardware is a big advantage that will grow as more hardware becomes available. The simplicity that makes RISC-V appealing for weak embedded cores also makes it not as good for performance. Many simple parallel cores can't provide the performance needed because many tasks can't be broken apart into parallel workloads or aren't worth breaking up because they have a short execution time. Strong cores with good single core performance/MHz are desirable for a PC with a human waiting and they usually do more work per watt allowing them to go to sleep sooner. Simple parallel RISC cores can be good when processing mostly parallel workloads or where the cores are sleeping most of the time which is sometimes better for embedded use. ARM liked many simple in order parallel cores which can be good for advertising but they achieved greater success when they designed the complex AArch64 ISA and started making most of their CPU designs OoO boosting the single core performance, especially for RISC. There are no artificial speed limits or traffic to slow down processors so do you want the cheap and slow economy RISC CPU because you don't have much work to do or do you want a high performance beast that is thirsty but does a lot of work and gets it done fast?

Last edited by matthey on 27-Aug-2022 at 12:43 AM.
Last edited by matthey on 27-Aug-2022 at 12:35 AM.

@matthey

Fair assessment. It is the intention and desire that will drive the choices of hardware in future. The average person uses computers every day now - mostly for websites and videos - cover these basis and you have a market.

Parallel processing is more useful when the systems are networked and payloads distributed, though software can often break tasks into parallel chunks if they are not to be instantly executed - think encoding videos or archiving.

You mention a fast CPU is preferable, but if the RISC-V is fast enough for our needs then it will be sufficient. Wait a few years and optimisations will be evident. I would have agreed with you up until recently but now even a PI zero is capable of doing most of the things I need from a desktop - including all the things I could ever do on my AMIGA - as well as emulating an AMIGA! Once this runs fast enough on RISC-V it will likely be far cheaper too so I see a naturally occurring shift towards it.

The comparison with the Motorola chip for the prize is interesting but the most interesting thing is that RISC-V didn't do any advertising, they didn't make any grand claims or use insincere promotion. The chip won because there are no other interesting options to give the award to. Just looking at the uptake in RISC-V this year alone shows how competitive these products are - people will always buy cheaper variants of expensive products - manufacturers are the same - why pay more for a product than you have to?

What can move towards open source, will go there, due to capitalism (easier to do, cheaper, faster to manufacture). Microsoft couldn't stop the open-source movement and now embrace it... how long before windows runs on RISC-V too?

The sheer availability and ubiquity of these platforms will make the PI seem like an expensive and antiquated device. Also the way you can design the CPUs into the products at the FAB level is very interesting for hobbyists and short production-runs as it means you won't have to source so many components!

It is all very positive and exciting.

xe54 Quote:

Fair assessment. It is the intention and desire that will drive the choices of hardware in future. The average person uses computers every day now - mostly for websites and videos - cover these basis and you have a market. Parallel processing is more useful when the systems are networked and payloads distributed, though software can often break tasks into parallel chunks if they are not to be instantly executed - think encoding videos or archiving. You mention a fast CPU is preferable, but if the RISC-V is fast enough for our needs then it will be sufficient. Wait a few years and optimisations will be evident. I would have agreed with you up until recently but now even a PI zero is capable of doing most of the things I need from a desktop - including all the things I could ever do on my AMIGA - as well as emulating an AMIGA! Once this runs fast enough on RISC-V it will likely be far cheaper too so I see a naturally occurring shift towards it.

The RPi is pushing the point that not everyone needs a several hundred dollar CPU using billions of transistors for educational, hobby and PC use. CBM often marketed the Amiga with a CPU that cost a fraction of competitors as well. Adequate performance varies from customer to customer but has increased enough that even low performance embedded RISC CPUs may have tolerable performance. A small CPU saves chip area which saves cost but transistors are very cheap. Let's take a look at the RPi lineup starting with the cheapest to see what is adequate. The Raspberry Pi Pico RP2040 SoC uses a 32 bit Cortex-M0+ CPU that has a similar area to a 68000 yet only costs $1 and has customers lined up like Adafruit, Arduino, Pimoroni, Seeedstudio, Sparkfun and Lone Dynamics besides using it in the RPi Pico.

2x Cortex-M0+ 50,000x2=100,000 transistors
264kiB 6T SRAM=12,976,128 transistors

The 68060 used 2.5 million transistors so a quad core 68060 would use fewer transistors and could be produced for $1 if sold in similar volume. Many 68060 Amiga users love their 68060@100MHz using modern memory. Most 68k users would say that a 68060@100MHz is more than adequate performance but that RP2040 SoC uses an economical 40nm chip fab process that likely was chosen to maximize the transistors/$. The 68060 only used a 500nm process back in 1994 while the RP2040 40nm process is a little smaller than the 1st generation Intel Core i7 Processors that were clock rated for over 3GHz circa 2009. The old 68060 wafer size is outdated and would be cost prohibitive to produce but there are businesses which could convert the 68060 RTL or the gate level FPGA netlist to a new process like the 40nm process. A simple 68060 conversion to a 40nm process likely wouldn't guarantee 3GHz operation but 1GHz plus is certainly plausible especially considering the 68060 has an 8 stage pipleline length which was very deep back in 1994 but is optimal today for a CPU design that balances performance and power efficiency (the 68060 was also a balanced design). The popular Cortex-A53 CPU cores that the Raspberry Pi Zero 2 W switched to and that the Raspberry Pi 3 uses also has 8 stage pipeline.

Maybe the RP2040 SoC doesn't have adequate performance for low end PC use. It is clearly aimed at low power and cost embedded markets so that is likely true. The Cortex-A53 was one of the first ARM CPUs to support AArch64 and the cores are some of the smallest to support it. Supporting 64 bit only uses about 20% more transistors so the cost is relatively cheap over a 32 bit CPU but it struggles using 64 bit pointers and with the larger code which requires significantly larger caches. It's not unusual for the older 32 bit ISAs to have better performance on the Cortex-A53.

https://www.7-cpu.com/

It does often support ARM32, Thumb, Thumb 2 and AArch64 ISAs which gives it flexibility but the reason why the in order CPU is used is usually to minimize area/transistors to reduce the chip cost. The replacement for the Cortex-A53 is the in order Cortex-A55 which is available but the likely smaller and older Coretex-A53 is still often used. One of the major improvements was to reduce the performance killing load-use (load-to-use) penalty from 3 cycles to 2 cycles and separate load and store units which makes instruction scheduling easier and reduces the amount of instruction cache wasting loop unrolling necessary. The instruction cache was also changed from 2way to 4way set associative. All this points to the instruction fetch bottleneck of RISC and the challenge of instruction scheduling an in order RISC CPU. In comparison, the 68060 solves the RISC bottlenecks as it has no load-use penalty on loads to ALU use, has much better code density, has amazing performance without instruction scheduling and already has a 4 way set associative instruction cache. The high performance answer for RISC is to ditch in order CPUs and move to OoO execution CPUs which is what the Raspberry Pi 4 has done but OoO often doubles the area/transistors used while increasing power and heat so the Raspberry Pi 4 is only appropriate for heavy processing high end embedded use like the PPC used to be used for. With high volume production, there may not be much difference is price but half the area of an in order CPU can double the number of chips from a wafer compared to an OoO CPU. The ARM Cortex-A53 may be much more mature than the RISC-V XuanTie C906 CPU but it still leaves a lot to be desired for a small in order CPU. Give me a like clocked 68060, even missing some modern bolt-ons, any day compared to cheap and weak in order RISC CPUs.

Article which gets into the difficulty of instruction scheduling and obtaining performance from the in order ARM Cortex-A53 using "assembly" language that was supposed to be unnecessary with RISC compilers.

https://tech-blog.sonos.com/posts/assembly-still-matters-cortex-a53-vs-m1/

xe54 Quote:

The comparison with the Motorola chip for the prize is interesting but the most interesting thing is that RISC-V didn't do any advertising, they didn't make any grand claims or use insincere promotion. The chip won because there are no other interesting options to give the award to. Just looking at the uptake in RISC-V this year alone shows how competitive these products are - people will always buy cheaper variants of expensive products - manufacturers are the same - why pay more for a product than you have to?

This RISC-V award is all about big names like John Hennessy and David Patterson.

https://ict.iitk.ac.in/wp-content/uploads/CS422-Computer-Architecture-patterson-5th-edition.pdf

Quote:

RISC-V is one of many RISC-based ISAs, including ARM, created over the years, for which four individuals were awarded the 2022 Charles Stark Draper Prize in March. The moniker “Reduced Instruction Set Computer” reflects the aim of the prize recipients—Stephen B. Furber, professor of computer engineering at the University of Manchester, UK; John L. Hennessy, professor of computer science and electrical engineering at Stanford University in Palo Alto, CA, USA; David A. Patterson, professor emeritus at the University of California, Berkeley, USA; and Sophie M. Wilson, a Cambridge University, UK-trained computer scientist—and their many collaborators to build smaller, lower-power but better-performing processors by decreasing the complexity of the core set of executable instructions. With RISC-V, the result is a core of 47 instructions—paltry compared to x86’s 1000-some instructions and ARM’s roughly 500. And RISC-V is an extensible ISA, meaning that companies can implement the instruction set core and later expand it by adding defined extensions or creating their own to build bespoke processors.

Still the same RISC propaganda about "better-performing processors by decreasing the complexity of the core set of executable instructions". Nice highlighting the more complex x86 and ARM competition that is destroying them in performance in the 2nd round after destroying MIPS and SPARC in the 1st round. There are minor improvements this time and the open hardware (free stuff) approach may be enough to keep RISC-V alive for low end embedded use but the same failed RISC philosophies and propaganda are being recycled. RISC needs OoO execution for performance and that is anything but simple. Even OoO does not solve all RISC performance deficiencies but only reduces them.

The MPC601 (PPC 601) award was likewise arrogant thinking that PPC would be the replacement for x86 and 68k by political alliance and propaganda instead of based on evaluation and performance. Motorola thought they were winning until PPC disappointed due to shallow pipelines limiting how much the CPUs could be clocked up (deeper pipelines also provide more performance through instruction level parallelism). They liked the shallow PPC pipelines because they used fewer transistors/area, didn't produced as much heat, didn't have to have as good of branch prediction and there was less load-use penalty (usually only 1 cycle with the simple OoO used). Early PPC designs were more practical than Alpha designs which chose the opposite RISC philosophy of deeper pipelines and out clocking the competition (DEC bet the farm on the Alpha and fell). Desktop customers like Apple wanted more performance than the shallow PPC pipelines could provide so Motorola turned to more expensive chip fab processes than the competition with the small area PPC 603(e) with a 4 stage pipeline. Sound familiar for RISC competitors? PPC had a little better code density than most RISC ISAs but still had an instruction fetch bottleneck and needed large caches to increase performance but larger caches are slower also limiting clock increases. PPC eventually added multilevel caches innovated by DEC in the Alpha to keep L1 caches small and fast but at the time of the PPC601 there was not enough room on a reasonably priced chip for an L2. The PPC 601 already had double the cache size of the 68060 and Pentium yet similar performance. The 68060 with a 8 stage pipeline used fewer transistors than the PPC 601 with 4 stages so should have been more suitable for clocking up but the PPC 601 was quickly clocked up instead. The high clocking DEC Alphas like the 21064 line were pushing 300MHz with only a 7 stage pipeline but they were severely bottle necked by the horrible ISA code density and small instruction cache necessary to achieve such high clock speeds. The Pentium only had a 5 stage pipeline stretched to 6 for the Pentium with MMX but x86 didn't have the instruction bottleneck and achieved moderate clock speeds with chip process improvements. Compatibility, performance and practicality won the day for x86 even though the 68060 has much of the same traits and should have been ready to clock up more than the Pentium, PPC 601 or PPC 603(e).

xe54 Quote:

What can move towards open source, will go there, due to capitalism (easier to do, cheaper, faster to manufacture). Microsoft couldn't stop the open-source movement and now embrace it... how long before windows runs on RISC-V too? The sheer availability and ubiquity of these platforms will make the PI seem like an expensive and antiquated device. Also the way you can design the CPUs into the products at the FAB level is very interesting for hobbyists and short production-runs as it means you won't have to source so many components! It is all very positive and exciting.

Microsoft only embraces open source so far and Linux still hasn't taken over as the desktop OS. RISC-V CPU cores allow for only a small cost savings compared to ARM. ARM licensed IP is relatively cheap, updated and convenient. I don't foresee a full transition to RISC-V even for embedded use though it may dominate for deeply embedded use. I don't think RISC-V CPU designs will scale up to ARM AArch64 design performance either. Decreasing the complexity of the ISA is counterproductive for performance and RISC-V still promotes these ideas. Open hardware is a nice idea but an ISA which scales from embedded to high performance would be more useful. The 68k once scaled from embedded to workstation markets with dominance on everything but the desktop between because of the IBM PC mistake when choosing a CPU. Maybe we need Open68k(64).

Last edited by matthey on 27-Aug-2022 at 11:49 PM.
Last edited by matthey on 27-Aug-2022 at 11:23 PM.

@xe54

Quote:

xe54 wrote: @matthey You mention a fast CPU is preferable, but if the RISC-V is fast enough for our needs then it will be sufficient. Wait a few years and optimisations will be evident.

Maybe it wasn't clear-enough before, but the problems with RISC-V are INTRINSIC of this architecture and couldn't be fixed in some years and optimizations. They are its DESIGN decisions which crippled its performances as well.

Of course, you could get better performances over the time, but at the expense of more silicon & complexity. Compared to other solutions, like ARMv8+ and CISC processors.

However this is a general statement for RISCs vs CISCs: the former require much more resources to achieve better performances compared to the latter.

That's why I mostly agree with Matt's latest posts.


@matthey

Quote:

matthey wrote: Article which gets into the difficulty of instruction scheduling and obtaining performance from the in order ARM Cortex-A53 using "assembly" language that was supposed to be unnecessary with RISC compilers. https://tech-blog.sonos.com/posts/assembly-still-matters-cortex-a53-vs-m1/

LOL This I've to quote it, because it's really funny. Another RISC's pillar which is dismantled by the... reality.

Academics lived and still live on a parallel, ideal universe...

Quote:

Still the same RISC propaganda about "better-performing processors by decreasing the complexity of the core set of executable instructions".

But they don't count the instructions which are added, and still adding, on RISC-V processors: guess why... its the RISC propaganda!

Quote:

The 68k once scaled from embedded to workstation markets with dominance on everything but the desktop between because of the IBM PC mistake when choosing a CPU. Maybe we need Open68k(64).

Or, even better, a redesign of 68k in 32&64-bit fashion, which cleans-up the ISA and removes legacy stuff, some quirks as well, and makes it more modern & extensible & future-proof.

@cdimauro

Quote:

Maybe it wasn't clear-enough before, but the problems with RISC-V are INTRINSIC of this architecture and couldn't be fixed in some years and optimizations. They are its DESIGN decisions which crippled its performances as well.

It is 100% clear. I am not disagreeing. I am saying how fast do you need this to go? Already I have RISC-V boards that do 99% of the computing I need.

What do you need your computer to do faster?

Quote:

That's why I mostly agree with Matt's latest posts.

I also agree with Matt. ARM is better for almost everything CPU related at this stage. Although this isn't the year of linux desktop OS... it has been the year of linux on mobile for almost a decade. The whole world is moving towards ARM even for their desktops and I am happy with that arrangement. 20 years ago I was hearing arguments for how ARM would never be powerful enough to do that.

Licensing isn't as clear cut as he makes out however and the PICO is rather unique in that it was mass manufactured at huge scale and so has special licenses which unless we use the PICO as the basis for our projects (not a bad idea) then it is very likely that it would cost our bespoke project an awful lot more.

There are plenty of developments in the designs but just because something is difficult doesn't mean it won't be done. Schedulers being perfected in software now will likely be recreated in hardware later. It is still very early and entire board designs will evolve.

Quote:

Or, even better, a redesign of 68k in 32&64-bit fashion, which cleans-up the ISA and removes legacy stuff, some quirks as well, and makes it more modern & extensible & future-proof.

Good idea - you could use FPGA and RISC-V!
But seriously, this could be written to run on the PICO right now. OpenNEXT / BoXeR were just ahead of their time. You don't even need to remove the legacy stuff. A USB AMIGA is a cool project.

Quote:

But they don't count the instructions which are added, and still adding, on RISC-V processors: guess why... its the RISC propaganda!

These are designs to perform functions - not instructions added at the core level. This concept of open source designs is the key point everybody seems to be overlooking except Matt. Unless you are talking about the none-compliant implementations in which case those variations aren't RISC-V but instead built upon that as a foundation and no longer satisfy that interface - bespoke chips - governments for example may want their own cryptographically signed systems or video encoders may want licensed code added. Yes the license is that broad.

Will there be faster processors - yes
Will there be cheaper processors - likely yes
Will there be any license free processors - not many RISC-V is best bet right now
Will it be cheaper to develop boards than for ARM / PPC - yes
Will they be available? - more available than other chips due to fabrication not requiring licenses

Everybody is just parroting performance issues somehow not recognizing that the AMIGA we are talking about replacing was powered by the 68000 which ran at something like 2100 Dhrystones at 8 Mhz!

@xe54

Quote:

xe54 wrote: @cdimauro Quote: Maybe it wasn't clear-enough before, but the problems with RISC-V are INTRINSIC of this architecture and couldn't be fixed in some years and optimizations. They are its DESIGN decisions which crippled its performances as well. It is 100% clear. I am not disagreeing. I am saying how fast do you need this to go? Already I have RISC-V boards that do 99% of the computing I need. What do you need your computer to do faster?

It depends on the specific context / project / constraints.

The above that I've reported are /abstract generic considerations on the RISCs (RISC-V, specifically) vs CISCs quarrel.
Quote:

Quote: Or, even better, a redesign of 68k in 32&64-bit fashion, which cleans-up the ISA and removes legacy stuff, some quirks as well, and makes it more modern & extensible & future-proof. Good idea - you could use FPGA and RISC-V! But seriously, this could be written to run on the PICO right now. OpenNEXT / BoXeR were just ahead of their time. You don't even need to remove the legacy stuff. A USB AMIGA is a cool project.

Sorry, but that wasn't the idea. RISC-V could NOT be part of it, because Matt was talking of system based on an evolution of the 68k architecture.

And I was talking of something derived.

So, RISC-V has absolutely no place on that.
Quote:

Quote: But they don't count the instructions which are added, and still adding, on RISC-V processors: guess why... its the RISC propaganda! These are designs to perform functions - not instructions added at the core level.

Which is not correct: RISC-V has a base / common ISA, but also several extensions AKA group of instructions dedicated to specific scopes.

The base ISA is really simple and "RISC-like", but alone it isn't that much useful. In fact you can see yourself that most of RISC-V-based projects use several extensions.

Contrary to the academics propaganda, having few instructions is NOT enough for most of the computing needs. So, you need MORE (and more) specialized instructions that help. More means MANY, which is clearly against the R of Reduced Instruction Set Computer.

In fact and since several decades, RISCs integrate a lot of instructions, in spite of such academics and their stupid propaganda.
Quote:

This concept of open source designs is the key point everybody seems to be overlooking except Matt.

Matt isn't overlooking it. He knows and we know that being open source and with licenses is the key point of RISC-V and the reason which is getting so much consensus in the industry.

However this value is NOT the most important thing on an ISA / architecture and that's what Matt tried to say (and which I agree with).
Quote:

Unless you are talking about the none-compliant implementations in which case those variations aren't RISC-V but instead built upon that as a foundation and no longer satisfy that interface - bespoke chips - governments for example may want their own cryptographically signed systems or video encoders may want licensed code added. Yes the license is that broad. Will there be faster processors - yes Will there be cheaper processors - likely yes Will there be any license free processors - not many RISC-V is best bet right now Will it be cheaper to develop boards than for ARM / PPC - yes Will they be available? - more available than other chips due to fabrication not requiring licenses

See above. Those are different things.
Quote:

Everybody is just parroting performance issues somehow not recognizing that the AMIGA we are talking about replacing was powered by the 68000 which ran at something like 2100 Dhrystones at 8 Mhz!

That's what Matt likes to have: a much more powerful 68000 successor. Which can compete at least on the embedded market.

I share almost everything of Matt's vision beside continuing with the 68k family.

The reason for me is simply: it has bad design decisions which came from its time and the very limited experience of its architects.
IMO there is too much legacy and too many quirks which should be removed. That's why I propose a novel, 68k-inspired ISA, which could be partially 68k source-level compatible, which is easier to be implemented, more efficient, more modern and open to enhancements.

That's something which ARM already did with its ARMv8 AKA AArch64.
ARM was already successful with its ARM AKA ARMv2..7 architecture. And the same with its Thumb/-2 ISA extensions, which became a completely standalone ISA (independent from ARMv4..7).
As a company it had the need to design a 64-bit successor to meet the demands/needs of the market and its partners. But in this case it decided to create a completely new one, thanks to the lessons learned with its previous architectures. In fact, AArch64 isn't ARMv2..7/Thumb/-2 compatible. Albeit it has several similarities.
It was a risk, which ARM decided to take, and which is paying...

For RISC-V it was even easier, because the academics had a white paper available. So, absolutely no constraints. They designed this new architecture as they liked AND taking lessons of the 30+ years of experiences / examples of all other architecture designs.
However, they were/are academics and with their limited vision of the reality they crippled this ISA (and now they are trying to put some patches to have some fixes for them).

@cdimauro

A processor that is compatible with AMIGA at the core level, that is based on ARM and runs hundreds of times faster than the original already exists - PI Storm.

My suggestion (beyond my tongue in cheek suggestion of FPGA and RISC-V - total overkill for this) was the PICO which is an embedded version of the PI.

It's a good idea - it wont be as fast as the PI storm but it will boot instantly and still offer most of the other goodies.

Quote:

Which is not correct: RISC-V has a base / common ISA, but also several extensions AKA group of instructions dedicated to specific scopes. The base ISA is really simple and "RISC-like", but alone it isn't that much useful. In fact you can see yourself that most of RISC-V-based projects use several extensions.

You literally agreed with me - the base ISA doesn't change but extensions can be added. This isn't a weak point of the architecture and most of those extensions are also open source. The software for designing RISC-V chips and platforms is incredible and unique and will really open up people's eyes to the possibilities - extensions are like plugins in the CPU IDE! Want a real time clock? Add one with a click.

Just for the sheer accessibility RISC-V is having a surge in function and use and once the home dev kits arrive at good prices, it will great for hobbyists too.

@xe54

Quote:

A processor that is compatible with AMIGA at the core level, that is based on ARM and runs hundreds of times faster than the original already exists - PI Storm.

Its not compatible with Amiga at its core, PI Strom is a JIT compiler, it converts 68K code to ARM format, before executing, Lett me tell you it’s a lot of overhead compared to native code. And its not an Amiga, it mimics a CPU, not an Amiga system. That’s its advantage, emulation does less and so it's more efficient. You most likely plug into an ATARI, or 68K Macintosh.

Last edited by NutsAboutAmiga on 29-Aug-2022 at 04:11 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@xe54

Quote:

xe54 wrote: @cdimauro A processor that is compatible with AMIGA at the core level, that is based on ARM

What do you mean with compatible?
Quote:

and runs hundreds of times faster than the original already exists - PI Storm. My suggestion (beyond my tongue in cheek suggestion of FPGA and RISC-V - total overkill for this) was the PICO which is an embedded version of the PI. It's a good idea - it wont be as fast as the PI storm but it will boot instantly and still offer most of the other goodies.

Does PICO boots Linux?
Quote:

Quote: Which is not correct: RISC-V has a base / common ISA, but also several extensions AKA group of instructions dedicated to specific scopes. The base ISA is really simple and "RISC-like", but alone it isn't that much useful. In fact you can see yourself that most of RISC-V-based projects use several extensions. You literally agreed with me - the base ISA doesn't change but extensions can be added. This isn't a weak point of the architecture and most of those extensions are also open source. The software for designing RISC-V chips and platforms is incredible and unique and will really open up people's eyes to the possibilities - extensions are like plugins in the CPU IDE! Want a real time clock? Add one with a click. Just for the sheer accessibility RISC-V is having a surge in function and use and once the home dev kits arrive at good prices, it will great for hobbyists too.

No, I don't agree: we say different things.

As I've said before, the base RISC-V ISA is almost useless: only good for very very limited products.

To make it desirable for the embedded to the HPC market you need to add several extensions, or even some custom ones.

So, having a so basic ISA is just propaganda: on real applications you always need more functionalities (instructions) built in hardware.

The idea of a Reduced instruction set which is good for everything was simply ridiculous.


@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @xe54 Quote: A processor that is compatible with AMIGA at the core level, that is based on ARM and runs hundreds of times faster than the original already exists - PI Storm. Its not compatible with Amiga at its core, PI Strom is a JIT compiler, it converts 68K code to ARM format, before executing, Lett me tell you it’s a lot of overhead compared to native code. And its not an Amiga, it mimics a CPU, not an Amiga system. That’s its advantage, emulation does less and so it's more efficient. You most likely plug into an ATARI, or 68K Macintosh.

What's your point? We already know that emulation has an overhead.

However there aren't native processors with very high performances.

xe54 Quote:

A processor that is compatible with AMIGA at the core level, that is based on ARM and runs hundreds of times faster than the original already exists - PI Storm. My suggestion (beyond my tongue in cheek suggestion of FPGA and RISC-V - total overkill for this) was the PICO which is an embedded version of the PI. It's a good idea - it wont be as fast as the PI storm but it will boot instantly and still offer most of the other goodies.

The PiStorm RPi hardware is embedded hardware but the Broadcom SoCs target relatively high performance smart phones and similar devices. The RPi Pico embedded target is very low power and cost while performance is sacrificed. RPi 68k emulation takes a while to boot because even a minimalist Linux OS is not particularly fast to boot and often uses more resources than it should. The emulator then has to load and may have to warm up into the CPU caches. It would be possible to avoid some of this overhead which I believe michalsc is working on to boot directly into the 68k emulator. The RPi Pico has few resources and most OSs can not run in 264kiB of memory. The main memory is SRAM which is what most CPU caches use so it is super fast and avoiding bloated OSs indeed makes it fast to boot. The RPi Pico ARM Cortex-M0+ CPU cores are only 133MHz normally while allowing overclocking to 400MHz and these are relatively weak 2 stage cores only supporting some Thumb ISA encodings where some 68k emulators require AArch64. ARM gives 0.99 DMips/MHz but this is likely when using SRAM memory with no wait states like the RPi Pico and using a much newer fab process than 68k chips like the 40nm of the Pico RP2040 SoC.

https://developer.arm.com/Processors/Cortex-M0-Plus

The 68060 is 1.52+ DMIPS/MHz which was very good back in 1994. The RPi Pico does not have enough performance to emulate the 68060 with similar performance and likely not enough resources for JIT emulation. It could probably boot fast and emulate a 68020 but would require more work without an OS. The Amiga 1000 actually had a preemptive multitasking OS that worked with 256kiB of memory, which is less memory than the RPi Pico has. The Amiga 1200 had practically instant boot with a small PCMCIA flash card (NAND or NOR nonvolatile memory). The RPi Pico has no flash memory but supports fast external flash loading into SRAM. What the RPi Foundation successfully accomplished with the RPi Pico which is a small cheap low power SoC without an OS and with I/O, the Amiga could do with not much more resources but with a preemptive multitasking OS, GUI with video output and a library of Amiga software. An Amiga SoC for not much more cost offers much more but it doesn't work with emulation overhead wasting resources (a 68060+AGA SoC would use fewer transistors than the $1 Pico RP2040 SoC but more pins from external memory may increase cost). The 68k Amiga has a tiny footprint and was using it before ARM Thumb technology was born (from the 68k->SuperH->Thumb). The AmigaOS was designed to be very thin. Sadly, the Amiga has lost its way and become a fat niche desktop failure or a virtual device emulated on fat hardware.

If performance is not important, a cheap FPGA SoC gives practically instant on Amiga capabilities and boot without the hacks and resource overhead of emulation. The FleaFPGA Ohm was only $45 USD without mass production and supported up to a 68020 with AGA.

https://www.indiegogo.com/projects/fleafpga-ohm-fpga-experimenter-board#/



This is a similar cost to the PiStorm accelerator, at least until the Pi Zero 2 W is working. Performance would be better with say a $15 FPGA instead of $10 FPGA and mass production with no indegogo fees could have easily offset the price difference if not lowered. He could have advertised more but Amiga customers have been buying higher performance 68k Amiga hardware. Compatibility and convenience also seem to be important. Low price does not appear to be as important as value. I don't believe good enough performance is good enough for the Amiga market in general.

xe54 Quote:

You literally agreed with me - the base ISA doesn't change but extensions can be added. This isn't a weak point of the architecture and most of those extensions are also open source. The software for designing RISC-V chips and platforms is incredible and unique and will really open up people's eyes to the possibilities - extensions are like plugins in the CPU IDE! Want a real time clock? Add one with a click. Just for the sheer accessibility RISC-V is having a surge in function and use and once the home dev kits arrive at good prices, it will great for hobbyists too.

Yes, RISC-V is more customizable than most ISAs but it is a tradeoff. Leaving encoding space free for customization means RISC-V has fewer standard general purpose instructions that strengthen performance or improve code density. This is a good trade off for fine tuning low end or highly specialized embedded CPUs but not so good for competing with ARM AArch64 standardization and performance. I believe most developers would rather have better optimized compilers and software libraries that more standardization brings but AArch64 may have increased the hardware requirements too much and become too fat for many embedded uses in their desire to compete in performance with the super obese x86-64. Maybe RISC-V is too simple, weak and non-standardized for anything but low end and specialized embedded use but they can always introduce RISC-X and win some more awards if it not successful.

@matthey

Quote:

but they can always introduce RISC-X and win some more awards if it not successful.

Totally accurate post.

Quote:

If performance is not important, a cheap FPGA SoC gives practically instant on Amiga capabilities and boot without the hacks and resource overhead of emulation. The FleaFPGA Ohm was only $45 USD without mass production and supported up to a 68020 with AGA.

I still think FPGA is the way to go IMHO... 2 programmable FPGAs would be perfect... did you see the Analogue Pocket? Would love to see the AMIGA on there.

https://www.analogue.co/pocket

I own a MiST and it is incredible. Almost the perfect platform for me... if only I could expand it and add extra chips! I love all programmable chips though and wish more attached to computers - but I realise this is a personal thing and not common. The XENA chip was ultimately a massive disappointment for what seemed like an obvious easy win. There is plenty of demand for small programmable boards that accept inputs beyond keyboard and mouse and offer a balance of hardware and simple software.

But back on topic - the RISC-V platforms are still at the very early stages yet things are starting to move faster than ever on these fronts. It is an interesting time and if it can bring down the price of hardware as it's costs are increasing it will certainly be adopted by many.

My aim - as ever - is to see AMIGA running on as many platforms as possible!

xe54 Quote:

I still think FPGA is the way to go IMHO... 2 programmable FPGAs would be perfect... did you see the Analogue Pocket? Would love to see the AMIGA on there.

I already knew of the Analogue Pocket. FPGAs are adequate where CPU performance is unnecessary like emulating 8 bit CPUs. The FPGAs may be too small for the Amiga. There isn't much advantage for using 2 FPGAs. It may be useful for development as smaller FPGAs can be programmed faster and side by side comparisons with real chips can be useful for reverse engineering and debugging. A single FPGA is cheaper, provides more FPGA resources for the same cost, is more flexible as rewiring between what would be 2 chips is possible in the FPGA, there is usually reduced resources used by reusing resources and reduced transfer overhead. Also, the Analogue Pocket may have enough total FPGA resources for 68k plus chipset support but if the 68k core does not fit in one FPGA and the chipset core in the other FPGA then no Amiga support.

It is possible to license technology for eFPGA blocks on ASICs. This would be optimum for chipsets of retro consoles and computers but also for FPGA acceleration codecs (servers sometimes use FPGAs to accelerate specialized workloads). Most FPGAs require programming after powerup before they are functional but the CPU in an ASIC could be used for reprogramming. It may be possible to partition the eFPGA resources into units as resources which could be programmed from files which contain cores (maybe multiple adjacent eFPGA units could be allocated to provide more FPGA resources if needed). Maybe something like this could provide a multiple FPGA feature but I'm not sure it would be possible.

xe54 Quote:

I own a MiST and it is incredible. Almost the perfect platform for me... if only I could expand it and add extra chips! I love all programmable chips though and wish more attached to computers - but I realise this is a personal thing and not common. The XENA chip was ultimately a massive disappointment for what seemed like an obvious easy win. There is plenty of demand for small programmable boards that accept inputs beyond keyboard and mouse and offer a balance of hardware and simple software.

MiST is adequate for the Amiga but MiSTer is more expandable and has become the multi-system retro gold standard with the most support. It's much easier to support one FPGA board as every FPGA model and board requires some rework for the same FPGA core.

xe54 Quote:

But back on topic - the RISC-V platforms are still at the very early stages yet things are starting to move faster than ever on these fronts. It is an interesting time and if it can bring down the price of hardware as it's costs are increasing it will certainly be adopted by many. My aim - as ever - is to see AMIGA running on as many platforms as possible!

The standard Amiga CPU is 68k and there is no reason to downgrade performance and compatibility with a RISC-V CPU. The main CPU of the Amiga is not a good use for RISC-V. I would be looking into licensing the Imagination Technologies hybrid ray tracing GPU if I was making an Amiga SoC ASIC which likely uses an embedded RISC-V core. It is better than paying to license a CPU core from ARM for the GPU. This is a good example of where an open core shines and RISC-V is adequate for the job.

@matthey

https://www.youtube.com/watch?v=2ZAIIDXoBis

Sylvain has recently got Quake on an FPGA chip too

2 FPGAs are great, you can flash one to do custom chips from the other!
I'd like even more!

Quote:

The standard Amiga CPU is 68k and there is no reason to downgrade performance and compatibility with a RISC-V CPU. The main CPU of the Amiga is not a good use for RISC-V. I would be looking into licensing the Imagination Technologies hybrid ray tracing GPU if I was making an Amiga SoC ASIC which likely uses an embedded RISC-V core. It is better than paying to license a CPU core from ARM for the GPU. This is a good example of where an open core shines and RISC-V is adequate for the job.

Sounds awesome! Looking forward to seeing it!

Quote:

MiST is adequate for the Amiga but MiSTer is more expandable and has become the multi-system retro gold standard with the most support. It's much easier to support one FPGA board as every FPGA model and board requires some rework for the same FPGA core.

Wish it was more cost effective. Been saving for a DE board for a while... it can do PS1 and Saturn now

@matthey

Off topic I know, but for a PICO + FPGA board look no further than

https://github.com/mkvenkit/humble_ice/

Lots of fun!

@xe54

Quote:

I also agree with Matt. ARM is better for almost everything CPU related at this stage. Although this isn't the year of linux desktop OS... it has been the year of linux on mobile for almost a decade. The whole world is moving towards ARM even for their desktops and I am happy with that arrangement. 20 years ago I was hearing arguments for how ARM would never be powerful enough to do that.

Android is running on a Linux-based kernel with Google's userland layers. Google attempting to replace the Linux-based kernel with Fuchsia.

Google has 6-year limit support for ChromeOS/Chromebooks and about three OS upgrade cycle for Andriod.

Fragmentation in the ARM hardware ecosystem wouldn't replace the unified cloned X86 PC ecosystem.

For the C= Amiga hardware platforms, I'm only concerned about price, performance, and legacy software support. My Amiga 500 with PiStorm has outlived my unsupported doorstop Apple iPad Mini.

Last edited by Hammer on 08-Sep-2022 at 07:43 AM.
Last edited by Hammer on 08-Sep-2022 at 07:36 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)

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @xe54 Quote: A processor that is compatible with AMIGA at the core level, that is based on ARM and runs hundreds of times faster than the original already exists - PI Storm. Its not compatible with Amiga at its core, PI Strom is a JIT compiler, it converts 68K code to ARM format, before executing, Lett me tell you it’s a lot of overhead compared to native code. And its not an Amiga, it mimics a CPU, not an Amiga system. That’s its advantage, emulation does less and so it's more efficient. You most likely plug into an ATARI, or 68K Macintosh.

PI Storm is an adaptor board (with CPLD glue logic) between 68000 bus and RPi 3a's GPIO. 68K-ARM JIT is serviced by bare-metal Emu68 or Linux-hosted Muhashi software.

Emu68 also provides the P96 RTG pathway to Broadcom's VideoCore IV IGP.

Not including the missing AGA issue, PI Storm/RPi 3a/Emu68 blows away the performance on my A1200/TF1260 (with 68060 rev 1 @ 62.5Mhz). I'm also waiting for PiStorm32 for A1200.

Both my high school and university years have Apple Macs, hence I can relived those MacOS 7.x and 8.x era on Amiga Shapeshifter. Apple Macs labs usually have less demand from other students, hence I can use them for general internet, essays, and gaming between subjects.

PI Storm's concept that targets legacy external ISA with different CPU cores is similar to the concepts from AMD K5 (based on AM29K RISC), NexGen's Nx586 (RISC86)/AMD K6 (evolved RISC86), Intel Pentium Pro (P6), and Transmeta Code Morph Software VLIW-based Crusoe and Efficeon.

Larger companies packaged their solution in a single chip.

Solutions from AMD and Intel have extra decoders and microcoding engines that don't reduce compute resources on the actual CPU cores.

The goal, make legacy instruction sets run faster.

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

@Hammer

Quote:

Hammer wrote: PI Storm is an adaptor board (with CPLD glue logic) between 68000 bus and RPi 3a's GPIO. 68K-ARM JIT is serviced by bare-metal Emu68 or Linux-hosted Muhashi software. Emu68 also provides the P96 RTG pathway to Broadcom's VideoCore IV IGP. Not including the missing AGA issue, PI Storm/RPi 3a/Emu68 blows away the performance on my A1200/TF1260 (with 68060 rev 1 @ 62.5Mhz). I'm also waiting for PiStorm32 for A1200.

Is Emu68 supporting all 68k instructions, a PMMU, and 80-bit FPU precision?