I came, my friends,

I came back to stay a while with you all as the weather becomes gloomy again and the season's first gentle shiver creeps under my sumptuous silken night robe.

I came to stay and bask in the warmth of your friendship.
But then...

Quote:

Higher clock speeds did not come from reduced transistor counts but from pipelining processors

...NEVER MIND, MY FRIENDS!
AWAY I GO!

With endless love,
/MEGA!

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

amigang Quote:

I know Im going on about Emulation alot, but there is one big positive to AmigaOS4 not progress as much as it has, getting SMP support etc, means its going to be a lot easier to emulate! interesting little read and thread I found on a Mac site, ARM faster for PPC Emulation https://www.emaculation.com/forum/viewtopic.php?t=10702 Who knows in a few years time we might see Pistorm PPC Edition.

Comparing a 14nm to 7nm chip fab process (roughly 4 times the transistors in the same area and half the distance for electricity to travel) tells us PPC emulation is better on ARM than x86-64?

NutsAboutAmiga Quote:

Interesting, but the FPU score is missing, this thing is lacking something,

A later post gives a 63% FPU percentage of a Power Mac G3/300.

NutsAboutAmiga Quote:

the M1 score of 400%, is like 4 x 300mhz = 1.2Ghz that is like the score of Sam460 1.2 Ghz, it’s pretty good. But not close to X1000 or X5000 computers.

I believe a G3 PPC core is significantly more powerful (performance/MHz) than a Sam460 core and may be approaching the performance of a X1000 PWRficient PA6T-1682M but likely falls short of a X5000 QorIQ P5020 core. Older G3 chips were pretty far behind in chip process and likely had fewer resources to work with narrowing the gap vs a weaker Sam460 core. G3 and G4 cores are roughly similar except for the addition of the SIMD unit if wanting to compare the design brought forward with newer technology. It's not really surprising that a state of the art chip can emulate a 20+ year old G3 processor is it?

MEGA_RJ_MICAL Quote:

I came, my friends, I came back to stay a while with you all as the weather becomes gloomy again and the season's first gentle shiver creeps under my sumptuous silken night robe. I came to stay and bask in the warmth of your friendship. But then... Quote: Higher clock speeds did not come from reduced transistor counts but from pipelining processors ...NEVER MIND, MY FRIENDS! AWAY I GO! With endless love, /MEGA!

I thought you were a tech guru and not just a software guy. It is common knowledge in processor design that the easiest way to clock up a processor is to increase the pipeline depth with more stages which uses more transistors. The branch mis-prediction penalty is increased so a better branch prediction cache uses more transistors. Memory is much slower than the CPU core so more instruction and data caches are needed costing more transistors. It's not difficult to do as Intel did with the Pentium 4. All those transistors used generate more heat and the processor is less general purpose because of branch penalties when pipelines are too deep but those high clock speeds are great for marketing. Still, Intel went back to the much better medium pipelined Pentium 3 design for later processors.

@matthey

Well no G3 is slower then G4 and my 1.2Ghz G4 is a lot slower then 1.8 Ghz PA6T-1682M, this has do with slower ram on G3 and G4, and number of other things, like bus speed, etc.

PA6T-1682M is similar to G5, but does not include all instructions, as it was intended as Apple’s last PowerPC laptop processor.

G5 is faster, but runs hot!

QorIQ 5020 is faster per clock, but does not include AltiVec, also X5000 is clocked higher.

Last edited by NutsAboutAmiga on 08-Oct-2021 at 09:56 PM.
Last edited by NutsAboutAmiga on 08-Oct-2021 at 09:46 PM.
Last edited by NutsAboutAmiga on 08-Oct-2021 at 09:44 PM.
Last edited by NutsAboutAmiga on 08-Oct-2021 at 09:42 PM.
Last edited by NutsAboutAmiga on 08-Oct-2021 at 09:39 PM.

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

NutsAboutAmiga Quote:

Well no G3 is slower then G4 and my 1.2Ghz G4 is a lot slower then 1.8 Ghz PA6T-1682M, this has do with slower ram on G3 and G4, and number of other things, like bus speed, etc.

Later G4 designs added a few pipeline stages to the G3 design so it would clock up better and chip die shrinks allowed higher clock speeds as well. Together, some G4 cores may allow twice the clock speed of early G3 cores in older chips. There were likely newer G3 cores without the extra stages and without a SIMD unit for embedded use and also able to clock up further than early G3 cores on older chips. The G3 and G4 CPU core designs are similar regardless of the chip process used, number of pipeline stages, caches and bus speeds used which allowed significant performance differences. The G3/G4 design was one of the best PPC designs and was reused for many years.

NutsAboutAmiga Quote:

PA6T-1682M is similar to G5, but does not include all instructions, as it was intended as Apple’s last PowerPC laptop processor. G5 is faster, but runs hot!

Design wise, the PA6T-1682M and G5 are not similar even though the performance may be. The G5 core is stronger and would likely significantly outperform the PA6T-1682M with similar chip process and resources. The G5 chip would run cooler on a similar chip process but would be unlikely to compete in power efficiency. The CPU designs have very different design goals.

The PA6T-1682M follows PPC standards very well. Even though it targets embedded use, it is not castrated like some Freescale embedded designs.

NutsAboutAmiga Quote:

QorIQ 5020 is faster per clock, but does not include AltiVec, also X5000 is clocked higher.

The QorIQ 5020 uses a 64 bit e5500 core which is based on the 32 bit e500mc core (not the castrated Tabor e500v2 core without FPU) which is the replacement of the G3 (Freescale 7xx) core and has more than a few design similarities including the lack of AltiVec. Coincidence?

@MEGA_RJ_MICAL

As the first law of amigaworld.net states:
Quote:

1) Every thread mentioning processors shall turn into an endless discussion about computer architectures, regardless of the original topic.

_________________
This is just like television, only you can see much further.

@matthey

You are trolling...

Let’s agree that there is no way you stuff all this crap into a laptop.

Last edited by NutsAboutAmiga on 09-Oct-2021 at 11:31 AM.
Last edited by NutsAboutAmiga on 09-Oct-2021 at 10:18 AM.

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

NutsAboutAmiga Quote:

You are trolling...

There are many hardware assertions in this thread which, even with my limited hardware knowledge, I believe are substantially incorrect, revisions of history and/or distortions of reality. I never intended to pull the thread off topic but how can the situation be properly analyzed with distorted information?

PPC was a reasonable or at least easy target for AmigaOS 4 shortly after CBM went bankrupt. Other than being big endian, there wasn't much hardware advantage to using PPC. Most of the advantages of choosing PPC had more to do with marketing and availability. CBM had considered PA-RISC which was also natively big endian and it further had the advantage of a SIMD unit (earlier than PPC) which they wanted for GPU/multimedia processing while losing 68k compatibility. That future would have likely led to another hardware target transition even sooner than the choice of PPC. The other option CBM was looking at was licensing the 68k from Motorola and further integrating the 68k and Amiga chips. I believe this option had the best chances of long term success if improvements could have been made with the cost reductions. I believe this could have resulted in very affordable products like the Raspberry Pi and Raspberry Pi 400 (Pi in keyboard) but significantly earlier. I believe this future would have seen the best chance of the AmigaOS surviving instead of being replaced as well.

NutsAboutAmiga Quote:

Let’s agree that there is no way you stuff all this crap into a laptop.

The G5 PPC 970 CPU used a 130nm chip fab process in 2003. A laptop was likely not practical at this process. The PPC 970FX used a 90nm process in 2004 and likely could have been used in a laptop with power saving features (added to 970MP in 2005) and a lower power north bridge chip. It was not because the currently used G4 CPUs had a better performance/W (power efficiency) which was better for a laptop.

Fast forward to the PA Semi PWRficient PA6T-1682M CPU circa 2007 which was designed for power efficiency (PWRficient stands for PoWeR efficient). The chip process is now 65nm. A G5 CPU at this process with power saving features and north bridge added could easily be used in a laptop but the PA6T-1682M would be a better choice as it is more power efficient as it was designed from the ground up for power efficiency and achieved those goals while the G5 was designed for performance and had disappointing performance and poor performance/W (notice that performance/W was very important even for a performance design).

Fast forward to today and the state of the art chip fab process is around 5nm. I believe "you stuff all this crap" of a G5 Mac onto one chip and then into a laptop and you wouldn't even need a fan at 2 GHz clock speed. I believe you grossly underestimate the advantage of chip process improvements. TSMC claims ~30% speed improvement, ~55% power improvement and ~3.3 times density improvement from its full node N16 (16nm) to N7 (7nm) process. From the G5 130nm to 5nm process is many full node improvements. The 68k stopped around 500nm process which compared to 5 nm is more improvement. The Amiga OCS chipset used a 5000nm process which compared to 5 nm is crazy. I don't know which is harder to fathom, the chip process improvements since the Amiga was released or Amiga users still using the original chips.

Who cares about ancient PA1682 or ibm 970 these days. Both are pocket calculator leagie cpus gruntwise on today's standards (have a 970 myself in my "computer museum").
It's old kit. We need to move on. AMD Ryzen 5000 or Apple M1 - that's where today's cool kids go.

ppc is dead and buried. Not too be forgotten though and of course we we had good times and high hopes which should always be remembered, but it's dead since more than a decade now. Time to move forward before we, the users, share the ppc fate and die - the usual Amiga nut is not really belonging to the youth anymore (age wise not necessarily behaviourally)...

_________________
My programs: via.bckrs.de
MorphOS user since V0.4 (2001)

@Zylesea

PPC will live on in my PS3 Cell just as MIPS will live on in my PS2! 68k never died IMHO and x86 and ARM can be utilised as co-processors for the Classic ‘miggy processor! Make it so!

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@ppcamiga1 Quote:

ppcamiga1 wrote: This thread is pure BS.

Wrong: this thread is pure terror for O4 blind Talibans like you.
Quote:

We use Amiga NG because it is the same Amiga as from Commodore

This is double-wrong.

First, Commodore clearly defined what's an Amiga in its Amiga ROM Kernel manuals, and this is 68K machine with OCS/ECS chipset (AGA never had an hardware manual, but only some internal documentation. In fact, the subsequent AAA chipset was only ECS-compatible). So, PowerPCs were completely out of question.

Second, and more important, there's absolute nothing "Next Generation" after the demise of Commodore.
OS4 was just a port of the Amiga o.s. to PCs where the CPU was replaced with a PowerPC one. Nothing of the "original sins" of the Amiga o.s. was ever fix, and they are still all there, in fact. What I expect from a "NG" system is that at least it solves some issues of the previous platform, which is clearly not the case.
This applies as well to the Amiga o.s. "rewriting" (MorphOS, AROS), but at least AROS is trying to solve some of them (SMP, 64-bit) and Morphos has similar WiP . Complete backward-compatibility will be gone, of course, but this is something expected on a normal world.
Quote:

but better because faster.

Emulators are faster too, and I reveal you a secret: they are even cheaper than PowerPC systems!
Quote:

If someone want change they have to hard work on something on x86 or ARM that will be not a shit compared to win/osx/lnx.

So, let me understand your rant: only AROS and MorphOS has to be compared to Windows/OS X/Linux when talking about different hardware platforms, but OS4 shouldn't? Is it your childish way to protect your beloved OS4 (on your beloved PowerPCs)?

I reveal you another secret: AROS is already running on x86 since the beginning, and it was ported also to x64, PowerPC, and ARM. If some ports aren't yet mature/done it's only because of lack of developers, but this o.s. is completely open source, so even a Quiche like you can contribute.
MorphOS has already shown an x64 version.
The only o.s. which is tied to the death to PowerPCs (which are dead, as I've reported it around 10 years ago) is OS4, but it's already dead, so there will be no plans to port it to other hardware platform(s).


@TRIPOS Quote:

TRIPOS wrote: @cdimauro Quote: cdimauro wrote: In reality it took took much less for Steven Solie to regret from his previous statement. In fact, it's now several years that he doesn't talk anymore of SMP, but all about a generic "multi-core" support. He also miserably tried in this forum to REDIFINE (!) the SMP term (which has a technical meaning since ages) to match the generic multi-core which is promoting, trying to save his face after the colossal shot that he made. In short: I don't expect any concrete update. I actually think it’s possible that he has developed SMP into the ExecSG kernel in some way. It’s not that much of rocket science after all, it’s ”just” a kernel; the real challenge would be the rest of the Amiga environment, that simply can not be SMP without breaking compatibility.

Exactly, and this is the reason why there will never be SMP on OS4.

In fact, and as I've already reported, Solie has regret from SMP years ago, and he's generically talking about "multi-core". So, expect something like AMP.
Quote:

There has already been some signs about this happening. And the signs are kind of disturbing IMO since it seems they do it in a poor way, involving unnecessary changes to firmware of motherboards, causing other operating systems not to work anymore. See for yourself in this (lengthy but extremely interesting) first post: https://morph.zone/modules/newbb_plus/viewtopic.php?forum=11&topic_id=12995&viewmode=flat&sortorder=0&start=0 In the post, MorphOS developer Bigfoot (and also developer of the X5000 firmware) is putting the spotlight on seemingly poor design decisions from ssolie regarding the implementation of SMP in ExecSG.

I've read all thread, and there are only two words that immediately came to my mind: incompetency and not professional.

A team which is not even able to compile a project, which required external support. But, much worse, a team which has no API and ABI knowledge, and which is trying to solve its problems in the "good" old way: hacking other parts.

If we consider all mistakes that OS4 developers made in all this time (including the CPU choice on Tabor) I think that part of the responsibility of the current situation is of Trevor, which continue to give credits to them, and he's contributing to the current situation.
Quote:

Some time ago, Bigfoot made a public demonstration of MorphOS running natively on X64 hardware. In his efforts to migrate MorphOS he ended up writing a completely new MorphOS kernel from scratch. The kernel isn’t at all limited to to X64/AMD64 architecture, it happily runs on PPC too. Ironically it was actually developed on X5000, and when this new MorphOS kernel is running on the X5000 HW it natively runs in SMP and 64-bit mode, cleanly and properly implemented so that it can boot up with the current, unchanged motherboard firmware. Signs of ExecSG development that Bigfoot highlights in his post suggest that this is not the path ssolie has chosen. But again, having SMP in a kernel is not the same thing as having an Amiga environment that is SMP capable. Even the AROS “Silly SMP” experiment concluded that changes to applications’ source code was needed, albeit very small. But it’s not binary compatible and not source compatible either. If you give this (compatibility) up though, implementing SMP should be quite straightforward and no brainer at all.

We know that, but at least AROS and MorphOS can have a future with SMP and 64-bit, which are must-have features nowadays.
Quote:

But breaking Amiga compatibility raises the question of why on earth you would want to continue using PPC at all. Of course AeonKit has its main focus on making their OS make the most out of their PPC products, including the Tabor. Their whole purpose seems to be about building HW dongles (PPC motherboards) that locks the community in a dead-end platform. But once you have sacrificed both binary and source compatibility you could as well go all-in on SMP, 64-bit, real memory protection and resource tracking, etc, on any other platform such as X64/AMD64 or AArch64 or whatever. Sticking to PPC at that point would just be… weird

In fact it doesn't make sense to continue with the same limitations when you have to break binary-compatibility.

But this applies to AROS and MorphOS as well. Since there'll be such breakage, then it's better to take the chance, walk some further steps ahead and introduce:
- resource tracking;
- memory protection;
- virtual memory;
- security.

You'll get an o.s. which is very close & inspired to the original Amiga o.s., keeping as much as possible from it, so it'll be easier to port / adapt the existing software.

Continuing nowadays with the same limits from early 80s is simply ridiculous.

Let the old Amiga software be still enjoyed through an emulator (even connected to the host o.s., like AROS is doing with AmiBridge/Janus), and the new stuff run on a modern platform.


@SHADES Quote:

SHADES wrote: @cdimauro Quote: [quote]es, cheap means something like that. The lowest cost PowerPC processors that NXP offers can be found on that ballpark. It's quite expensive considered what else (not PowerPC) can be found (more powerful and at much less cost), but here we're talking about a processor to be used on a hobby machine just to run OS4 (as I've said times ago, PowerPCs can be considered as the "dongle key" used by Lightwave). $100 US before OS purchase is quite a bit for a hobby. I very much doubt you will get new users at that price point. No one would care about a single tasking old OS other than a die-hard.

Actually the are several die-hard fans which are spending even $2000-$3000 for playing around with Workbench's windows (I don't see any other killer app which justify the expensive PowerPC dongle) on a single core (the others are idle, of course)...
Quote:

Quote: Impossible: SMP is certainly out of question. ExecSG leader already regretted from it several years ago (see also the above YT video, which is from 2015). Now that, I don't agree on. It has to happen. We just need to move away from legacy. AROS have test versions already on 3.x. Sandboxing older requirments is always an option, but yeah, it needs to happen. This is the future, CPUS are not going to go back to single threading.

See above my reply to TRIPOS, as well for the remaining part of your post.
Quote:

There once was a time when AMIGA had Transputer compute over may CPUs before it was mainstream. http://www.bambi-amiga.co.uk/amigahistory/prototypes/transputer.html https://en.wikipedia.org/wiki/Atari_Transputer_Workstation

There was no Amiga o.s. port to Transputers: Amiga was acting just like a "director" for them.


@ppcamiga1 Quote:

ppcamiga1 wrote: @WolfToTheMoon AMIGA Technologies chose PPC in 1995

PowerPCs were only one of possible architectures.

Anyway, plan can also change.

When OS4 development started it was 2001 (so definitely NOT 1995!), and already at the end of 90s even Apple knew that PowerPCs weren't competitive anymore.

In fact, Apple's upcoming o.s., which would then have been delivered as MacOS X, had x86 at its primary architecture and PowerPC as second choice.
The ONLY reason why Apple changed its mind and reverted to PowerPC as its primary architecture for OS X was because a rampant IBM manager (which after that it became Freescale's CEO) promised the (in)famous G5 to Jobs. But, as we know, G5 was a failure as well, and then the transition to x86 happened anyway.

So, the post-Commodore managers failed AGAIN choosing the wrong architecture for the Amiga o.s. port. But the same applies to the OS4 developers: blind Talibans that only had eyes to their beloved PowerPCs ("Intel outside").



@NutsAboutAmiga Quote:

NutsAboutAmiga wrote: @IridiumFX No one knew that Intel was able to Die shrink Intel chip to extent they did, it speculated that in order to get higher clock speed the transistor count had to go down, this was point of risk

I wonder how is it possible that after so many years you are still unable to correctly use the right them: it's RISC! NOT risk! And it's an acronym (that's why it's all uppercase).
Quote:

as well as C compilers where unable to take advantage of special instructions.

It depends on the compilers: Intel's one is good at that (and especially on auto-vectorize code).
Quote:

Intel Pentium 6, actually introduce risk.

It was the Pentium Pro (there is no Pentium 6), and it's only an internal detail of the micro-architecture.

PentiumPro, as well ALL x86 processors, are CISC processors, and that's they advantage compared to RISCs.
Quote:

https://en.wikipedia.org/wiki/Intel_Microcode https://en.wikipedia.org/wiki/Micro-operation So at least for people bet on Power had right, in that Risk was good idea, to some extent,

It WAS a good idea only at the beginning, when RISCs were introduced. After that almost all RISCs "pillars" miserably felt-down, and there's no RISC since very long time ago that can be really classified as RISC: rather, all of them are... CISCs. Yes, even your beloved PowerPCs: they ARE CISCs and definitely NOT RISCs.

I've written a long article about that, which makes an historical excursus about RISCs vs CISCs, and which clearly proves the above. I'll still take some time to publish it, but I think that there's no hurry.
Quote:

what messed up PowerPC, as that it did not go into normal PC, with exception of Apple, instead went into embedded swamp. They where willing to cut arms, and legs off, to save power consumption.

They weren't good even on the embedded market.
Quote:

Too many variation of PowerPC, hard to optimize if you can’t trust that instructions are available. Isel, fsel instructions are good for branchless code, but they are not always included, it all depends on powerpc isa version.

This was a Motorola heritage: cutting away instructions and/or features depending on the specific processor.

Backward-compatibility was never a totem to be preserved for Motorola (then Freescale). So, I don't understand why OS4 zealots are so tied to it...


@NutsAboutAmiga Quote:

NutsAboutAmiga wrote: @IridiumFX most of that large 32bit bitmaps, at high resolutions, sure binaries are fatter, but its not what makes up most of memory usage, binaries are fat on x86/x64 as well. Also AmigaOS4.1 contains more drivers, contains USB and lot stuff do not exist in memory on AmigaOS3.x, as well JIT compiler, large buffers etc.

You forgot a very important detail: MacOS X, as well as all other mainstream o.ses, used virtual memory since the very beginning.

So, each process has from 2 to 3GB (depending on the specific implementation. Windows, by default, has 2GB, which can be extended to 3GB setting a parameter) of virtual address space.
It means that, for example, if you have 10 processes they can have (and "eat") from 20 to 30GB of address spaced. And you can manage to have everything filled-up and working either by using the extended physical memory (>4GB) and/or the swap.


On 64-bit o.ses it's even better: 32-bit processes have full 4GB of address space.


@matthey Quote:

matthey wrote: Part of the RISC philosophy was a good idea. Some traditional RISC ideals were taken too far to be practical for high performance cores and were later abandoned. Some CISC performance advantages were realized and added back in. Traditional RISC and CISC are both mostly dead and high performance cores today are hybrid designs.

I beg to differ: there aren't "hybrid designs". RISCs and CISCs have proper, very clear definitions & characteristics.

Given an architecture, it can be immediately classified as a RISC or, to exact opposite, as a CISC, by checking if the 4 RISC "pillars" apply (ALL of them!) or not.
Quote:

There are 3 choices of how to handle larger immediates and displacements. [...] Most RISC cores have to use a combination of 1 and 2 above. Even ARM Thumb2 and RISC-V which use a variable length instruction encoding don't take advantage of 3 above even though the short 16 bit encodings at least reduce the code size. It is possible for a RISC ISA to take advantage which Mitch Alsup was working on. The 68k and x86(-64) take advantage.

Variable-length instructions encoding means that the 3rd RISC's pillar (instructions should have a fixed-length) doesn't apply. Hence: you have a CISC design, and certainly NOT a RISC one.
Quote:

I believe misaligned memory handling hardware is optional although most PPC processors had it for big endian mode. Many newer RISC ISAs support hardware misalignment. That would have been an advantage for PPC in the time of PA-RISC, MIPS and even early ARM but it is a mostly standard feature today.

Misaligned memory handling requires more complex instructions / circuits, which can take more than one clock cycle: it means that 4th RISC's pillar (instructions should be simple --> execute on a single clock / machine cycle) doesn't apply. Hence: you have, again, a CISC design.

Just for completeness, I report an excerpt from my article:
The 4 pillars of RISC architectures:
1) there should be a small set of instructions;
2) only load/store instructions can access memory (for data read/write);
3) instructions should have a fixed-length --> no variable-length;
4) instructions should be simple --> execute on a single clock / machine cycle.


@NutsAboutAmiga Quote:

NutsAboutAmiga wrote: @matthey You are trolling... Let’s agree that there is no way you stuff all this crap into a laptop.

Please, tell me which laptop used a PA6T-1682M...


P.S.: sorry, no time to read again.

@cdimauro

https://forums.macrumors.com/threads/if-apple-stayed-with-ibm-powerpc.1515401/?post=16567807#post-16567807

Intel is falling behind now... the risk is back as ARM, its a same about PowerPC.
CISC is dyeing bread.

https://www.youtube.com/watch?v=6UkPagCQuXU

but changing all the software overnight does not happen, Intel can come back,
the battle for endianness was lost, but it does not change the fact that 680x0 are big-endian, and so are PowerPC. while we wait for comeback of x86.

Intel has decided to make ARM chips as well..

https://www.youtube.com/watch?v=yU2MHsRMtZE

ARM is doing pretty well emulating 680x0 as well, but pistorm for example cant be compared to EUAE, EAUE has emulate all chips in Amiga, while pistorm gets away with just emulating the CPU.

There are so many things has nothing to do with Amiga, way PowerPC failed, way Apple failed to capture the market, in late 90’s and when Commodore and Atari was pushed out.

Way Amiga can’t catchup to Apple and Microsoft, can answers with words like, disorganized, poor planning, too little investment, and infighting.

Last edited by NutsAboutAmiga on 11-Oct-2021 at 07:24 PM.
Last edited by NutsAboutAmiga on 10-Oct-2021 at 01:30 PM.
Last edited by NutsAboutAmiga on 10-Oct-2021 at 01:21 PM.
Last edited by NutsAboutAmiga on 10-Oct-2021 at 01:04 PM.
Last edited by NutsAboutAmiga on 10-Oct-2021 at 01:01 PM.
Last edited by NutsAboutAmiga on 10-Oct-2021 at 12:53 PM.
Last edited by NutsAboutAmiga on 10-Oct-2021 at 12:51 PM.

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

@NutsAboutAmiga Quote:

NutsAboutAmiga wrote: @cdimauro https://forums.macrumors.com/threads/if-apple-stayed-with-ibm-powerpc.1515401/?post=16567807#post-16567807

This is a WhatIF, which I'm tired of, since history took a different path (the current, real one) and doesn't make sense to continue wasting time trying to imagine what could have happened if something different happened.

BTW and anyway, the keypoint is this:
"Apple moved to the Intel architecture officially for 'performance-per-watt' reasons"
Quote:

Intel is falling behind now...

I assume that you never heard of Intel's AlderLake (which is arriving next month) neither you have took a look a the (unofficial) benchmarks that popped-up, right?
Quote:

the risk

RISC, damn! Your beloved processors macro-family is called RISC and NOT risk!!!

Reduced Instruction Set Computer -> RISC!

I don't know where you saw the "k" in that name, which, as I've already said, it's an acronym!
Quote:

is back as ARM, its a same about PowerPC.

ARM is one of the oldest RISCs, so it's NOT back: it's here from 1985.

PowerPC is younger.
Quote:

CISC is dyeing bread.

So, it's clear that you do NOT read what people write. Or, at least, you do NOT understand.

I've already reported why there are no RISCs anymore from very long time, and all processors now are CISCs. See above my previous comment.
Quote:

https://www.youtube.com/watch?v=6UkPagCQuXU

I don't need to view a video which everyone can upload to YT, and which cannot refute what I've already proven to be wrong (IF you understand what I've written before).
Quote:

but changing all the software overnight does not happen, Intel can come back,

See above: Intel is here to stay.
Quote:

the battle for endianness was lost, but it does not change the fact that 680x0 are big-endian, and so are PowerPC.

And... who cares, since they are both dead?
Quote:

ARM is doing pretty well emulating 680x0 as well, but pistorm for example cant be compared to EUAE, EAUE has emulate all chips in Amiga, while pistorm gets away with just emulating the CPU.

And? At least PiStorm doesn't need a perfect chipset emulation (which EUAE hasn't) since it already has it.

Plus performances can only improve over the time, either by improving the JIT or by using a more powerful Raspberry Pi.
Quote:

Intel has decided to make ARM chips as well.. https://www.youtube.com/watch?v=yU2MHsRMtZE

Intel is making ARM chips since YEARS.

Your problem is that you, as usual, you talk of things that you've no clue.

Last edited by cdimauro on 10-Oct-2021 at 01:30 PM.
Last edited by cdimauro on 10-Oct-2021 at 01:30 PM.

Quote:

NutsAboutAmiga wrote: CISC is dyeing bread.

That doesn’t make sense! I think he should stop doing that and get back to developing MorphOS already!

@NutsAboutAmiga

CISC is dying?

Sorry I must laugh about that

RISC has lots of disadvantages compared to CISC processors. The main reason was commercial, it is simply cheaper to develop new RISC processors because less complexity means less people involved and less testing making it cheaper and faster to develop.

Last edited by OlafS25 on 10-Oct-2021 at 02:09 PM.

With two of the top three super computers in the world being Power9 based (and number one being ARM based), it’s a little ridiculous to talk about the architecture being dead - it just went to other places. I suppose the dull thing about Power architecture is that they made a roadmap years ago, and have stuck to it, so … no surprises. Which sort is the selling point.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

On desktop PPC is dead and we here discuss about a desktop OS I guess... ;)

On smartphones/tablets it lives and also in big computer systems by IBM but I guess there will be no amiga smartphones or amiga based mainframes in near future

@kolla

Mentioning Power 9 and Power 10 in contex of desktops is like saying that Catepillar 797F would make race car since it haves 4000hp.

cdimauro Quote:

I beg to differ: there aren't "hybrid designs". RISCs and CISCs have proper, very clear definitions & characteristics. Given an architecture, it can be immediately classified as a RISC or, to exact opposite, as a CISC, by checking if the 4 RISC "pillars" apply (ALL of them!) or not.

I consider RISC to be a more general processor design philosophy coined by David Patterson.

The Case for the Reduced Instruction Set Computer
https://www.cs.utexas.edu/users/fussell/courses/cs352h/papers/risc.pdf

An argument could be made that the Berkeley RISC-I processor developed partially under David's supervision defines a RISC architecture (SPARC) but other examples of RISC architectures are given in the paper. Another important question is has the definition of RISC evolved over time. Your rigid 4 pillar definition of RISC would disqualify practically all popular architectures today but David received an award in 2018 which states the following.

https://www.acm.org/media-center/2018/march/turing-award-2017 Quote:

Hennessy and Patterson created a systematic and quantitative approach to designing faster, lower power, and reduced instruction set computer (RISC) microprocessors. Their approach led to lasting and repeatable principles that generations of architects have used for many projects in academia and industry. Today, 99% of the more than 16 billion microprocessors produced annually are RISC processors, and are found in nearly all smartphones, tablets, and the billions of embedded devices that comprise the Internet of Things (IoT).

From the "The Case for the Reduced Instruction Set Computer" paper, I would say the main "pillars" are a reduced instruction set using simple general purpose building block instructions and the elimination of microcode yet most of those 16 billion microprocessors have more specialized instructions than the PDP-11 or 68000 mentioned in the paper and at least the higher performance ones usually use microcode. This leads me to believe RISC is an evolving philosophy which is not so clearly defined. Certainly some of the RISC goals have changed as eliminating specialized instructions and microcode to save gates for other performance enhancements on a severely limited chip die is not a top priority anymore. The specialized instructions are back in a big way as can be seen by ARM AArch64 and POWER10 and the flexibility of microcode which can be updated has been of great benefit to fix bugs and security vulnerabilities without recalling or replacing chips. Is RISC now only a pipelined load/store GP register architecture of which "pipelined" is only mentioned in the paper as a potential benefit of the savings from the elimination of specialized instructions and microcode which are no longer eliminated?

At the time RISC was created, CISC was following a philosophy of ever expanding specialized instructions and feature creep. Performance improvements were primarily achieved by reducing the number of instructions used by code which was also helpful to improve code density where memory was severely limited. The new RISC philosophy called for prioritizing the clock cycles per instruction and even the time per clock cycle.

time/code = instructions/code x clock_cycles/instruction x time/clock_cycles

Improving clock_cycles/instruction became important for pipelining and initially gave RISC an advantage. However, many simple instructions, a load/store architecture and a fixed length encoding decreased the instructions/code (code density). From the paper, a flawed RISC assumption was that memory speed was catching up with processor speed when it would later be clear that it was falling further and further behind, especially with the RISC need to clock up the core to execute the additional instructions. The article also mentions cache memories reducing the difference in CPU and memory speeds but fewer instructions/code resulted in a less effective instruction cache. The RISC instruction fetch bottleneck was born. CISC design philosophy changed to reduce the clock_cycles/instruction for pipelining while they retained the instructions/code advantage. The new CISC philosophy had no problem with adding more powerful general purpose instructions which could be easily pipelined while the RISC philosophy was to simplify instructions requiring more of them and decreasing the instructions/code while the instruction bottleneck grew. Practically all of the original RISC architectures are dead and the new RISC philosophy has abandoned most of the original RISC philosophy yet "99% of the more than 16 billion microprocessors produced annually are RISC". If the absence of the original RISC philosophy is the CISC philosophy then I would say the CISC philosophy won but more likely the definition of RISC has evolved. The dominant design philosophy is between and incorporating the best of the original RISC and CISC philosophies which I refer to as a hybrid, some may call it RISC using an evolving definition and some may call it CISC due to the lack of a pure enough original RISC philosophy.

cdimauro Quote:

Variable-length instructions encoding means that the 3rd RISC's pillar (instructions should have a fixed-length) doesn't apply. Hence: you have a CISC design, and certainly NOT a RISC one.

Early RISC examples seem to prefer the simple and uniform fixed length encoding but it is not mentioned in the "The Case for the Reduced Instruction Set Computer" paper. RISC-V allows a compressed encoding where David Patterson supervised the creation of the predecessor RISC-I. I wonder if they asked his approval for such an abomination. Besides RISC-V, we would lose Thumb2 which is likely most of the "99% of the more than 16 billion microprocessors produced annually are RISC". POWER would be converting to CISC too but IBM already defined RISC as Reduced Instruction Set Cycles (as in reduced clock_cycles/instruction which helped pipelining as I mentioned above?).

https://www.cpushack.com/CPU/cpu5.html#Sec5Part4

IBM POWER RISC=CISC? (Did IBM trick all the PPC RISC lovers in this thread?)

cdimauro Quote:

Misaligned memory handling requires more complex instructions / circuits, which can take more than one clock cycle: it means that 4th RISC's pillar (instructions should be simple --> execute on a single clock / machine cycle) doesn't apply. Hence: you have, again, a CISC design.

"The Case for the Reduced Instruction Set Computer" paper suggests pipelining as an enhancement for RISC but it is not a requirement. It is true that many early RISC designs left out unaligned loads/stores as well as other multi-cycle instructions like MUL and DIV and now almost all of them have these instructions and more.

cdimauro Quote:

Just for completeness, I report an excerpt from my article: The 4 pillars of RISC architectures: 1) there should be a small set of instructions; 2) only load/store instructions can access memory (for data read/write); 3) instructions should have a fixed-length --> no variable-length; 4) instructions should be simple --> execute on a single clock / machine cycle.

Between the evolving definition of RISC and your definition of RISC, I believe it is safe to say that
RISC has somewhere between 99% of the microprocessor market and 0%.

Last edited by matthey on 11-Oct-2021 at 01:51 AM.

@cdimauro

Quote:

Actually the are several die-hard fans which are spending even $2000-$3000 for playing around with Workbench's windows (I don't see any other killer app which justify the expensive PowerPC dongle) on a single core (the others are idle, of course)...

I'm not sure of your point here. Just how many users like that do you think there are?
I can assure you, it's not growing the user base at all, if anything, it's locking it out for anyone not in that extreme fringe.

Last edited by SHADES on 11-Oct-2021 at 05:29 AM.

_________________
It's not the question that's the problem, it's the problem that's the question.

@matthey:

dear Matthew, it might wonder you that what I've reported is NOT my definition of RISC, but it directly comes from prof. Patterson when it first published the paper where he coined the RISC term, and then more specifically when he published the RISC-I paper (it's directly from this paper that I've extracted the 4 RISC's pillars).

Here follow the links to the two papers:
Patterson and Ditzel: The Case for a Reduced Instruction Set Computer
https://inst.eecs.berkeley.edu/~n252/paper/RISC-patterson.pdf

Patterson and Séquin: DESIGN AND IMPLEMENTATION OF RISC I.
https://www2.eecs.berkeley.edu/Pubs/TechRpts/1982/CSD-82-106.pdf

Yes, the first one is the one which you reported, and that already starts defining what a RISC is, its properties, and then, au contraire, what a CISC is.

But it's the second which leaves absolutely no doubts about the RISC's properties, and you can clearly see that they exactly match the 4 pillars that I've just summarized and reported.

So, it's not me that invented those 4 pillars, but the our eminent Turing award.

The historical excursus that I made is roughly equivalent to what you also reported, but I go further in details, and add more things. Anyway, the outcome is essentially the same: what was defined as RISC at the very beginning has lost almost all its properties (see below). And it didn't took long for it: just a few years (which clearly proves the RISC concept was a failure).

And it's very true that if we apply that the definition to the current RISCs, 99% (or even more) of those cannot be classified as RISCs, rather as CISCs.

Now, you call it new RISCs.
Many people (all others, to be precise) continues to call them RISCs, which I personally find offensive considering the defaming campaign that those academics made to promote RISCs by constantly bashing and ridiculing CISCs, and continue to do after 40 years.
I call them, and I propose to call them, just what was left and what they are: Load/Store architectures. L/S (or just LS) architectures, in short. Because this is essentially what was left from the original RISC definition: only the L/S pillar.

How can you (not you: I'm talking in general now) continue to call RISC what has lost 3/4 (75%!) of its original definition? It doesn't make sense at all, to me.

How prof. Patternson can continue to bash CISCs and promote RISCs, when he has stepped-on what he himself has proclaimed with trumpets to the world?

In Italy we're used to say "ha la faccia come il bronzo" (which just roughly translates like "his face is like bronze") to speak about people which completely reverted what they stated before.

On the exact contrary, CISCs continue to satisfy many of the opposite pillars: they have many instructions, they have complex instructions (and which take more than one clock cycles), and they have variable-length encoding.

This is enough, for me, to clearly see who has "won", and prove wrong what prof. Patterns has defined, and what continues to falsely claim.

To conclude, the above is the reason why an "hybrid" design definition cannot be accepted.

Even because, at the very end, what counts is the ISA: the interface between a processor and the external world. The internal details, are, in fact, just internal details.


@SHADES: I don't know how many such users there are. But I agree that the user base is going down.

Last edited by cdimauro on 11-Oct-2021 at 06:11 AM.