@OneTimer1

We are talking about new SoC Power based in development. The team is looking for collaborations for everyone skilled in CPU / GPU / VPU design.

FPGA is a starting point for the initial Microwatt core implementation. The subsequent step is the ASIC implementation.

_________________
retired

Quote:

AmigaBlitter wrote: We are talking about new SoC Power based in development.

Dying platform, replaced by ARM SoC in most appliences.

Quote:

AmigaBlitter wrote: The team is looking for collaborations for everyone skilled in CPU / GPU / VPU design.

There is no team at least no one with skills in hard- and software or with money.


Quote:

FPGA is a starting point for ...

No, it is a possible target point for hardware emulation, the only way that is left when no one sees a real chance for mass produced hardware.

And seeing what happens when the SoC doesn't has the right kind of FPU for your target OS, should make you more realistic.

Last edited by OneTimer1 on 13-Feb-2021 at 04:22 PM.

@OneTimer1

Quote:

There is no team at least no one with skills in hard- and software or with money.

You know that project is destined for greatness when you find gems like this from developer list written by the leader.

Quote:

Q: do you understand or know what OP_SC is or does? A: i don't... and don't care, and it is completely irrelevant to you, as well. (it's *optional* to have understanding: you may *desire* understanding, you may *like* to have understanding, but it is, fundamentally, *completely irrelevant* to the actual task) Q: do we *need* to understand or know what OP_SC is or does? A: no we do not. Q: will it work? A: yes it will. Q: will there be bugs? A: most probably, and those can be found with unit tests. Q: do absolutely all the required unit tests have to be written *right now*? A: no they do not. Q: do we need to freeze and lock up solid in total fear at our total and complete lack of understanding just because those unit tests do not exist? A: of course not. so reading a 1300 page PDF is completely and utterly pointless. and making reading that 1300 page PDF a hard, fixed, absolute critical dependency on *completing this task* is a false assumption, isn't it?

@thread

A Power CPU from 1990 on mars

https://www.techtimes.com/articles/257542/20210301/nasa-mars-perseverance-sports-1990-imac-powerpc-750-withstand-sun.htm

_________________
retired

@AmigaBlitter

The article probably means from 1990s (there is a typo). The actual CPU is RAD750 from 2001.

@Rose

Holy cow.
That's so crazy it could have easily been written by half the Amiga user base.

The fact that the latest Perseverance rover on Mars uses a special radiation and temperature resilient variant of the famed G3 PowerPC CPU tells you everything.

PowerPC was an effort, rightfully applauded at the time, to bring RISC-based computing into the mainstream. High-end RISC platforms of the day were pretty much relegated to the workstation and server markets, and a confluence of disparate needs was the hope to take a slice of that growing consumer PC pie.

There were some smart people at Apple, IBM, and Motorola who saw the potential in delivering such a platform through the combination of each other’s strengths and market problems. Unfortunately, the combination of IBM’s greed, Apple’s mismanagement, and Motorola’s narrowly focused capability around design and fabrication, was the bad that came with good.

In many ways, the recipe under which the PowerPC was baked, doomed it from the start. Though no one would admit it at the time, despite early signs that the technically sound alliance was not going to work in a commercial sense.

The return of Steve Jobs, and the singular focus on rescuing Apple was another nail in the coffin that was being prepared for PowerPC in the mainstream. Though some would only see the success of the iMac G3, the TiBook G4, and the 64-bitness of the G5, this was Apple (Jobs) making the best of a bad situation. And thanks to Avie Tevanian and his team, it was a situation that Jobs was going to get out of as soon as practicable.

As with most things, there’s no one culprit in the demise of the Power platform. IBM did its usual thing, and its uncertain if it would’ve made a difference if they’d open sourced it with the release of Power 7. Jobs chose the growth of Apple over the growth of a common platform to compete with increasing x86 dominance. And Motorola didn’t really have a dog in that race so it followed the money and was happy to be a dominant force in the embedded market. They came together for one purpose, but they all pulled in different directions.

So you see, the PowerISA as a mainstream platform is not only dead, it’s been dead for a long time. Shortly after birth some might say. And while there are still millions of MCUs in all sorts of devices, and it’s the legacy platform for highly specialized extreme computing requirements like military and space systems, the glorious comeback of PowerISA into the mainstream is only a dream inside the minds of a shrinking cadre of fans.

Last edited by agami on 07-Mar-2021 at 11:33 AM.
Last edited by agami on 07-Mar-2021 at 11:32 AM.

_________________
All the way, with 68k

@thread

https://openpowerfoundation.org/openpower-foundation-provides-microwatt-for-fabrication-on-skywater-open-pdk-shuttle/

_________________
retired

@AmigaBlitter

Quote:

AmigaBlitter wrote: @thread https://openpowerfoundation.org/openpower-foundation-provides-microwatt-for-fabrication-on-skywater-open-pdk-shuttle/

Translation: "We are going to make very simple PPC with 2001 state of the art 130 nm process"

@thread

OpenPOWER ISA co-simulation test suite with its own built-in OpenPOWER ISA Simulator.

https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=NEWS.txt;h=b6e803833d4de57f11ee4f5dc5a014237bea90d0;hb=90116cefabd7869169bcf8e7f1c97e95284969f9

_________________
retired

@AmigaBlitter

Guy who thinks that understanding ISA is irrelevant makes a test suite, what could go wrong...

Must be that time of year that LKCL must show to grant board "Look! We are making progress!"

@OneTimer1

Quote:

Dying platform, replaced by ARM SoC in most appliences.

And Risc-V is putting some dents in ARM's marketshare. The Nvidia thing brings some question marks into the ARM universe as well. Any fracturing of the ARM situation can be an opportunity. I think that if the Nvidia buyout does complete, then that would be a good thing for Power.

_________________
All glory to the Hypnotoad!

@billt

Quote:

billt wrote: @OneTimer1 Quote: Dying platform, replaced by ARM SoC in most appliences. And Risc-V is putting some dents in ARM's marketshare. The Nvidia thing brings some question marks into the ARM universe as well. Any fracturing of the ARM situation can be an opportunity. I think that if the Nvidia buyout does complete, then that would be a good thing for Power.

Rumour says that nVidia wants to make a mother of all ARM cpu's for future DGX to be building block for relatively affordable super computers. And thats going to eat marketshare from Power.

billt Quote:

And Risc-V is putting some dents in ARM's marketshare. The Nvidia thing brings some question marks into the ARM universe as well. Any fracturing of the ARM situation can be an opportunity. I think that if the Nvidia buyout does complete, then that would be a good thing for Power.

Assuming the Nvidia buyout of ARM opens up opportunities in the market, isn't POWER in a different market? The Libre project is one research project using POWER for embedded hardware with some weird extensions like a variable length encoding for CPU/GPU vector processors. At least RISC-V is focused on the embedded market and uses a variable length encoding to try to improve code density. POWER/PPC fans will likely say that code density doesn't matter but it has been the ISAs with the best code density which have dominated the embedded market starting with the 68k.

68k baseline
Thumb2 +2% code size
SuperH +16% code size
x86-64 +31% code size
RISCV64IMC +34% code size
AArch64 +50% code size
PPC +81% code size
MIPS +85% code size
SPARC +93% code size

Is it a coincident that the 68k, SuperH and then ARM Thumb2 cores were the best selling 32 bit cores in the embedded market? Can we see why Motorola lost the embedded market when they stopped developing the 68k and forced PPC into the embedded market? Do you still think POWER/PPC has an opportunity in the embedded market because of Nvidia buying ARM? Can we see that RISC-V would have an opportunity because of lack of code density competition?

@matthey

I'm curious where your code size numbers came from, and what codesets were measured. Do you have any links?

_________________
All glory to the Hypnotoad!

@matthey

Don't worry about code size, IMHO is much more important instruction efficiency and how many transistors are needed to make it work.
All weird old instructions complexity and addressing modes jungle are part of past.
I have always thought simpler is better, so as example I really don't understand why to mask load stores to memory with complex instructions. We all know memory modules doesn't execute any instruction, but in most old cpus you can make math on memory addresses.
All compilers will never use full potential of complex addressing modes or some fancy instructions.
We have still a lot of difficulty to use today simd units, major part of coders does not use assembly and some cpu tricks to gain speed are never used.

Simplicity is better, always! ..so if we want make theory it's better to start think different and go far ahead old cpu designs.
Look at new apple silicon chips, it outperform any other cpu considering whole efficiency.
It's a new design, it's fast, it's cold, it's low power, it's cheap, it's simple, it's arm based!

_________________
Pegasos II G4@1GHz 2GB Radeon 9250 256MB
AmigaOS4.1 fe - MorphOS - Debian 9 Jessie

billt Quote:

I'm curious where your code size numbers came from, and what codesets were measured. Do you have any links?

The percentages were meant to give a general idea of code density differences but they are from Dr. Vince Weavers code density comparison.

http://deater.net/weave/vmwprod/asm/ll/ll.html

I made a spreadsheet which includes some data he hasn't updated.

https://docs.google.com/spreadsheets/d/e/2PACX-1vTyfDPXIN6i4thorNXak5hlP0FQpqpZFk2sgauXgYZPdtJX7FvVgabfbpCtHTkp5Yo9ai6MhiQqhgyG/pubhtml?gid=909588979&single=true

This is one small program avoiding compiler bias but suffering from small code size and assembler proficiency variations. The general rankings when using a larger code size (MediaBench and MiBench) are similar in "SPARC16: A new compression approach for the SPARC architecture".

https://www.researchgate.net/publication/221306454_SPARC16_A_new_compression_approach_for_the_SPARC_architecture

Code Density ordering from paper

1. Thumb
2. 68k (best by Geometric Mean)
3. x86
4. x86-64
5. ARM
6. SPARC
7. PPC
8. MIPS

This study was older so lacks newer ISAs and there is information missing about compiler used and compiler settings which could easily switch a few positions. The article is about SPARC code compression so there may be better compiler options for SPARC allowing it to surpass PPC. Default GCC compiler options for the 68k are not very good either and this may have been only 68000 code instead of 68020 code.

PPC had code compression with CodePack and VLE. IBM claimed 40% code size reduction on average with CodePack which is impressive and should have placed it close to the 68k and Thumb encodings but it is complex, introduces considerable latency on L1 cache misses and the L1 cache did not benefit from the code compression. VLE was a simpler complete replacement encoding as the original PPC ISA did not store the lower bits of displacements necessary for 16 bit instructions. Despite being a complete PPC re-encoding, NXP claimed only an average code reduction of 30% leaving it well short of embedded code density leaders like the 68k and Thumb2 but likely in RISC-V code density territory. Then performance metrics need to be considered where NXP claimed less than a 10% execution path length increase. This would likely place it closest to Thumb2 where I would expect AArch64, 68k and RISC-V compressed to have the shortest execution paths in that order (fewer instructions to execute usually gives better performance).

Fl@sh Quote:

Don't worry about code size, IMHO is much more important instruction efficiency and how many transistors are needed to make it work.

Most transistors are used for caches in high performance CPUs. Larger caches are slower. Using simpler instructions requires more instructions which can create an instruction fetch bottleneck and often can't be executed in parallel because they are dependent. There is a reason RISC cores have improved code density, decreased instruction paths and added more complex instructions and addressing modes.

Fl@sh Quote:

All weird old instructions complexity and addressing modes jungle are part of past.

Have you looked at AArch64?

Fl@sh Quote:

I have always thought simpler is better, so as example I really don't understand why to mask load stores to memory with complex instructions. We all know memory modules doesn't execute any instruction, but in most old cpus you can make math on memory addresses. All compilers will never use full potential of complex addressing modes or some fancy instructions.

Pure RISC is "part of past".

Fl@sh Quote:

We have still a lot of difficulty to use today simd units, major part of coders does not use assembly and some cpu tricks to gain speed are never used.

That's because the RISC assembler was not friendly and compilers can't optimize as well as humans. x86-64 software and CPUs received the performance tricks while RISC was moving complexity out of the CPU and into the compiler. PPC, MIPS and SPARC are now "part of the past".

Fl@sh Quote:

Simplicity is better, always! ..so if we want make theory it's better to start think different and go far ahead old cpu designs. Look at new apple silicon chips, it outperform any other cpu considering whole efficiency. It's a new design, it's fast, it's cold, it's low power, it's cheap, it's simple, it's arm based!

It's AArch64 which has complex addressing modes much like the 68k. More complex instructions have reduced the number of dependent instructions and number of instructions which need to be executed. It is *not* the pure RISC of the past but a more competitive Hybrid RISC/CISC.

@matthey

matthey wrote:
Quote:

Most transistors are used for caches in high performance CPUs. Larger caches are slower. Using simpler instructions requires more instructions which can create an instruction fetch bottleneck and often can't be executed in parallel because they are dependent. There is a reason RISC cores have improved code density, decreased instruction paths and added more complex instructions and addressing modes.

Current cpu cache sizes have shifted the code density problem to code efficiency.
It is much more important to guarantee continuous access to the data to be processed.
Usually cpu intensive algorithms are small code size, while datas to be processed are huge.
Main goal is to avoid as much as possible code jumps, usually all critical code in processed inside cache.

Dividing complex instructions in simple ones let compiler use them at best and parallelize code better than complex instructions where usually there are more dependencies among them.

Reusing simple instructions many times let also cpu to not decode them everytime and there are more probability next instruction is already in cache, because there are less instructions to be used.

matthey wrote:
Quote:

Have you looked at AArch64?

AArch64 is surely a good ISA but as said in other threads today it's more important the fab process and R&D on silicon than theory.
ARM isn't the best solution for sure, POWER is much better but ARM was smarter than others to open their projects to third parties giving licenses and letting ARM ISA to be adapted to many different purposes, from microcontrollers to high end cpus.
Look at x86 cpus, one of the worst ISA full of legacy compromises with a revelant part of transistors inside cpu core is often unused and present only for backward compatibility

matthey wrote:
Quote:

Pure RISC is "part of past".

I agree but even 68k is part of past, sadly it was suppressed by Motorola just like PowerPC.
The difference is that PowerPc is a completely new project with much better potential than mc68k.
Today we have Power9 and Power10 and their specs are impressive also compared with Opteron/Xeon.

matthey wrote:
Quote:

That's because the RISC assembler was not friendly and compilers can't optimize as well as humans. x86-64 software and CPUs received the performance tricks while RISC was moving complexity out of the CPU and into the compiler. PPC, MIPS and SPARC are now "part of the past".

RISC assembler is much more simple than any CISC assembler.
Less fancy instructions, less addressing modes, usually more registers and fully orthogonal.
Programming RISC you have to go really low level and make all by your hand, moving datas from/to memory everytime without high level instructions masking all this things.
For a compiler should be simpler generate code for a RISC cpu rather than a CISC, less choices to guess among instructions and addressing modes, more registers to put variables, less registers dependencies.

matthey wrote:
Quote:

It's AArch64 which has complex addressing modes much like the 68k. More complex instructions have reduced the number of dependent instructions and number of instructions which need to be executed. It is *not* the pure RISC of the past but a more competitive Hybrid RISC/CISC.

Complex instructions increase transistors numbers and complexity, they have to be decoded in simple ones at clock cycles cost.
I don't agree they reduce dependencies but for sure number of instructions as you said.
But as already I wrote with large caches code size isn't more a real problem.
I'm not an extremist of RISC, an hybrid design could be the better choice assembling the best of two worlds in one solution,
The problem is that looking at x86-64 as example instructions grow everytime.. and a lot of instructions are never used.

_________________
Pegasos II G4@1GHz 2GB Radeon 9250 256MB
AmigaOS4.1 fe - MorphOS - Debian 9 Jessie

@Fl@sh

If you are not making changes you are not innovating, and you remove existing instructions, you get illegal instruction hits, this are really costly, so optimizing things by hand is no fun, on chips designed for embedded market.

PowerPC be great if they did not butcher it so much. Anyway I have thinked whery creatively to work around issues lately, I’m using double to copy data, but not all PowerPC has even doubles, so you see my problem.

Instructions like fsel and isel should used all the time by compiler as they branchless instructions, the are ideal for code like:

a = is_active ? 10 : 20;
And lot of code has stuff like that, yes, I know you can do it with logical operators, but I’m sure it will be slower.

Sandy fsel and isel as missing in many of PowerPC isa’s and I’m sure its why compiler doesn’t support the instructions, or don’t optimize for it, it takes time for compilers to catch on to new instructions. Maybe this IBM compilers do, but we don’t use this here.

Last edited by NutsAboutAmiga on 01-May-2021 at 08:24 PM.
Last edited by NutsAboutAmiga on 01-May-2021 at 08:15 PM.
Last edited by NutsAboutAmiga on 01-May-2021 at 08:10 PM.

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