@Gunnar

Spirit here and spirit there… who are you to dictate what Amiga was about? Let me remind you that CBM Amiga also was A2500UX and A3000UX with AMIX. The A3000UX with monitor was even more expensive than 040 NextStation.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Gunnar

Quote:

Gunnar wrote: @cdimauro Quote: By doubling the register size to 256 bits, AVX fits eight 32-bit values into each register, enabling 16 floating-point operations per cycle. This effectively, in one fell swoop, doubles the peak performance. This is a peak only.

I've reported all relevant information, included a comparison of AVX with SSE (128-bit) on the same machine. I report it here again:

Intel has published direct SSE versus AVX comparisons with benchmarks run on the same second-generation Core i7 processor with FFT performance improvements ranging from 1.2 to 1.8x.

Those are not peak-only and the improvements are clear.
Quote:

More important is the combination of all factors - how strong are your instructions - what limitations do the instructions have - how many bytes can you load / write to memory per cycle - how many bytes can you load / write to data-cache per cycle

See above: the benchmarks are executed on the same machine, so everything is the same besides the differences in the instruction set.
Quote:

You can increase the number of flops you do in 2 ways. 1) double the width (this has a major drawback!)

Correct. I've already reported the major one (clock skew).
Quote:

2) double the number instructions per cycle you do

This has drawbacks as well: you cannot scale both the frontend and the backend of the processor to execute many instructions per clock cycle.
Quote:

Doubling the width has the drawback that not all algorithms benefit from it.

Indeed, but where it's possible it gives a big boost. Which is often the case on HPC workloads.
Quote:

Think of it like sprites What is better 1 Sprite Channel with 128 pixel Or 2 sprite Channel each 64 pixel Or 4 sprite Channel each 32 pixel. Which architecture is more flexible/ Which is better?

The one which offers all: same number of sprites with possibility to select 32, 64 and 128 for the width.

Now let's take a look at what IBM offers:
- Altivec and VSX can only process 128 bits data. VSX has 64 x 128-bit registers.

And now what Intel offers:
- SSE can only process 128 bits data. It has 16 x 128-bit registers;
- AVX can process 128 and 256 bits data. It has 16 x 256-bit registers;
- AVX-512 can process 128, 256 and 512 bits data. It has 32 x 512-bit registers.

The only advantage which VSX has is when unrolling loops. However, very often if you're able to unroll a loop then you're also able to computer more data at the time, and this without requiring to execute tens of instructions per clock cycle.

That's exactly the reason why, and as I've already said, many CPU vendors embraced big vectors.

IBM has no chance at all to compete with VSX: it's out of business with its POWER CPU line.

@kolla

Quote:

kolla wrote: @Gunnar Quote: with copy and paste 100 lines Please, I’m getting drunk!

How did you get on?

_________________
Doing stupid things for fun...

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: You just copied some stuff from the web. Stuff that was not needed according to what was already written at the time. So what. Again, this topic is about PPC vs the world.

Right. And what was (and is) your contribute besides copying & paste things from internet when there was already all relevant information reported here?

What's your added value to the discussion?
Quote:

Hammer wrote: @cdimauro Quote: I agree here: they both do NOT exist. Whereas 128-bit AVX INSTRUCTIONS exist, instead. "AVX 128" terminology exists across many forums, not just this one. Intel forum moderators don't attempt to correct "AVX 128"

Why they should waste their time on those irrelevant things?
Quote:

since they know it refers to the "128-bit AVX" feature i.e. it's shorthand.

That's a logic fallacy: you're assuming that since there's no correction from their side then AVX-128 should be accepted. No way. Logic works differently, you know?
Quote:

https://accserv.lepp.cornell.edu/svn/packages/fftw/simd-support/simd-avx-128-fma.h "AVX-128" term is used.

It's only on a filename where SPACES WHERE REPLACED WITH DASHES: simd-avx-128-fma.h

Internally there's no "AVX-128". But there's "128-bit AVX support", which is correct.
Quote:

https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=1421121 (IBM) AVX-128 term is used.

It's just a bug entry which anyone can write. Specifically, the guy stated this:

Intel introduced AVX-128 instructions which operate on the same 128-bit XMM register as SSE but take into account upper halves of YMM registers.

Where Intel introduced AVX-128? If the company has done it, then a trace should be found on its documentation, right? WHERE? Care to point me to Intel's documentation stating this?

You can also ask to the guy, eh!
Quote:

https://i.ibb.co/sVhhKNX/AMD-s-AVX128-term-usage.png

You broken again the forum layout because after so many years you're still unable to proper link big images.

Do you that there are image hosting sites which allow you to show a reduced size of an image whilst giving the possibility to click to get the original, big one?

When you plan to LEARN this ELEMENTARY thing, instead of wasting people time with scrolling the web page?
Quote:

During the AMD Bulldozer presentation, AMD used the "AVX 128" term. PDF copy from https://naic.nrao.edu/arecibo/phil/software/amd/AMD_6200cpu_hpc.pdf

You posted EXACTLY the same thing in the past, but that time you used Intel's documentation about PORTING applications using SSE to AVX.

This time it's about AMD, but the thing does NOT change: it's a GUIDELINE for helping developers porting their code to AVX.

Specifically, there's a COMPILER OPTION which allows to generate only 128-bit instructions. How do you pretend to achieve it if you don't allow this possibility to the user?!? You OBVIOUSLY need to add a command-line option for it!

Have you ever worked with a compiler? I mean: at this level of details. I don't think so...

Anyway, it's only "AVX 128". NOT "AVX-128".

Now, looking at the entire PDF, could you please tell me why AMD has NOT used such AVX-128 and AVX-256 terms that you pretend to sell as concrete terms for identify alleged 128 and 256 bits instructions set?
THERE'S NOT A SINGLE TRACE OF IT IN ENTIRE DOCUMENT!

Whereas I can see this:

Executes two SSE or AVX (128-bit) instructions simultaneously or one AVX (256-bit) instruction per Bulldozer module

Could you tell me why AMD has NOT used AVX-128 and AVX-256 in this case, since they would have been the absolutely appropriate terms according to YOU (and ONLY YOU)?

I give you the answer for YOUR benefit: it's because AMD KNOWS PERFECTLY OF WHAT IT'S TALKING ABOUT. And NOT you!

In fact, in the entire document it's always reported AVX, several times, and not a single chance one of those two FALSE definitions.

Do you think that AMD knows about what it's talking about or not? If not you can always contact them and signal that they "forgot" (!) to use AVX-128 and AVX-256 in their documentation. Let me know their reply, because I'm very curious...
Quote:

https://www.anandtech.com/show/16214/amd-zen-3-ryzen-deep-dive-review-5950x-5900x-5800x-and-5700x-tested/6 AVX 128-bit term is used by Dr. Ian Cutress.

Have you read it? No, it's not found.

Here is the only part where I can see "128" reported:

In Zen 2, vector-based AES and PCLMULQDQ operations were limited to AVX / 128-bit execution, whereas in Zen 3 they are upgraded to AVX2 / 256-bit execution.

Which is stating something different. IF you know what it does mean.
Quote:

https://forum.beyond3d.com/threads/digital-foundry-article-technical-discussion-archive-2015.60515/page-31#post-1836452 Sebastian Aaltonen (sebbbi) programmer for these games https://www.mobygames.com/person/226323/sebastian-aaltonen/ AVX128 term was used by Sebastian Aaltonen.

NOT "AVX-128".

Anyway, the context is clear: HE identify instructions using only 128 bits of data. In fact:

need two decoder cycles to decode a 256 bit wide AVX instruction (fastpath double). 128 bit wide instructions need only one cycle

Anyway, it's HIS definition. Nothing which is found on Intel's or AMD's documentation.
Quote:

This Beyond3d forum's topic discussed the performance regression with AVX-256 on AMD Jaguar! AMD Jaguar CPUs were the baseline for game consoles for Xbox One and PS4.

Irrelevant for what I've said before.

And "AVX-256" was used by only a guy.

As I've already stated, a terms doesn't become magically true only because it was written on a forum from a user. Even if the user is the above PS4 developer.
Quote:

https://accserv.lepp.cornell.edu/svn/packages/fftw/simd-support/simd-avx-128-fma.h AVX 128 (e.g. _avx_128_fma) term was used for FFTW open-source software.

You already the SAME link above! And you've already got my reply.
Quote:

Your register-level argument hides the real performance.

Maybe because I'm talking about the ISA = Instruction Set Architecture and NOT about one of its possible microarchitectures? Since they are DIFFERENT things.
Quote:

Intel's Gracemont E-Cores have inferior game performance, hence the need for Intel's Thread Director.

Irrelevant as per above.
Quote:

Your AVX register-only argument has been wreaked by Intel's Thread Director.

AVX is ONLY about registers AND instructions. Intel's ITD is about the MICROARCHITECTURE. Do you spot the differerence?
Quote:

Your argument is not transparent when associated with performance.

Irrelevant: I don't mix APPLES and ORANGE. See above.
Quote:

It's a clown show when you argued that 256-bit AVX is a win when Intel does NOT guarantee 256-bit hardware implementation for Intel's current-gen SKUs with E-Cores.

LOL. WHERE I've written it? You've completely INVENTED this thing!
Quote:

It's too bad for you,

What's bad for me? Care to clarify?
Quote:

Intel released the AVX-512/AVX10.x feature matrix table that divides 128-bit, 256-bit, and 512-bit feature sets.

Ah, yes: the table that even a dummy is able to read, but not you.

The same table that do NOT report anything about AVX-128 and AVX-256 and that "just" (!) defines the REGISTERS SIZES.

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: cdimauro wrote: There's no "internal RISC core" inside x86/x64 processors: that's an urban legend! If you want to have more insight about this, you can check my series of articles about the everlasting RISCs vs CISCs dispute: https://www.appuntidigitali.it/20594/the-final-riscs-vs-ciscs-6-conclusions/ This collects the links to all articles. But, specifically, article #5 clarifies this part. Counter https://arstechnica.com/features/2005/02/amd-hammer-1/5/ for AMD's K8 Hammer. https://archive.arstechnica.com/cpu/1q00/g4vsk7/m-g4vsk7-1.html The G4 and the K7: an architectural look at two post-RISC processors.

Those are articles are the result of the same propaganda of lie which RISCs evangelists continue to repeat since more than 40 years.

The guy was simply deceived by it, as MANY other people.

Anyway, this doesn't change a single comma from what I've reported on my articles, which are perfectly valid.

Specifically, I've ALSO talked about AMD's implementation. And PROVED which is FAR AWAY from RISC's concepts (the 4 pillars).

Have you read it? I don't think so.
Quote:

No modern X86 CPU microarchitecture implements old-school multi-variable instructions

LOL. "multi-variable instructions"?!? What the HELL are you talking about?!?
Quote:

within the CPU's execution pipelines.

Have you ever OPENED Intel's or AMD's OPTIMIZATION MANUALS? Maybe you'll find something which, unfortunately for you, gives a completely different picture of what you think about this argument.

IF you understand their content, of course. Which I STRONGLY doubt...

@Gunnar

Quote:

Gunnar wrote: @Hypex Quote: A good driver will bang the hardware itself while supporting all the hardware features. What defines AMIGA? Is it how it was coded? Is it how the Amige inventors teached people how to code it?

It's Commodore's manuals. Specifically, the Amiga Hardware manual.
Quote:

If you read and understand the Amiga hardware reference manuals What is the philosophy that the Amiga engineers teach you? This is very clear to answer and there is no doubt. But the Amiga inventors explicitly encourage you to directly code the hardware. And they teach you how to do this the best. Read the hardware reference manuals than you will agree to this. Coding the hardware is the Amiga way the Amiga engineers encourage you to code!

That's absolutely false and you clearly don't know of what you talk about! From the same manual:
http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node000B.html

The Amiga operating system is designed to operate the Amiga hardware
within spec, adapt to different hardware and RAM configurations, and
generally provide upward compatibility with any future hardware upgrades
or "add ons" envisioned by the designers. For maximum upward
compatibility, it is strongly suggested that programmers deal with the
hardware through the commands and functions provided by the Amiga
operating system.

If you find it necessary to program the hardware directly, then it is your
responsibility to write code which will work properly on various models and
configurations.

So, it's exactly the OPPOSITE of what you're talking about : direct access to hardware is DISCOURAGED and it's recommend to use the OS!
Quote:

Do you not like this? You can like what you want - but this does not change the fact that coding the hardware was always part of Amiga spirit - and encouraged by the fathers of the Amiga.

TOTALLY FALSE!
Quote:

Why do you want to forbid people from using the Amiga the way the fathers of the Amiga envisioned it?

You can do whatever you want. There's no one which forbids you to directly accessing the hardware.

But the RECOMMENDED way is to do NOT do it and use the OS, instead.

Well, it's evident that you do NOT like it. As you don't like to follow Commodore's guidelines even when the OS is running:
http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node0007.html

New peripheral devices may be easily added to all Amiga models. These
devices are automatically recognized and used by system software through a
well defined, well documented linking procedure called AUTOCONFIG(TM).
AUTOCONFIG is short for automatic configuration and is the process which
allows memory or I/O space for an expansion board to be dynamically
allocated by the system at boot time. Unlike some other systems, there is
no need to set DIP switches to select an address space from a fixed range
reserved for expansion devices.

Is the Apollo's extra memory being added to the system using the above Autoconfig protocol? Because this was/is the standard way to do on Amigas...
Quote:

My position is very simple: Code how you like, if you want to user drivers then use drivers. if you want to code the hardware, then code the hardware. Both was allowed on Amiga, and think people should have the right do code how they like.

Yes, but that's different from the lie that you're spreading around: accessing the hardware was NOT recommended!

You can, if it's NECESSARY (word from the documentation!) FOR YOU to do it. Otherwise, the OS should be your choice.

@cdimauro


How about you look at original Amiga Hardware Reference Manual?
https://archive.org/details/Amiga_Hardware_Reference_Manual_1985_Commodore/page/n1/mode/2up

Then you will see that all coding examples are direct hardware banging and are in assembly.

The manual puts great emphasis on explaining you how the hardware works
and it encourages the programmer to direct code the hardware.


What do you think which coding manual did the Amiga developer that coded all the A500 games use as basis?

The Manual that came out before the A500 ?
or the later Manual that came out after the A3000?


Its clear that all early Amiga coders used the original Manual to learn how to code Amiga.
The tone of the original Manual done by the "original" Amiga team is different.

Just READ then you see

@Gunnar

Quote:

Gunnar wrote: @cdimauro How about you look at original Amiga Hardware Reference Manual? https://archive.org/details/Amiga_Hardware_Reference_Manual_1985_Commodore/page/n1/mode/2up

Have you done it? Because it reports EXACTLY THE SAME THINGS which I've already copied. EXACTLY THE SAME WORDS.
Quote:

Then you will see that all coding examples are direct hardware banging and are in assembly. The manual puts great emphasis on explaining you how the hardware works

LOL. And what do you expect from the Hardware Manual? That it shows how to use the OS for coding?
Quote:

and it encourages the programmer to direct code the hardware.

ABSOLUTELY FALSE! Take a look at page 16 of your link: there's THE SAME TEXT which I've reported and that DISCORAUGES to directly use the hardware, recommending the OS instead.
Quote:

What do you think which coding manual did the Amiga developer that coded all the A500 games use as basis?

That's a completely different thing. In this case it was NECESSARY (see the same manual on that) to squeeze the most of the hardware.

The OS took too many resources and it wasn't suitable to have it running. Unless a game wasn't that demanding.
Quote:

The Manual that came out before the A500 ? or the later Manual that came out after the A3000?

The first edition came on 1985, right? When both machines weren't released.
Quote:

Its clear that all early Amiga coders used the original Manual to learn how to code Amiga. The tone of the original Manual done by the "original" Amiga team is different. Just READ then you see

Not needed: it's printed in my head since many years.

It's YOU that should CAREFULLY read it AND pay A LOT of attention on ALL its content.

Just taking a look at the examples and claiming that direct hardware programming is the recommended way is not only misleading, but completely false, since the text is stating the exact contrary.

Anyone can read even the book on your link, which looks the first edition, and verify that.

@cdimauro

Quote:

New peripheral devices may be easily added to all Amiga models. These devices are automatically recognized and used by system software through a well defined, well documented linking procedure called AUTOCONFIG(TM). AUTOCONFIG is short for automatic configuration and is the process which allows memory or I/O space for an expansion board to be dynamically allocated by the system at boot time. Unlike some other systems, there is no need to set DIP switches to select an address space from a fixed range reserved for expansion devices. Is the Apollo's extra memory being added to the system using the above Autoconfig protocol? Because this was/is the standard way to do on Amigas...

You misunderstand how Amiga works.


Amiga onboard e.g. the chip memory, the A500 Ranger memory expansion,
Amiga 3000 fast memory or Amiga 4000 fast memory
= are not auto config


And this makes sense. This memory is always there and useable even at early boot.
Before autoconfig was run.

Also Apollo Memory is be designed always there and its placed at the "Amiga locations"
The Apollo Card gives you Ranger A500 expansion as some games want it.
The Apollo Card gives you Chipmemory and so on.


What you talk about are Expansion in Zorro slots.
This is totally different topic.
For Zorro cards autoconfig is extremely useful.
And autoconfig will on boot "assign" the memory of the card to an address.

@cdimauro

Quote:

The first edition came on 1985, right?

The first edition came out 1985.
I have the print from 1986 here on my desk.


1985 is 2 years before the 68030 CPU was invented.
And before the A2000 came out
This means the original hardware manual could obvious never
mention the Amiga 2000 nor state that some Amiga have an 68030 CPU.
As this CPU did no yet exists. And Amiga using it A3000 also not existed yet.

makes sense?



The original manual did not had this section you mention.

@cdimauro

Quote:

Just taking a look at the examples and claiming that direct hardware programming is the recommended way is not only misleading, but completely false, since the text is stating the exact contrary. Anyone can read even the book on your link, which looks the first edition, and verify that.

The section warning that some Amigas might have faster CPU like 68030
and to use the OS to avoid compatibility issues - was added after the A3000 came out.


This was obviously not in the original manual.


How could a section mentioning a CPU invented in 1987 be in the manual of 1985?

@kolla

Quote:

who are you to dictate what Amiga was about?

Please stop making up stories.
I not dictated anything. Actually the opposite.



Does the Amiga software not show us a lot of the Amiga spirit?

What do we think off when we think on Amiga?

- thousands of nice games?
- thousands of cool demos?
- some famous programs like DPaint, Protracker, maybe Workbench Powerpacker and Xcopy?


To me this is "what I think about" when I think on Amiga?

How about you guys?

I think the programs we recall when we think about Amiga - this is for us the spirit of Amiga.
And when the Amiga demos and games we recall were mostly coded with direct hardware access.

Is the direct hardware access not the basis for the spirit of Amiga how we recall it?

@Gunnar

I never cared much for the games, and even less for demos. For me, Amiga is mainly about productivity software and operating systems, and the shoestrings and chewing gum that ties it all together. And networking, all systems online, even if it means a 9600 baud serial link.

Last edited by kolla on 17-Mar-2024 at 05:51 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Gunnar

Quote:

And autoconfig will on boot "assign" the memory of the card to an address.

it’s wasteful to have address spaces pre-mapped, and Zorro RAM its quite slow.
Far too much address space was, mapped to zorro slots.

Last edited by NutsAboutAmiga on 17-Mar-2024 at 09:07 PM.

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

@kolla

Quote:

kolla wrote: I never cared much for the games, and even less for demos. For me, Amiga is mainly about productivity software and operating systems, and the shoestrings and chewing gum that ties it all together. And networking, all systems online, even if it means a 9600 baud serial link.

The Amiga platform wouldn't survive from the Video Toaster and Toaster Flyer NLE niche and most AmigA's non-linear editing system (NLE) software is anchored by hardware Zorro II/III add-ons and PowerPC Amiga NG doesn't have Zorro II/III slots.

A500's Q1 1992 cancellation has negatively impacted Commodore's revenue in a large scale. AGA A1200 wasn't ready for a blended transition from A500's cancellation into A1200's introduction. Commodore management wasted more than 6 months on ECS-based "A1000 Jr".

PowerPC Amiga NG has cut off the Amiga Zorro II/III add-on hardware that anchored the Amiga platform in its professional market niche.

AmigaOS's software library didn't have Adobe Premiere style NLE software that is not anchored by a specific addon card.

PowerPC Amiga may have PowerPC optimized Datatypes, but it's almost meaningless without NLE software targeted for the semi-professional/professional markets. This is what I encountered during the early 2000s PowerPC-based AmigaOne SX/XE. X86-based Amithlon has similar software library problems since the PC doesn't have Zorro II/III slots.

My A1200 with PiStorm-PRi4B-Emu68 can still run very fast Adobe Premiere 4.0 NLE via Shapeshifter/MacOS 7.5, but it's missing FireWire. It's software from MacOS world.

For Amiga's semi-professional/professional niche video market, the transition from classic Amiga into PowerPC Amiga NG was mishandled.

I stayed with my gaming PC's K7 Athlon XP/GeForce 4 Ti 4200 VIVO DirectShow MPEG-1/MPEG-2 acceleration /FireWire for the NLE work.

VIVO = non-PC video in, video out.

Last edited by Hammer on 18-Mar-2024 at 04:43 AM.
Last edited by Hammer on 18-Mar-2024 at 02:48 AM.

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

@cdimauro

Quote:

Those are articles are the result of the same propaganda of lie which RISCs evangelists continue to repeat since more than 40 years.

RISC's important ideological points:

1. Atomic instruction that is executed close to 1 instruction per cycle or greater. For lower transistor budgets, this particular RISC concept has the advantage i.e. improving basic math instruction completion rates.

Sega has evaluated MC68030 vs SuperH2 for their Saturn. SuperH2 won the Saturn contract.

Sony's PS1 also has about a 1 million transistor budget.

Commodore Amiga's PA-RISC Hombre had about a 1 million transistor budget.

Intel's Pentium P5 and Motorola 68060 blows Commodore's 1 million transistor budget.

Around the 1st Xbox's cutdown Pentium III-S/Celeron 128 KB L2 cache 733 Mhz and original Xbox prototype's K7 Duron CPU when X86 CPUs can complete in the game console price and performance.

Intel focused on advanced process nodes and large economies of scale ahead of "big iron" RISC competitors. Modern ARM clones have advanced process nodes and large economies of scale, hence ARM world is a very strong competitor.

As the transistor budget increased from generation to the next generation, X86 vendors were able to transition most of the X86 CISC into 1 instruction per cycle or greater. X86 decoder cost has decreased when out-of-order processing and execution hardware increased in scale.

For Jaguar, AMD was able to pack a higher density transistor count into a nearly comparable to the area size of NVIDIA Tegra X1's ARM Cortex A15 when both have 28 nm TSMC process node. Transistor packing skills are an art.

Zen 2 (2.83mm^2) at 7 nm process node is smaller than Jaguar (3.1mm^2) at the 28 nm process node. Area size efficiency vs performance is important for desktop game console wins.

Both Intel and AMD are chasing Microsoft's Xbox 2027 contract. Microsoft is also open to ARM's entry into the Xbox 2027 contract contest.

ARM's P-Cores still have the edge on idle power consumption which is important for smartphones.

2. Fix length instructions are important for pipelining.

Intel refers to the variable-length x86 instructions as macro-ops.

AMD refers to the more simplified fixed-length operation as macro-ops. AMD's macro-ops are x86 instructions that have undergone a number of transformations to make them fit into a more strict, but still complex, format. In Intel's context, no such concept exists.

Intel refers to the internal operations of fixed length and regular format as micro-operation (µOP).

AMD refers to the simple, single-operation (e.g. a single arithmetic or memory operation) micro-operation (uOP). Those µOPs make up a potentially more complex macro-operation.

Modern X86-64 CPUs have Intel's trace cache/UOP cache or AMD's uOP cache.

NextGen Nx586 had the RISC86 and AMD has RISC86 for K6.

3. RISC's atomic load and store instructions ideology is less important. There's a reason why Apple's M1 has 8-way ARM instruction decoders just rival X86 competitors.

The main difference between Zen 2 and Zen 3 is load-store capability. In general, 8 core Zen 3 is like the 12-core Zen 2 despite both microarchitectures having similar execution units.

For Zen 5, two additional IEUs, one additional AGU, and Load-Store are increased beside the full-speed AVX-512 units.

Modern X86 CPUs are not your granddad's classic Pentium CPUs.

4. RISC world's pure register-only math operations. Who cares. There's a reason why Apple's M1 has 8-way ARM instruction decoders just rival X86 competitors.

5. RISC world's higher register count argument. GpGPU has many thousands of registers.
X86's register renaming hardware is the workaround.

Major aspects of the RISC world were assimilated by X86 vendors.

Last edited by Hammer on 18-Mar-2024 at 04:31 AM.

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

@cdimauro

Quote:

Have you ever OPENED Intel's or AMD's OPTIMIZATION MANUALS? Maybe you'll find something which, unfortunately for you, gives a completely different picture of what you think about this argument.

Intel has "128-bit AVX" and "AVX128" (e.g. page 2-25, page 3-62) in "Intel @ 64 an IA-32 Architecture Optimization Reference Manual" with Order Number: 248966-046A. January 2023

Idiot.

AVX128 is a shortened term for "128-bit AVX".

I don't hide behind "256-bit AVX" front-end instruction set marketing.

Last edited by Hammer on 18-Mar-2024 at 04:14 AM.

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

@Gunnar

Quote:

Gunnar wrote: @cdimauro Quote: The first edition came on 1985, right? The first edition came out 1985. I have the print from 1986 here on my desk. 1985 is 2 years before the 68030 CPU was invented. And before the A2000 came out This means the original hardware manual could obvious never mention the Amiga 2000 nor state that some Amiga have an 68030 CPU. As this CPU did no yet exists. And Amiga using it A3000 also not existed yet. makes sense? The original manual did not had this section you mention.

But you haven't shared it!

You posted a link to the second edition (which is NOT reporting the A3000 for the same obvious reasons: it talks only about the A2000 and A500), reporting 1985 in the link, and then while quickly scrolling the pages I've found the same thing and stopped there.

You should have shared the first (original) edition, instead.

Anyway, I've found only one version of the first edition, but it shows only a few pages, unfortunately.

This clarified, at least from the second edition (A2000 and A500 time. And 68030 was also included in the reference), those were the official guidelines for the developers.
Quote:

Gunnar wrote: @cdimauro Quote: Just taking a look at the examples and claiming that direct hardware programming is the recommended way is not only misleading, but completely false, since the text is stating the exact contrary. Anyone can read even the book on your link, which looks the first edition, and verify that. The section warning that some Amigas might have faster CPU like 68030 and to use the OS to avoid compatibility issues - was added after the A3000 came out. This was obviously not in the original manual. How could a section mentioning a CPU invented in 1987 be in the manual of 1985?

See above plus: why don't you read and understand what people are writing? Let me quote me again:

The first edition came on 1985, right? When both machines weren't released.

I've highlighted the relevant part for YOUR interest...

@Gunnar

Quote:

Gunnar wrote: @kolla Quote: who are you to dictate what Amiga was about? Please stop making up stories. I not dictated anything. Actually the opposite. Does the Amiga software not show us a lot of the Amiga spirit? What do we think off when we think on Amiga? - thousands of nice games? - thousands of cool demos? - some famous programs like DPaint, Protracker, maybe Workbench Powerpacker and Xcopy? To me this is "what I think about" when I think on Amiga? How about you guys? I think the programs we recall when we think about Amiga - this is for us the spirit of Amiga. And when the Amiga demos and games we recall were mostly coded with direct hardware access. Is the direct hardware access not the basis for the spirit of Amiga how we recall it?

No: the OS was equally important.

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: Those are articles are the result of the same propaganda of lie which RISCs evangelists continue to repeat since more than 40 years. RISC's important ideological points: 1. Atomic instruction that is executed close to 1 instruction per cycle or greater.

Do you understand that if you write this statement then you're getting ANY processor built since several decades, whatever is the macrofamily?!?

Yes, even CISC processors. How many instructions per cycles a Pentium or 68060 were executing on average? Were they RISC processors? I don't think so...

BTW, what do you mean with "Atomic instruction"? In the literature those are instructions for blocking / synchronizing memory accesses (LOCK instructions on x86, for example. TAS, CAS, etc. on the 68k family).

With those instructions is UNLIKELY that a processor can execute even more of them per clock cycle.

In short: your point #1 is a complete non-sense...

I've removed the rest because is a complete non-sense as well: it's the very well known Hammer's PADDING...
Quote:

2. Fix length instructions are important for pipelining. Intel refers to the variable-length x86 instructions as macro-ops. AMD refers to the more simplified fixed-length operation as macro-ops. AMD's macro-ops are x86 instructions that have undergone a number of transformations to make them fit into a more strict, but still complex, format. In Intel's context, no such concept exists. Intel refers to the internal operations of fixed length and regular format as micro-operation (µOP). AMD refers to the simple, single-operation (e.g. a single arithmetic or memory operation) micro-operation (uOP). Those µOPs make up a potentially more complex macro-operation. Modern X86-64 CPUs have Intel's trace cache/UOP cache or AMD's uOP cache.

And? What's the point? Those were/are NOT instructions as normal processors execute. Have you read the declaration from one of Intel's chief engineers, which I've reported on my article? I don't think so, because he clarified it.
Quote:

NextGen Nx586 had the RISC86 and AMD has RISC86 for K6.

That might be the case, but it was just ONE example.

The generality is represented by x86 processors NOT having a builtin RISC core.
Quote:

3. RISC's atomic load and store instructions ideology is less important.

Not important?!? ROTLF

It's the ONLY thing which have the processors which are falsely marketed as RISCs...

And, again, "atomic" instructions are the only ones used for SYNCHRONIZATION purposes. You don't know of what you talk about!!!
Quote:

Modern X86 CPUs are not your granddad's classic Pentium CPUs.

LOL And? What's your point here (IF you have any)?
Quote:

4. RISC world's pure register-only math operations. Who cares.

You clearly don't, because you don't understand it, since it's exactly related to the PREVIOUS point (which in reality was talking about load/store) and CANNOT be separated by it...
Quote:

There's a reason why Apple's M1 has 8-way ARM instruction decoders just rival X86 competitors.

What's the reason of this thing that you continue to repeat as the PARROT that you're?

I mean: what in THIS context (= register only)?!?
Quote:

5. RISC world's higher register count argument. GpGPU has many thousands of registers. X86's register renaming hardware is the workaround.

RISCs do NOT require to have an HIGH register count numbers...
Quote:

Major aspects of the RISC world were assimilated by X86 vendors.

Absolutely NOTHING was assimilated.

RISCs were clearly defined, as I've precisely reported and PROVED on my articles.

And CISCs got NOTHING from those definitions.

But it's true the exact opposite: major aspects of the CISC world were assimilated by RISCs vendors. As I've PROVED on my articles as well.

That's if you have READ and, especially, UNDERSTOOD them. Which is clearly NOT the case, since you've written a big load of complete bullsh!t.