Binning is definitely a possibility. Separately from binning, there are often just features that don't work right and get disabled with "chicken switches" or "feature enable bits."
Any two-ANE design would have a lot of control logic that has to be right, e.g., to manage which work gets sent to which ANE, which cache lines get loaded, etc. It's easy to imagine bugs in this logic which would only show up when both ANEs are enabled. So it's likely that there is a chicken bit that you could use to disable one of the ANEs and run in single-ANE mode.
Counter-opinion: industry simply has no plausible alternative to Verilog/SystemVerilog and succeeds in producing chips only in spite of the language's glaring flaws.
I worked for several years at a world class company verifying CPU designs. Even into the late 2010s, designers were afraid to use basic features like structs because who knows what tool might not support it correctly. They emulated structures using piles of defines that set all the bit offsets. I wouldn't know how to begin to estimate the amount of senseless work that this led to during debugging. The lack of any type safety was appalling. If you were lucky, you could catch gross type confusion by having a linting tool notice a size mismatch. These tools found hundreds of real errors that should never have compiled in the first place. I could go on and on...
But there's no escaping it. There are so many amazing tools built around it. The vendors love the moat the complexity gives them. The IP developers have huge investments in legacy code bases. Compatibility is worth too much.
FWIW -- A later, vaguely related project was Jitawa[1]. Its Lisp dialect was not as fancy as VLISPs, but its verification was much more thorough (machine checked proofs down to the X86 code for the runtime.)
Today, ongoing, CakeML[2] extends these techniques to an ML language and is just generally super awesome.
Maybe the magic is just the discipline to somehow keep tuning and optimizing everything across the chip. Year after year they release another power-sipping design with another 10-20% performance. It's not a sudden tsunami, but an ever rising tide.
It does seem like TSMC has strong leverage since it would take Apple a lot of time and work to move to a competitor.
On the other hand, the incentives seem pretty well aligned. TSMC presumably makes a lot of money when Apple is successful and sells a lot of chips. Having a customer that is demanding and willing to pay for huge volumes of bleeding edge parts helps TSMC build on their lead. Having early access to the best process helps Apple differentiate, and their business model gives them the margins to afford all of this.
Anyway, I don't see why either side would want to really change this setup.
If it can emulate x86, is there really a motivation for developers to switch to ARM? (I don't have an M1 and don't really know what it's like to compile stuff and deploy it to "the cloud.")
For other ARM manufacturers, I wonder how much of this is a software problem.
I mean, what would the market be for a super-fast ARM laptop/desktop machine? It would run Windows RT, I guess?
How much better than Intel/AMD would the ARM machine need to be to justify buying it and running that? It seems like the M1's "magic" is not just the chip, but very much also the Rosetta thing.
I'm a free software fan, but I don't see that open source matters here.
How do you know the machine is running the program whose source code you're looking at, instead of some other program that looks superficially like it?
If a machine produces convincing evidence of what it has done, e.g., a print-out that (1) the voter can meaningfully check before depositing, and that (2) is audited with at least spot checks or formal recounts later, why does it matter whether it is open or closed source?
I heard (discussions with folks online) that in other parts of the state they are still using the older machines, which the voter just has to trust to record their selections correctly. I think I've heard they are transitioning away from these.
I think "fast, cheap, good, pick 2" applies. Obviously the current bloated, ad-laden state of the web is pretty horrible and indefensible. But if we can keep making compute faster, it should ultimately save programmer time, which can be used to either get cheaper or better programs.
"Penalties in this section do not apply to users of tiktok"
https://leg.mt.gov/bills/2023/billpdf/SB0419.pdf