Did I discover the Einstein of trolling?

Jimmyjames

Jimmyjames

Elite Member
Joined
Jul 13, 2022
Posts
1,094
Nothing unusual about trolling or stupidity on Twitter or Reddit (or Macrumors for that matter). Usually you engage or leave well enough alone.

While browsing earlier, I saw what I believe to be the most audacious piece of stupidity or the most spectacular piece of trolling I have ever seen. It has caused me to question the very foundation of my existence, so piercing was it’s insight.

Behold:
1726609858136.jpeg
 
Jimmyjames said:
Nothing unusual about trolling or stupidity on Twitter or Reddit (or Macrumors for that matter). Usually you engage or leave well enough alone.

While browsing earlier, I saw what I believe to be the most audacious piece of stupidity or the most spectacular piece of trolling I have ever seen. It has caused me to question the very foundation of my existence, so piercing was it’s insight.

Behold:
View attachment 31406
Click to expand...
was that on X?

serves you right for being there.
 
Jimmyjames said:
Still better than Macrumors.

In all seriousness it’s still one of the best places for tech information and threads/bluesky/mastodon are much worse unfortunately.
Click to expand...
It's a shame that no other platform has taken it's place but Threads has been a great alternative for me. The biggest problem with X is that they've locked everyone out who doesn't have an account, they're the only platform to do that. We can share from IG, Threads, and Reddit.
 
Perhaps we need a new acronym. ARMv9 is really not "RISC", because it has a few profoundly complex instructions (mostly in the atomic operation area), and a number of instructions that perform elaborate operations (like Neon/SVE). Apple has also added some useful functionality like embedded memory compression.

I would suggest something like "Flexible Regularized Efficiency Architecture" (FREA – I tried to get a "Y" or "J" in there, for the berserkers, but could not think of a word that would fit).
 
The terms are somewhat outdate in general. Even x86 uses some RISC like functions these days, alongside ARM loaning some CISC instructions for more oomph.

I think it'd be more apt to say that a processor is "more RISC," or "more CISC."
 
Renzatic said:
Even x86 uses some RISC like functions
Click to expand...
No, "RISC" is a design principle. x86 does not "use some RISC functions". That makes no sense. It dissects its spaghetti code into micro-ops, which allows it to function at decent speed, but the underlying design principle is very much a not-RISC mess.
 
Yoused said:
Perhaps we need a new acronym. ARMv9 is really not "RISC", because it has a few profoundly complex instructions (mostly in the atomic operation area), and a number of instructions that perform elaborate operations (like Neon/SVE). Apple has also added some useful functionality like embedded memory compression.
I would suggest something like "Flexible Regularized Efficiency Architecture" (FREA – I tried to get a "Y" or "J" in there, for the berserkers, but could not think of a word that would fit).
Click to expand...

You should add "Computing" to get a really FREACy acronym.

BTW, unless I'm missing some obscure instructions, AArch64 should be more RISCy (LDP/STP only handles two registers) than AArch32 (LDM/STM handles up to 16 registers).

EDIT: The author of the book Optimizing PowerPC Code wrote that a better explanation of RISC would be: Reduced Instruction Set Complexity
A lot of people still think that RISC means that a RISC processor has to have a small number of instructions.
 
Last edited:
KingOfPain said:
BTW, unless I'm missing some obscure instructions, AArch64 should be more RISCy (LDP/STP only handles two registers) than AArch32 (LDM/STM handles up to 16 registers).
Click to expand...
AArch64 has a small set of ops that modify a memory location based on math with a register: read-modify-write operations, which are also atomic (that is, to they are for use with semaphores/mutexes). These are very much not RISC in nature. There are also the rather elaborate Neon load-gather and store-scatter ops, and the recently added memory block move ops (vaguely similar to x86 REP MOVS ops, but a different type of implementation).

x86 has some ops that were really handy in 1982 but seriously compromise efficiency in the modern age, so optimizing compilers almost never generate them, but the CPU still has to support them. The FREAC principle avoids general use operator forms that offer marginally useful features, opting instead to expand that edge-case functionality into multiple ops.
 
Yoused said:
Perhaps we need a new acronym. ARMv9 is really not "RISC", because it has a few profoundly complex instructions (mostly in the atomic operation area), and a number of instructions that perform elaborate operations (like Neon/SVE). Apple has also added some useful functionality like embedded memory compression.

I would suggest something like "Flexible Regularized Efficiency Architecture" (FREA – I tried to get a "Y" or "J" in there, for the berserkers, but could not think of a word that would fit).
Click to expand...

Legacy Overt Support Enabled Runtime

for CISC
 
Yoused said:
AArch64 has a small set of ops that modify a memory location based on math with a register: read-modify-write operations, which are also atomic (that is, to they are for use with semaphores/mutexes). These are very much not RISC in nature. There are also the rather elaborate Neon load-gather and store-scatter ops, and the recently added memory block move ops (vaguely similar to x86 REP MOVS ops, but a different type of implementation).

x86 has some ops that were really handy in 1982 but seriously compromise efficiency in the modern age, so optimizing compilers almost never generate them, but the CPU still has to support them. The FREAC principle avoids general use operator forms that offer marginally useful features, opting instead to expand that edge-case functionality into multiple ops.
Click to expand...

I don't know enough about NEON, but every instructions that operates more like a loop certainly shouldn't be classified as RISC.
I concur that read/write (similar to the 68K TAS "test and set" or the x86 XCHG "exchange") isn't really RISC either. I believe MIPS was using "load locked", i.e., the semaphore was read and locked at the same time and then a separate write would reserve it, if the read confirmed that it was free.
 
Back
Top