@Hammer

Quote:

Hammer wrote: @cdimauro VPGATHERDD ymm1, (edx+ymm0*1), ymm2 ;The instruction conditionally loads 8 dword values from memory addresses specified by the memory operand (the second operand) and using dword indices. Try again.

YOU:

"AVX2's gather instruction can load many 32-bit data elements from a pointer list."

REALITY (also reported by your comments!):

"using dword indices"

RESULT: INDICES are NOT POINTERS!

FYI, Gather and Scatter instructions use INDICES lists. NOT POINTERS lists.

Understood now? "Genious"!

cdimauro Quote:

RESULT: INDICES are NOT POINTERS! FYI, Gather and Scatter instructions use INDICES lists. NOT POINTERS lists.

The unusual 68k mem,mem operations are sometimes criticized for allowing two pointers which may require 2 ATC/TLB lookups. The 68060 supposedly handles these instructions by splitting them into two internal instructions without even using microcode. The 68k mem,mem operations are common, simple, limited and improve code density so I believe they are worth it but more than two pointers for a few rarely used SIMD instructions, probably not so much.

@matthey

Quote:

matthey wrote: cdimauro Quote: RESULT: INDICES are NOT POINTERS! FYI, Gather and Scatter instructions use INDICES lists. NOT POINTERS lists. The unusual 68k mem,mem operations are sometimes criticized for allowing two pointers which may require 2 ATC/TLB lookups.

I don't know who it was who criticised them, but these are criticisms that leave time to be found, since those are details which belong to the IMPLEMENTATION of an ISA and not the ISA itself.
Quote:

The 68060 supposedly handles these instructions by splitting them into two internal instructions without even using microcode.

This could be an implementation, but what about using two (parallel) EAs in the pipeline, and breaking the instruction into two micro-ops only if both EAs refer an element in memory? I mean, if the 2 TLB lookup per cycle cannot be supported.
Quote:

The 68k mem,mem operations are common, simple, limited and improve code density so I believe they are worth it

Absolutely! mem,mem operators are so useful and powerful. So much, that I've also mem,mem,mem in my new architecture, even for vector instructions.

Code density might not always be improved, but the number of executed instructions & used registers & pipeline dependencies can be consistently reduced, with a general benefit in terms of performance and less power consumption.
Quote:

but more than two pointers for a few rarely used SIMD instructions, probably not so much.

They aren't rare. Gather/Scatter instructions are fundamental operations when you have to deal with sparse arrays, or structures which have some pattern from/to which extract / insert data.

Those instructions were first being widespread with (GP)GPUs, and then borrowed by regular CPUs for SIMD/vector extensions / units, because they were very useful there.

However and on the other side, they are very complicated to implement and work. In fact, they pose serious issues when dealing with exceptions (e.g.: page faults, divisions by zero, illegal FP operations, etc.), which require ad hoc solutions to be adopted to properly handle those cases.

BTW, my new architecture supports mem,mem,mem vector instructions where the destination can be a scattered location and the two sources could be gathered locations. So, adding even more complexity. But with greater flexibility as well.

cdimauro Quote:

I don't know who it was who criticised them, but these are criticisms that leave time to be found, since those are details which belong to the IMPLEMENTATION of an ISA and not the ISA itself.

Some RISC proponents still criticize 68k 40 year old complexity as if the 68k is more complex than modern "RISC". I had the user Minator recently explain to me on this forum all the disadvantages of the 68k.

https://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=43330&forum=16&start=380&viewmode=flat&order=0#874314 Quote:

I guess the idea of an ASIC 68K is kind of cool, but it's not very realistic. Even if it could be built, it'll be slow. If you increase clock speed by 10X the cycle time reduces by 10X, however this also means latency goes up by 10X the clock cycles. Without all the modern mechanisms used to deal with this, the CPU will be constantly stalling. I doubt it'll get anywhere near the performance of an Arm A53, never mind Arm's OOO cores. The 68K instruction set won't help, multi-length instructions makes instruction decoding complex and unpredictable, trying to prefetch is going to take a load of complex logic. Then you've got potential page faults in the middle of instructions, and how 68K handles exceptions is even worse.

He did not even mention 68k two pointer ATC/TLB accesses per instruction making exceptions harder too. Modern RISC cores all use scalar classic RISC pipeline designs with only single cycle throughput simple fixed length encoded instructions of a reduced instruction set with few addressing modes and no microcode, of course.

cdimauro Quote:

This could be an implementation, but what about using two (parallel) EAs in the pipeline, and breaking the instruction into two micro-ops only if both EAs refer an element in memory? I mean, if the 2 TLB lookup per cycle cannot be supported.

Each execution pipeline (pOEP and sOEP) of the 68060 can perform an EA calc with ATC/TLB lookup and memory access (EAs that do not access memory should not perform an ATC/TLB lookup). A MOVE mem,mem requires two cycle throughput where most MOVE reg,mem and MOVE mem,reg instructions have single cycle throughput. Would it be possible to perform a MOVE mem,mem in a single OEP in a single cycle instead of splitting the instruction and taking 2 cycles? Tricky but maybe if the store can go into the store buffer but the ATC/TLB lookup may need to be performed first and I doubt it is worth it to allow two ATC/TLB lookups per OEP per cycle. The 68060 could be improved by allowing instructions longer than 6 bytes to execute in a single cycle so most MOVE #imm,mem instructions and longer addressing modes can have single cycle throughput and it may be possible for the sOEP to perform the load of a MOVE mem,mem instead of waiting for the pOEP. There is plenty of room for 68060 performance improvements.

cdimauro Quote:

Absolutely! mem,mem operators are so useful and powerful. So much, that I've also mem,mem,mem in my new architecture, even for vector instructions. Code density might not always be improved, but the number of executed instructions & used registers & pipeline dependencies can be consistently reduced, with a general benefit in terms of performance and less power consumption.

Two load TLB lookups and memory accesses should be possible in parallel with dual ported accesses. Big modern x86-64 OoO cores likely could execute VAX code well enough too but all memory operations without using registers would likely reduce parallel code execution as memory accesses are more expensive and limited than register accesses.

cdimauro Quote:

They aren't rare. Gather/Scatter instructions are fundamental operations when you have to deal with sparse arrays, or structures which have some pattern from/to which extract / insert data. Those instructions were first being widespread with (GP)GPUs, and then borrowed by regular CPUs for SIMD/vector extensions / units, because they were very useful there. However and on the other side, they are very complicated to implement and work. In fact, they pose serious issues when dealing with exceptions (e.g.: page faults, divisions by zero, illegal FP operations, etc.), which require ad hoc solutions to be adopted to properly handle those cases. BTW, my new architecture supports mem,mem,mem vector instructions where the destination can be a scattered location and the two sources could be gathered locations. So, adding even more complexity. But with greater flexibility as well.

The argument could be made that all SIMD instructions are rarely used. SIMD unit instructions are not rare on x86-64 because the SIMD unit is the FPU replacement but scalar operations are more common than SIMD operations. Auto vectorization has come a long way for architectures with standard SIMD units but I guess it depends on your definition of rare. I get that gather/scatter instructions are valuable for a SIMD unit.

Last edited by matthey on 29-Nov-2024 at 07:09 AM.
Last edited by matthey on 29-Nov-2024 at 07:07 AM.

@matthey and @cdimauro

What's the point with all this endless ranting up and down about stuff that never will materialise? What's the goal of it all?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

What's the goal of it all?

I think by now that would be obvious:

42

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@kolla

Quote:

kolla wrote: @matthey and @cdimauro What's the point with all this endless ranting up and down about stuff that never will materialise? What's the goal of it all?

Entertainment

@kolla

no goal

@OneTimer1

Quote:

Entertainment

Are they still entertained though? It's moving along very slowly and repetitively... almost have to throw in some BS "bait" just to stir things up every now and then.

So here goes... screw damn hippie archs like m68k! MIPS and LoongArch FTW!

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

kolla wrote: @matthey and @cdimauro What's the point with all this endless ranting up and down about stuff that never will materialise? What's the goal of it all?

Thread:

"what is wrong with 68k"


@OneTimer1

Quote:

OneTimer1 wrote: @kolla Quote: kolla wrote: @matthey and @cdimauro What's the point with all this endless ranting up and down about stuff that never will materialise? What's the goal of it all? Entertainment

Also


@pixie

Quote:

pixie wrote: @kolla Quote: What's the goal of it all? I think by now that would be obvious: 42

@OlafS25

Quote:

OlafS25 wrote: @kolla no goal

@kolla

Quote:

kolla wrote: @OneTimer1 Quote: Entertainment Are they still entertained though? It's moving along very slowly and repetitively... almost have to throw in some BS "bait" just to stir things up every now and then.

Actually it's the most interesting stuff which is circulating here.

Besides that, what else is interesting? You Linux crusade? :
Quote:

So here goes... screw damn hippie archs like m68k!

Good.
Quote:

MIPS and LoongArch FTW!

Not good.

@matthey

Quote:

matthey wrote: cdimauro Quote: I don't know who it was who criticised them, but these are criticisms that leave time to be found, since those are details which belong to the IMPLEMENTATION of an ISA and not the ISA itself. Some RISC proponents still criticize 68k 40 year old complexity as if the 68k is more complex than modern "RISC". I had the user Minator recently explain to me on this forum all the disadvantages of the 68k. https://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=43330&forum=16&start=380&viewmode=flat&order=0#874314 Quote: I guess the idea of an ASIC 68K is kind of cool, but it's not very realistic. Even if it could be built, it'll be slow. If you increase clock speed by 10X the cycle time reduces by 10X, however this also means latency goes up by 10X the clock cycles. Without all the modern mechanisms used to deal with this, the CPU will be constantly stalling. I doubt it'll get anywhere near the performance of an Arm A53, never mind Arm's OOO cores. The 68K instruction set won't help, multi-length instructions makes instruction decoding complex and unpredictable, trying to prefetch is going to take a load of complex logic. Then you've got potential page faults in the middle of instructions, and how 68K handles exceptions is even worse. He did not even mention 68k two pointer ATC/TLB accesses per instruction making exceptions harder too. Modern RISC cores all use scalar classic RISC pipeline designs with only single cycle throughput simple fixed length encoded instructions of a reduced instruction set with few addressing modes and no microcode, of course.

Those critics are without foundations.

First, all mainstream RISC architectures have similar problems. And all of them have gather / scatter instructions which are way more complicated compared to the most complicated 68k instruction.

Second, x86/x64 has already shown that it's possible to have better performance than all RISC processors, and even with competitive power consumption: The final ISA showdown: Is ARM, x86, or MIPS intrinsically more power efficient?

Why 68k should do much worse? The most complex thing is represented by the double memory indirection addressing modes, which could be relegated to a couple of micro-ops, when it's needed.
Quote:

cdimauro Quote: This could be an implementation, but what about using two (parallel) EAs in the pipeline, and breaking the instruction into two micro-ops only if both EAs refer an element in memory? I mean, if the 2 TLB lookup per cycle cannot be supported. Each execution pipeline (pOEP and sOEP) of the 68060 can perform an EA calc with ATC/TLB lookup and memory access (EAs that do not access memory should not perform an ATC/TLB lookup). A MOVE mem,mem requires two cycle throughput where most MOVE reg,mem and MOVE mem,reg instructions have single cycle throughput. Would it be possible to perform a MOVE mem,mem in a single OEP in a single cycle instead of splitting the instruction and taking 2 cycles? Tricky but maybe if the store can go into the store buffer but the ATC/TLB lookup may need to be performed first and I doubt it is worth it to allow two ATC/TLB lookups per OEP per cycle.

You don't necessarily need to split the instruction, unless for the double memory indirection addressing modes, as I've said before.

There are execution patterns that could allow to use both AGUs (EA units), for example. Or just add some delay until the EA can be calculated.

MOVE is the most simple instruction which could take advantage of those situations.

The most critical instructions are the ones which need to read from two memory locations, because in this case a delay must be introduced. Here you can think about splitting the instruction into two micro-ops (at least).
Quote:

The 68060 could be improved by allowing instructions longer than 6 bytes to execute in a single cycle so most MOVE #imm,mem instructions and longer addressing modes can have single cycle throughput and it may be possible for the sOEP to perform the load of a MOVE mem,mem instead of waiting for the pOEP. There is plenty of room for 68060 performance improvements.

Exactly. The 68060 had a good enough design for its goals, but it's too little nowadays, and a modern 68k should go beyond it (even whilst keeping the in-order nature).
Quote:

cdimauro Quote: Absolutely! mem,mem operators are so useful and powerful. So much, that I've also mem,mem,mem in my new architecture, even for vector instructions. Code density might not always be improved, but the number of executed instructions & used registers & pipeline dependencies can be consistently reduced, with a general benefit in terms of performance and less power consumption. Two load TLB lookups and memory accesses should be possible in parallel with dual ported accesses.

With two pipelines, that's a must have.
Quote:

Big modern x86-64 OoO cores likely could execute VAX code well enough too but all memory operations without using registers would likely reduce parallel code execution as memory accesses are more expensive and limited than register accesses.

Yes, but it depends on the goal for the specific microarchitecture. If the core should be simple and small, then having mem-mem-mem instructions instead of a larger number of registers could be a possible solution.
Quote:

cdimauro Quote: They aren't rare. Gather/Scatter instructions are fundamental operations when you have to deal with sparse arrays, or structures which have some pattern from/to which extract / insert data. Those instructions were first being widespread with (GP)GPUs, and then borrowed by regular CPUs for SIMD/vector extensions / units, because they were very useful there. However and on the other side, they are very complicated to implement and work. In fact, they pose serious issues when dealing with exceptions (e.g.: page faults, divisions by zero, illegal FP operations, etc.), which require ad hoc solutions to be adopted to properly handle those cases. BTW, my new architecture supports mem,mem,mem vector instructions where the destination can be a scattered location and the two sources could be gathered locations. So, adding even more complexity. But with greater flexibility as well. The argument could be made that all SIMD instructions are rarely used. SIMD unit instructions are not rare on x86-64 because the SIMD unit is the FPU replacement but scalar operations are more common than SIMD operations. Auto vectorization has come a long way for architectures with standard SIMD units but I guess it depends on your definition of rare. I get that gather/scatter instructions are valuable for a SIMD unit.

They are much rarer compared to the regular scalar instructions, but when they are needed... can make a HUGE difference.

A recent example: https://whatcookie.github.io/posts/why-is-avx-512-useful-for-rpcs3/
Quote:

The performance when targeting SSE2 is absolutely terrible, likely due to the lack of the pshufb instruction from SSSE3. pshufb is invaluable for emulating the shufb instruction, and it’s also essential for byteswapping vectors, something that’s necessary since the PS3 is a big endian system, while x86 is little endian.

With SHUFB, the PS3 emulator jumped from 5 to 166 FPS...

@kolla

Quote:

@OneTimer1 Quote: Entertainment Are they still entertained though? It's moving along very slowly and repetitively...

Try to ignore posts that are leading away from the topic.

Not easy, because I don't think the OP really wanted to learn, why 68k has turned to be wrong.

@OneTimer1

Quote:

OneTimer1 wrote: @kolla Try to ignore posts that are leading away from the topic. Not easy, because I don't think the OP really wanted to learn, why 68k has turned to be wrong.

Maybe you can take the chance and show the technical reasons for your statement.

And also show why x86 is still here, even being wronger compared to 68k...

@cdimauro

Quote:

You Linux crusade?

What crusade, it’s typically matthey that keeps bringing in Linux for no good reasons at all.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@cdimauro

Quote:

cdimauro wrote: And also show why x86 is still here, even being wronger compared to 68k...

Easy:

Because x86 x86 enjoyed further development because 90% of hardware manufacturers used it for their desktop PCs, where 68k was abandoned by its owner.

@kolla

Quote:

kolla wrote: @cdimauro Quote: You Linux crusade? What crusade, it’s typically matthey that keeps bringing in Linux for no good reasons at all.

It's the exact opposite: he gave good (technical) reasons.

Which you still don't get, because you stopped to the "equation" support + diffusion = good.

As I've also tried to explain you more times.

@OneTimer1

Quote:

OneTimer1 wrote: @cdimauro Quote: cdimauro wrote: And also show why x86 is still here, even being wronger compared to 68k... Easy: Because x86 x86 enjoyed further development because 90% of hardware manufacturers used it for their desktop PCs, where 68k was abandoned by its owner.

Then you can say that 68k wasn't lucky.

Not that it was (technically) wrong.

Words are important...

Last edited by cdimauro on 30-Nov-2024 at 03:34 PM.

@cdimauro

Quote:

cdimauro wrote: Not that it was (technically) wrong. Words are important...

Well, the 'not available' is a technical term, it makes technicians staying away from it.

Last edited by OneTimer1 on 30-Nov-2024 at 06:02 PM.

@OneTimer1

Quote:

OneTimer1 wrote: @cdimauro Quote: cdimauro wrote: Not that it was (technically) wrong. Words are important... Well, the 'not available' is a technical term, it makes technicians staying away from it.

There's no development anymore (I mean: from chip companies), but 68k processors are still produced and available.

Which is still a different concept and it's far away from the "wrong" term that you've used.

@cdimauro

Quote:

cdimauro wrote: but 68k processors are still produced and available.

They are about as "available" as spare parts for Ford Model Ts.

And about as relevant....


68k died because Motorola came to the conclusion that further development of that line made no economic sense and beyond a last hoorah (68060) and some legacy product (ColdFire) nothing really happened in over 30 years.

But I'm sure you gonna drag that dead horse over at least another dozen pages.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada