.
I read a couple of good deep descriptions of the machinery in Apple's new M1 chip, an ARM (or AARCH64) implementation which seems to have great performance and insanely great performance per unit power. (I exaggerate.)

Apple's Humongous CPU Microarchitecture

A few quick takeaways:
- fast micros these days (since Alpha!) don't have single-cycle L1 cache - M1 as 3 cycles for L1D, which is best in class
- M1's Firestorm A14 cores have a really wide decode stage, helped by fixed length instructions
- there are just huge amounts of in-flight state

Apple's A14:


Another recent high-performance implementation:
Hot Chips 2020 Live Blog: IBM's POWER10 Processor on Samsung 7nm


Related previous threads:

Modern Microprocessors A 90 Minute Guide!
Readings on high-performance CPU designs
The Architecture of Microprocessors - 1987 book
Microarchitecture wiki and other resources
Two fast micros from the 90's: Alpha, and StrongARM
BOOM - a high performance RISC-V implementation

Ibm has new standard for BCD math (2000?), for new 360 style mainframe computers ( I have no idea what they called today) for things like COBOL, or TAXES or BANKING. I don't see that feature listed with modern cpu's. Is that patented just for IBM, hidden as some special upgrade feature,
or they are so busy having a all singing and dancing cpu, they have never thought about that feature?

I wonder if it is considered part of the floating-point unit (decimal floating-point)

I think: yikes! on a branch miss a lot of cycles would be wasted for the humongous architecture.

According to this overview
https://threadreaderapp.com/thread/1331 ... 03104.html
Apple have added some mechanisms to help their case: a mode with strong memory ordering to help with x86 emulation; something which speeds up reference counting which helps Swift programs; something which specifically helps with JavaScript.

The mysterious “something”. I would think custom instructions in the AArch64 set could have compatibility issues with future ARMs.

I wonder what the percentage improvement in processing speed is compared to a smaller four-wide machine is and versus power consumption as well. For most apps it’s lucky if two instruction execute at the same time. I would think an eight wide machine would sit idle a lot of the time. With all the functional units, bypassing must be pretty large. Fixed length instructions probably really help the design, otherwise a lot of pipelining would be needed in the decode.

> For most apps it’s lucky if two instruction execute at the same time
It does feel like that, from a coding perspective. But seeing how many machines go to such expense to execute more, it can't be so! Perhaps we need a nice graphical simulation of an out of order machine to see which instructions get dispatched, which get stalled, and which get retired.

(It is possible that boring everyday code doesn't have much instruction level parallelism to exploit, but highly optimised crucial routines do, and that's where performance really counts.)

It looks also plausible to me that Apple be heavily working on their own fork of the LLVM compiler to take the most advantage of their new A14 processors. From the point of view of developers, this should only take a recompile of their apps to get the benefits.

It hard to say how faster it will be. Best case timing is not average timing , and the memory cache
affects timing of the whole system. You need balanced system so all has fair share of memory.

Faster is realitive to the user. A better mouse click reponse affects more people than 5% increase in floating point division.

Good point that compiler improvements might bring further gains. (Similarly compiler related, I gather it's an advantage to the M1's emulation of x86 that modern x86 code tends to use a fairly regular subset of x86.)

I found a really nice presentation on the limits to ILP: taking an ideal CPU, seeing how much instruction level parallelism might ideally be extracted from an instruction stream, and then gradually refining the machine (and compiler) to more realistic conditions:
http://www.cse.uaa.alaska.edu/~afkjm/cs ... ations.pdf

Probably via this discussion, one of many about M1: https://news.ycombinator.com/item?id=25257932
where we see
and


See also
Why do ARM chips have an instruction with Javascript in the name (FJCVTZS)?
which is probably the JS assist: one instruction replaces several, for an operation commonly needed by JS engines.

Interesting that you brought that up. When I was looking to port a compiler to my M65C02A soft-core, I did a quick tally of the x86 instructions that the compiler used. As you suggest, for that Pascal compiler, the list shown is below is remarkably short compared to the total number of instructions that the x86 processor itself supports.

Confused here. I have not followed apple, but just what are we emulating that needs
x86 codes?

Apple is in the process of changing their consumer computers from x86 to ARM, and to provide some backward compatibility have an ahead-of-time translation from x86 to ARM. (Also some just-in-time capability I think.) So, with this technology, which they call Rosetta2, users of the new computers can run older software which hasn't yet been ported to ARM. It turns out the performance isn't too bad, which is notable.

Apple proves what "cheap is" umm best CPU, works for computers.
I still remember Dr Dobbs and putting 512KB on a MAC. Ben.

There's little doubt that Apple will provide a smooth transition. In the past they already switched from 68000 to PowerPC and then to Intel. I recall the times where "Rosseta" executed 68000 code in PowerPC macs and you didn't even know unless you looked at the system monitor. IIRC, the technology consists on real time, just-in-time, conversion of target machine code into native code in blocks as the execution progresses, in a way that is transparent to the user and is only performed a single time for any given piece of machine code. So it's not like a machine code interpreter, but a true machine code translator, this is why it is so fast. I also believe that translation from Intel instructions to ARM code is potentially a lot more efficient than 68000 to PowerPC, because ARM instructions and addressing modes are much more alike to Intel's than PowerPC ever was to 68000. [Time to buy a "short" position in Intel stock...]

Nice graph in here of Apple's ARM experience: they've been making fully custom ARMs for 6 years now.
https://www.cs.utexas.edu/~bornholt/post/z3-iphone.html

Also a piece here (from 2018) about cache latencies over various generations:
https://www.anandtech.com/show/13392/th ... -secrets/3