Poster | Thread |
MEGA_RJ_MICAL
|  |
Re: RISC V Laptop announced... Could this be the ultimate AMIGA hardware? Posted on 8-Sep-2022 6:52:34
| | [ #121 ] |
|
|
 |
Super Member  |
Joined: 13-Dec-2019 Posts: 1200
From: AMIGAWORLD.NET WAS ORIGINALLY FOUNDED BY DAVID DOYLE | | |
|
| |
Status: Offline |
|
|
Hammer
 |  |
Re: RISC V Laptop announced... Could this be the ultimate AMIGA hardware? Posted on 8-Sep-2022 7:04:24
| | [ #122 ] |
|
|
 |
Elite Member  |
Joined: 9-Mar-2003 Posts: 6169
From: Australia | | |
|
| @cdimauro
Quote:
cdimauro wrote: @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?
|
Emu68's 68K MMU is disabled and it's an "open source" project, hence standard reply from open source advocates is to do it yourself .
With the microSD card change, I can reuse RPi 3a for the ARM Linux desktop with the Amiga 500 providing the power source. I have a wireless USB keyboard and mouse pad connected to RPi 3a. I have a 3D printed breakout panel for Amiga 500's expansion side panel that mounts an external microSD card reader and HDMI cable.
The Amiga (via VGA) and RPi 3a (via HDMI) are connected to a 15 kHz capable Dell 2311HB monitor (supports VGA 15 kHz, DVI, and DisplayPort inputs).
The Musashi MMU emulation is not complete, or completely accurate, hence anyone is welcome to improve it.
---- 64-bit double precision support is on my tolerance threshold.
When I looked at Apollo-Core's accelerator card offerings, they are at V2's 52-bit floating point precision. Later, Firebird V4's or IceDrake V4's 64-bit double precision support is acceptable.
Terasic Technologies P0037 Board, Dev, De0, FPGA Cyclone III has a $284 AU price range. https://au.element14.com/terasic-technologies/p0037/board-dev-de0-fpga-cyclone-iii/dp/2217597 Apollo-Core is overcharging.
Apollo-Core's accelerator card offerings can't run Linux.
Last edited by Hammer on 08-Sep-2022 at 07:25 AM. Last edited by Hammer on 08-Sep-2022 at 07:22 AM. Last edited by Hammer on 08-Sep-2022 at 07:17 AM. Last edited by Hammer on 08-Sep-2022 at 07:12 AM. Last edited by Hammer on 08-Sep-2022 at 07:07 AM.
_________________ Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68) Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68) Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB |
|
Status: Offline |
|
|
cdimauro
|  |
Re: RISC V Laptop announced... Could this be the ultimate AMIGA hardware? Posted on 8-Sep-2022 7:39:33
| | [ #123 ] |
|
|
 |
Elite Member  |
Joined: 29-Oct-2012 Posts: 4127
From: Germany | | |
|
| @Hammer
Quote:
Hammer wrote: @cdimauro
Quote:
cdimauro wrote: @Hammer
Is Emu68 supporting all 68k instructions, a PMMU, and 80-bit FPU precision?
|
Emu68's 68K MMU is disabled and it's an "open source" project, hence standard reply from open source advocates is to do it yourself . |
So no PMMU is available yet.
What about 68k instructions: are ALL of them supported? Quote:
64-bit double precision support is on my tolerance threshold. |
So no 80-bit FPU is supported.
P.S. Removed the padding. |
|
Status: Offline |
|
|
Hammer
 |  |
Re: RISC V Laptop announced... Could this be the ultimate AMIGA hardware? Posted on 8-Sep-2022 7:55:18
| | [ #124 ] |
|
|
 |
Elite Member  |
Joined: 9-Mar-2003 Posts: 6169
From: Australia | | |
|
| @cdimauro
Quote:
So no PMMU is available yet. |
Emulated 68K MMU is incomplete, but RPi 3i's Cortex A53 MMU is Linux proven.
The end user can enable the emulated 68K MMU and it has bugs.
Run Amiberry for 68K MMU.
Quote:
So no 80-bit FPU is supported. |
Run Amiberry. Last edited by Hammer on 08-Sep-2022 at 08:00 AM.
_________________ Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68) Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68) Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB |
|
Status: Offline |
|
|
cdimauro
|  |
Re: RISC V Laptop announced... Could this be the ultimate AMIGA hardware? Posted on 8-Sep-2022 18:13:03
| | [ #125 ] |
|
|
 |
Elite Member  |
Joined: 29-Oct-2012 Posts: 4127
From: Germany | | |
|
| @Hammer
Quote:
Hammer wrote: @cdimauro
Quote:
So no PMMU is available yet. |
Emulated 68K MMU is incomplete, but RPi 3i's Cortex A53 MMU is Linux proven. |
Of course the o.s. uses the MMU, however this cannot happen for any regular application. Maybe that's why Michal is working on an hypervisor. Quote:
The end user can enable the emulated 68K MMU and it has bugs.
Run Amiberry for 68K MMU. |
The topic was (PiStorm/)Emu68. Quote:
Quote:
So no 80-bit FPU is supported. |
Run Amiberry. |
The topic was (PiStorm/)Emu68. |
|
Status: Offline |
|
|
matthey
|  |
Re: RISC V Laptop announced... Could this be the ultimate AMIGA hardware? Posted on 9-Sep-2022 1:55:08
| | [ #126 ] |
|
|
 |
Elite Member  |
Joined: 14-Mar-2007 Posts: 2454
From: Kansas | | |
|
| xe54 Quote:
It's easy and cheap enough to put a SoC with CPU and FPGA on a board. The Humble iCE is a pretty humble (minimalist) board though. The FPGA is small but starts about $7 in quantity and the RP2040 is of course about $1. That leaves only the flash memory as costing much and maybe it gets dual purpose for loading (programming) the RP2040 SRAM and the FPGA. It likely could have been simpler with a smaller board if the flash memory was on the SoC. It may even have been cheaper in that case even though the SoC would have been more expensive. The flash memory could have had more lines in the SoC for higher higher performance and NOR flash that is addressable by the CPU could have been used (ROMs could have been placed in it and code executed from it saving SRAM and potentially booting faster). As is, the board is a versatile embedded device but retro use is more difficult. It could probably handle 8 bit system emulation/simulation but lacks video output and standard I/O. GPIO pins could probably handle a lot but hardware all wired together is not optimal as the MiSTer sandwich of boards demonstrates which needs cooling and has power issues (too long of HDMI cables can cause memory access errors for example). This would not be an easy board to get programmed and connected to other hardware either. It is cheap and likely the kind of bobby and embedded projects the RP2040 SoC was trying to encourage by pushing the price down. There is no RISC-V for now as ARM a la carte at least allowed the RPi Foundation to develop the board faster even though the lack of RISC-V licensing fees could allow them to push the price lower with the economies of scale of this SoC. They didn't know how successful the product would be before they produced it so RISC-V would have been a larger gamble. They are likely to stick with ARM as there are no RISC-V cores available as powerful as those in Raspberry Pi 4. They also have the UK retro Acorn computer angle which spawned ARM even though it is more educational than gaming. The Retro Amiga market, if getting competitive for hardware, doesn't have a choice but to develop the 68k although this avoids licensing fees and we have retro gaming appeal. As we see hear, it is not expensive to add FPGA capabilities, even if just for chipsets, to gain retro markets larger than the Amiga market.
|
|
Status: Offline |
|
|
Hammer
 |  |
Re: RISC V Laptop announced... Could this be the ultimate AMIGA hardware? Posted on 9-Sep-2022 13:56:31
| | [ #127 ] |
|
|
 |
Elite Member  |
Joined: 9-Mar-2003 Posts: 6169
From: Australia | | |
|
| @cdimauro
Quote:
Of course the o.s. uses the MMU, however this cannot happen for any regular application. Maybe that's why Michal is working on an hypervisor.
|
Emu68 is bare metal without Linux OS.
There are 68K FPU behavior differences between ARM-based Emu68 (I'm using Emu68-pistorm-20220905-bca29 nightly build) and X86-64-based WinUAE (I'm using version 4.9.1).
WinUAE's SoftFloat does not use any floating point numbers, everything uses integers with a separated 64-bit mantissa and 16-bit exponent.
For extended double precision requirements on X86-64 with AVX2 and AVX-512, this can be done with big integer AVX2 and AVX-512 numbers with minimal overheads.
For example, the sign64 register can be precomputed so only three instructions are necessary, hence adding four pairs of 128-bit numbers with AVX2 can be done with six instructions.
vpaddq vpaddq vpxor vpxor vpcmpgtq vpsubq
AVX512 has a single instruction for doing 64-bit unsigned comparison vpcmpuq, hence it should be possible to add eight pairs of 128-bit numbers using only four instructions
vpaddq vpaddq vpcmpuq vpsubq
With SSE, the only realistic option for this with SSE is from the AMD XOP instruction vpcomgtuq. vpaddq vpcomgtuq vpaddq vpsubq AMD removed XOP during Zen 1.0's introduction, but Zen 1.0 supports AVX2.
Extended double precision processing requirements can be worked around with 64bit CPUs that enable fast big numbers calculations.
There are differences between AArch32 NEON and AArch64 NEON, and I'm starting to look into the ARM hardware world instead of being an end-user bystander.
For about $150 AUD, PiStorm/Pi 3a/Emu68 has additional features and performance over Wicher 508i, Wicher 520EC, TF534/GottaGoFastRAM and TF536. Furthermore, PiStorm/Emu68 is open source, hence I can modify these PiStorm/Emu68 products If I'm motivated enough to do it.
Wake me up when Fire Phoenix v4 is offered between the $150 to $250 AUD price range.
In terms of evolution potential, PiStorm/Pi 3a/Emu68 has fewer restrictions compared to the transistor budgeted Fire Phoenix v4's Cyclone V.
I would rather see Apollo-Core offer standalone products that can support 3rd party Amiga 500/1200 accelerator products, hence copying Commodore's expandability feature from A500/A1200.
FPGA Minimig 1.8 already cloned A500's ability to support 3rd party Amiga 500 accelerator products, but it's missing AGA. The Amiga has unique characteristics that differentiate itself from other dead-end door-stop devices.
Quote:
The topic was (PiStorm/)Emu68. |
PiStorm/Emu68 doesn't work without RPi 3a or RPi Zero 2 W.
The preconfigured PiStorm/Pi 3a/Emu68 solution can be reused for another purpose. i.e. "RPi 3a" is also a standalone product.
Last edited by Hammer on 09-Sep-2022 at 02:12 PM. Last edited by Hammer on 09-Sep-2022 at 02:08 PM. Last edited by Hammer on 09-Sep-2022 at 02:02 PM.
_________________ Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68) Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68) Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB |
|
Status: Offline |
|
|
cdimauro
|  |
Re: RISC V Laptop announced... Could this be the ultimate AMIGA hardware? Posted on 9-Sep-2022 15:56:58
| | [ #128 ] |
|
|
 |
Elite Member  |
Joined: 29-Oct-2012 Posts: 4127
From: Germany | | |
|
| @Hammer
Quote:
Hammer wrote: @cdimauro
Quote:
Of course the o.s. uses the MMU, however this cannot happen for any regular application. Maybe that's why Michal is working on an hypervisor.
|
Emu68 is bare metal without Linux OS. |
I was recalling badly (since it runs on RPi). Nevermind.
Anyway, there seems to be no 68k PMMU implementation currently on Emu68. Neither 80-bit precision FPU. And maybe not all 68k instructions are implemented. Quote:
There are 68K FPU behavior differences between ARM-based Emu68 (I'm using Emu68-pistorm-20220905-bca29 nightly build) and X86-64-based WinUAE (I'm using version 4.9.1).
WinUAE's SoftFloat does not use any floating point numbers, everything uses integers with a separated 64-bit mantissa and 16-bit exponent.
For extended double precision requirements on X86-64 with AVX2 and AVX-512, this can be done with big integer AVX2 and AVX-512 numbers with minimal overheads. |
I don't recommend to use any SIMD unit for implementing 80-bit FP support: the regular integer/scalar instructions are much better from flexibility and performance PoV. |
|
Status: Offline |
|
|
agami
|  |
Re: RISC V Laptop announced... Could this be the ultimate AMIGA hardware? Posted on 10-Sep-2022 6:29:39
| | [ #129 ] |
|
|
 |
Super Member  |
Joined: 30-Jun-2008 Posts: 1897
From: Melbourne, Australia | | |
|
| |
Status: Offline |
|
|
cdimauro
|  |
Re: RISC V Laptop announced... Could this be the ultimate AMIGA hardware? Posted on 10-Sep-2022 7:18:13
| | [ #130 ] |
|
|
 |
Elite Member  |
Joined: 29-Oct-2012 Posts: 4127
From: Germany | | |
|
| @agami
Quote:
RISC-V isn't cool by definition. 
Anyway, this is the SoC: 32-bit RV32IMAC RISC-V “Bumblebee Core” @ 108 MHz https://www.sifive.com/cores/e24 CPU: 32-bit RV32IMAFC RISC-V “SiFive E24 Core” @ 144 MHz
Specifically: https://sifive.cdn.prismic.io/sifive/dc408861-94ce-4d82-a704-caddec98609d_e24_core_complex_manual_21G3.pdf The E2 execution unit is a single-issue, in-order pipeline. The pipeline comprises: Instruction Fetch, described in the previous section, Execute, and two stages of Write-back. The pipeline has a peak execution rate of one instruction per clock cycle.
The E24 Core Complex includes a 32-bit E2 RISC‑V core, which has an efficient, single-issue, in-order execution pipeline, with a peak execution rate of one instruction per clock cycle. The SiFive E2 core is guaranteed to be compatible with all applicable RISC‑V standards. The E2 core is configured to support the RV32I base ISA, as well as the Multiply (M), Atomic (A), Single-Precision Floating Point (F), Compressed (C), CSR Instructions (Zicsr), InstructionFetch Fence (Zifencei), Address Calculation (Zba), and Basic Bit Manipulation (Zbb) RISC‑V extensions. This is captured by the RISC‑V extension string: RV32IMAFC_Zicsr_Zifencei_Zba_Zbb. The base ISA and instruction extensions are described in Chapter 5. SiFive E24 Core Complex Manual Introduction 21G3.02.00 Copyright © 2018–2022 by SiFive, Inc. All rights reserved. 18 The E2 also supports machine and user privilege modes, in conjunction with Physical Memory Protection (PMP), thereby allowing System-on-Chip (SoC) implementations to make the right area, power, and feature trade-offs. The E2 core provides a flexible memory system that includes standards-based configurable bus interfaces, and memory maps that provide a lot of flexibility for SoC integration. The E2 includes an IEEE 754-2008 compliant Floating-Point Unit.
Basically they are using a monster for a... soldering pen! 
It's interesting to notice that this RISC-V core embeds A LOT of extensions, which means A LOT of instructions AND functional units AND control registers.
Could someone tell me where the R of RISC is located here? 
Finally, to me this shows that a 68k or some other CISC (mine ) could have something to say on the embedded market. Especially when I read this:
The number of stall cycles between a load instruction and the use of its result is equal to the number of cycles between the bus request and bus response. In particular, if a load is satisfied the cycle after it is demanded, then there is one stall cycle between the load and its use. In this special case, the stall can be obviated by scheduling an independent instruction between the load and its use. |
|
Status: Offline |
|
|
xe54
|  |
Re: RISC V Laptop announced... Could this be the ultimate AMIGA hardware? Posted on 10-Sep-2022 11:22:24
| | [ #131 ] |
|
|
 |
Regular Member  |
Joined: 16-Feb-2005 Posts: 122
From: Unknown | | |
|
| @agami
It is very cool. A lot of electronics are needed to maintain a consistent temp for portable soldering irons - I have a few re-programmable ones already - but this is the first RISC-V one that I've seen! Love how open it is!
With no license and and pre-fabbed designs RISC-V is perfect for these applications - suggesting inefficiencies for these devices compared with other technologies is abstract and unnecessary.
Saying that it is inefficient is missing the point entirely. What do you need, a faster soldering iron?
As for using 68K for this? The sheer cost of making a custom 68k board to run a soldering pen's brains would cost more than all the profit they could ever make.
The reason people use these chips is because they are cheap to design, cheap to manufacture and are performant enough for the functions they are tasked for. Do they have extra instructions and extensions, perhaps yes, but certainly fewer than chipsets with licensed parts and there is nothing to stop you from removing them due to the license if you don't need them!
Pine are a great company and I applaud their work in all of their products. If every AMIGA dev got involved in making software work for existing platforms such as their OpenPhone - rather than arguing about which hardware to make for the future versions - we wouldn't have to have these weird conversations and would already have an AMIGAPhone.
There are lots of suitable platforms for us already.
RISC-V is coming to all these embedded devices, it is that just much more affordable. Get involved or get left behind. |
|
Status: Offline |
|
|
BigD
|  |
Re: RISC V Laptop announced... Could this be the ultimate AMIGA hardware? Posted on 10-Sep-2022 12:38:58
| | [ #132 ] |
|
|
 |
Elite Member  |
Joined: 11-Aug-2005 Posts: 7472
From: UK | | |
|
| @MEGA_RJ_MICAL
Quote:
MEGA_RJ_MICAL wrote: ZORRAM LAPTOP ANNOUNCED
|
Yep, but it is spelt with one 'R' (Violent Ken just can't spell) and is limited to 128MB of Ram! _________________ "Art challenges technology. Technology inspires the art." John Lasseter, Co-Founder of Pixar Animation Studios |
|
Status: Offline |
|
|
MEGA_RJ_MICAL
|  |
Re: RISC V Laptop announced... Could this be the ultimate AMIGA hardware? Posted on 10-Sep-2022 12:46:59
| | [ #133 ] |
|
|
 |
Super Member  |
Joined: 13-Dec-2019 Posts: 1200
From: AMIGAWORLD.NET WAS ORIGINALLY FOUNDED BY DAVID DOYLE | | |
|
| |
Status: Offline |
|
|
xe54
|  |
Re: RISC V Laptop announced... Could this be the ultimate AMIGA hardware? Posted on 10-Sep-2022 15:52:38
| | [ #134 ] |
|
|
 |
Regular Member  |
Joined: 16-Feb-2005 Posts: 122
From: Unknown | | |
|
| @MEGA_RJ_MICAL
2 more weeks... |
|
Status: Offline |
|
|
Hammer
 |  |
Re: RISC V Laptop announced... Could this be the ultimate AMIGA hardware? Posted on 11-Sep-2022 0:19:23
| | [ #135 ] |
|
|
 |
Elite Member  |
Joined: 9-Mar-2003 Posts: 6169
From: Australia | | |
|
| @cdimauro
Quote:
I was recalling badly (since it runs on RPi). Nevermind.
Anyway, there seems to be no 68k PMMU implementation currently on Emu68. Neither 80-bit precision FPU. And maybe not all 68k instructions are implemented.
|
PiStorm has options with Emu68 and Linux-hosted Musashi 68k. Musashi has the 68K MMU option and it's not accurate.
Worst case, run Amiberry on RPI 3a with the Amiga providing the power source and enclosed case for RPi 3a.
https://youtu.be/SrKUrkQ_qTs?list=PL9f_2h3YeEIbI0gE0VMg5C7a9Ae6inFU8&t=445 PiStorm/Emu68 can run the "We Come In Peace" demo test.
https://www.youtube.com/watch?v=iGJAI00AYjQ&t=826s PiStorm/Emu68 can run the "Quake II" PC port game.
For Shapeshifter, Emu68's FPU must be disabled since it has the scroll bar bug. i.e. I run CoffinOS R58's ShapeShifter MacOS 8.1 setup with the nightly Emu68-pistorm-20220905 build. My own ShapeShifter MacOS 8.0 setup (from A1200/TF1260) has a similar scroll bar bug on PiStorm/Emu68 (20220905 build). CoffinOS R58's ShapeShifter MacOS 7.5.5 setup is okay.
With Shapeshifter, WInUAE's host FP64 mode has a different behavior from Emu68's FPU. Quote:
I don't recommend to use any SIMD unit for implementing 80-bit FP support: the regular integer/scalar instructions are much better from flexibility and performance PoV.
|
SIMD example is for native code that can exploit very wide SIMD.
Amiga's FP80 is scalar.
Last edited by Hammer on 11-Sep-2022 at 02:19 AM. Last edited by Hammer on 11-Sep-2022 at 12:26 AM. Last edited by Hammer on 11-Sep-2022 at 12:25 AM.
_________________ Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68) Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68) Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB |
|
Status: Offline |
|
|
matthey
|  |
Re: RISC V Laptop announced... Could this be the ultimate AMIGA hardware? Posted on 11-Sep-2022 1:09:38
| | [ #136 ] |
|
|
 |
Elite Member  |
Joined: 14-Mar-2007 Posts: 2454
From: Kansas | | |
|
| cdimauro Quote:
Basically they are using a monster for a... soldering pen! 
|
The Bumblebee core is using only a 2 stage in order 32 bit scalar CPU. The SiFive E24 core is using a 3 stage in order 32 bit scalar CPU but I don't know what it has to do with the Bumblebee core in the soldering iron. I would think a 16 bit CPU would be more than adequate and still easy to work with while saving area and power. There is likely not much code so main memory is probably SRAM or NOR flash which I would think would have plenty of bandwidth but the RISC-V compression may allow the size to be reduced. A $1 RP2040 "Pico" SoC would likely be adequate but doesn't have flash built in so there may be better choices.
cdimauro Quote:
It's interesting to notice that this RISC-V core embeds A LOT of extensions, which means A LOT of instructions AND functional units AND control registers.
Could someone tell me where the R of RISC is located here? 
|
Only 2 pipeline stages is a must to save area and power but 32 bit, 100+MHz and all these extensions are priceless! RISC at its finest! A 1979 68000 would do the job and even comes with compression although a smaller package than original would be needed.
cdimauro Quote:
Finally, to me this shows that a 68k or some other CISC (mine ) could have something to say on the embedded market. Especially when I read this:
The number of stall cycles between a load instruction and the use of its result is equal to the number of cycles between the bus request and bus response. In particular, if a load is satisfied the cycle after it is demanded, then there is one stall cycle between the load and its use. In this special case, the stall can be obviated by scheduling an independent instruction between the load and its use. |
Yea, the RISC answer to avoid the load-to-use stalls is to add more registers and unroll the code filling the bubbles which bloats it more but embedded systems want to reduce the registers and memory. This is why CISC, and especially the 68k, were so popular for embedded. Full performance, compressed code and no load-to-use stalls for a basic and common load to ALU. The 1 cycle load-to-use stall is not even that bad due to the shallow pipeline. PPC also used shallow pipelines, relatively low clock speeds and weak OoO to usually minimize load-to-use penalties to 1 cycle, at least early PPC CPUs like 601, 603 and 604. In order RISC CPUs suffer from it like the 3 cycle load-to-use stall of the ARM Cortex-A53 which is one of the most most popular CPUs in the world right now due to minimizing area and power. The successor ARM Cortex-A55 lowered the load-to-stall to 2 cycles showing how important it is to performance but it is larger area so the A53 is still commonly used. A 64 bit CISC CPU with better performance and code density than AArch64 and competitive area and power draw would be very appealing indeed. Basically like a 68060 competed back in the day with 32 bit CPUs. Well, it won't come from Freescale/NXP as they would rather pay licensing fees to ARM for a la carte custom SoCs than design anything new.
Last edited by matthey on 11-Sep-2022 at 01:13 AM.
|
|
Status: Offline |
|
|
cdimauro
|  |
Re: RISC V Laptop announced... Could this be the ultimate AMIGA hardware? Posted on 11-Sep-2022 4:50:18
| | [ #137 ] |
|
|
 |
Elite Member  |
Joined: 29-Oct-2012 Posts: 4127
From: Germany | | |
|
| @Hammer
Quote:
Hammer wrote: @cdimauro
Quote:
I was recalling badly (since it runs on RPi). Nevermind.
Anyway, there seems to be no 68k PMMU implementation currently on Emu68. Neither 80-bit precision FPU. And maybe not all 68k instructions are implemented.
|
PiStorm has options with Emu68 and Linux-hosted Musashi 68k. Musashi has the 68K MMU option and it's not accurate. |
Musashi is slow. That's why people uses Emu68. Quote:
Worst case, run Amiberry on RPI 3a with the Amiga providing the power source and enclosed case for RPi 3a. |
Amiberry is also slower than Emu68. Quote:
It doesn't generate many FPS, but it's quite playable. Quote:
For Shapeshifter, Emu68's FPU must be disabled since it has the scroll bar bug. i.e. I run CoffinOS R58's ShapeShifter MacOS 8.1 setup with the nightly Emu68-pistorm-20220905 build. My own ShapeShifter MacOS 8.0 setup (from A1200/TF1260) has a similar scroll bar bug on PiStorm/Emu68 (20220905 build). CoffinOS R58's ShapeShifter MacOS 7.5.5 setup is okay.
With Shapeshifter, WInUAE's host FP64 mode has a different behavior from Emu68's FPU. |
Strange. Both are using 64-bit FP. Quote:
Quote:
I don't recommend to use any SIMD unit for implementing 80-bit FP support: the regular integer/scalar instructions are much better from flexibility and performance PoV.
|
SIMD example is for native code that can exploit very wide SIMD.
Amiga's FP80 is scalar. |
That's why I've said that it's better to use the regular GP/"Integer"/Scalar instructions for implementing the 80-FP operations.
Using the SIMD unit complicates the implementation and makes it also slower since it'll use the scalar versions of those instructions (so, the packed ones aren't used). And I doubt that it's possible to exploit the usage of packed instructions (it's possible in theory, but requires a lot of work for the JIT). |
|
Status: Offline |
|
|
cdimauro
|  |
Re: RISC V Laptop announced... Could this be the ultimate AMIGA hardware? Posted on 11-Sep-2022 5:04:04
| | [ #138 ] |
|
|
 |
Elite Member  |
Joined: 29-Oct-2012 Posts: 4127
From: Germany | | |
|
| @matthey
Quote:
matthey wrote: cdimauro Quote:
Basically they are using a monster for a... soldering pen! 
|
The Bumblebee core is using only a 2 stage in order 32 bit scalar CPU. The SiFive E24 core is using a 3 stage in order 32 bit scalar CPU but I don't know what it has to do with the Bumblebee core in the soldering iron. |
Indeed. The documentation looks wrong. Quote:
cdimauro Quote:
It's interesting to notice that this RISC-V core embeds A LOT of extensions, which means A LOT of instructions AND functional units AND control registers.
Could someone tell me where the R of RISC is located here? 
|
Only 2 pipeline stages is a must to save area and power but 32 bit, 100+MHz and all these extensions are priceless! RISC at its finest! A 1979 68000 would do the job and even comes with compression although a smaller package than original would be needed. |
I agree. The only thing which is not know is how many transistors are required for such RISC-V implementation, to make a comparison with the 68000.
Another thing is that I don't know if the original 68000 could be reimplemented using less transistors, because micro-architecture engineers may have acquired a better knowledge / technologies after 44 years. Quote:
cdimauro Quote:
Finally, to me this shows that a 68k or some other CISC (mine ) could have something to say on the embedded market. Especially when I read this:
The number of stall cycles between a load instruction and the use of its result is equal to the number of cycles between the bus request and bus response. In particular, if a load is satisfied the cycle after it is demanded, then there is one stall cycle between the load and its use. In this special case, the stall can be obviated by scheduling an independent instruction between the load and its use. |
Yea, the RISC answer to avoid the load-to-use stalls is to add more registers and unroll the code filling the bubbles which bloats it more but embedded systems want to reduce the registers and memory. This is why CISC, and especially the 68k, were so popular for embedded. Full performance, compressed code and no load-to-use stalls for a basic and common load to ALU. The 1 cycle load-to-use stall is not even that bad due to the shallow pipeline. PPC also used shallow pipelines, relatively low clock speeds and weak OoO to usually minimize load-to-use penalties to 1 cycle, at least early PPC CPUs like 601, 603 and 604. In order RISC CPUs suffer from it like the 3 cycle load-to-use stall of the ARM Cortex-A53 which is one of the most most popular CPUs in the world right now due to minimizing area and power. The successor ARM Cortex-A55 lowered the load-to-stall to 2 cycles showing how important it is to performance but it is larger area so the A53 is still commonly used. |
Interesting. That's why the A53 is so much used: it's the best selling ARM core. Quote:
A 64 bit CISC CPU with better performance and code density than AArch64 and competitive area and power draw would be very appealing indeed. Basically like a 68060 competed back in the day with 32 bit CPUs. |
I agree and was/is my hope. But see below. Quote:
Well, it won't come from Freescale/NXP as they would rather pay licensing fees to ARM for a la carte custom SoCs than design anything new. |
I also talked recently with a friend of mine which is working at STMicroelectronics (automotive area / products) and it seems that the company has also no interest at all on developing its own architectures (whereas it had some when I joined the company for my internship + thesis. Notably, the LX, which my responsible used to simulate my JPEG 2000 decoder implementation for their embedded market).
All companies seem to have given-up in favor of ARM. A now RISC-V as well. They prefer off-the-shelf designs, which could be directly used as they need, with no costs other than licenses.
It makes sense from some perspective, but it's quite depressing since everything seems to be flat and creativity is killed (no chance for better products to be developed). |
|
Status: Offline |
|
|
kolla
|  |
Re: RISC V Laptop announced... Could this be the ultimate AMIGA hardware? Posted on 11-Sep-2022 6:45:43
| | [ #139 ] |
|
|
 |
Elite Member  |
Joined: 20-Aug-2003 Posts: 3357
From: Trondheim, Norway | | |
|
| There’s nothing creative about the idea of reimplementing 68k on asic. _________________ B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC |
|
Status: Offline |
|
|
cdimauro
|  |
Re: RISC V Laptop announced... Could this be the ultimate AMIGA hardware? Posted on 11-Sep-2022 7:00:57
| | [ #140 ] |
|
|
 |
Elite Member  |
Joined: 29-Oct-2012 Posts: 4127
From: Germany | | |
|
| @kolla
Quote:
kolla wrote: There’s nothing creative about the idea of reimplementing 68k on asic. |
I was talking about new ISAs (included a 64-bit version of the 68k; which would be clearly incompatible like x86-64 is incompatible with IA-32). |
|
Status: Offline |
|
|