In terms of years, not that old.In terms of process, it&#x27;s ancient.

Imagine canning your 7nm process last minute only few years before the chip shortage.Must be the most moronic decision ever.and it&#x27;s not like 20&#x2F;20 hindsight either, because every hardware enthusiast knew at the time Intel was having troubles and was worried TSMC (and Samsung at the time) were going to be the only fabs producing leading edge lithographies.

GF&#x27;s fabs aren&#x27;t that old. They were neck-and-neck with TSMC until 02018, when they could do 12nm: <a href="https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20190107061855&#x2F;https:&#x2F;&#x2F;www.v3.co.uk&#x2F;v3-uk&#x2F;news&#x2F;3061809&#x2F;globalfoundries-drops-7nm-as-amd-goes-to-tsmc-instead" rel="nofollow">https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20190107061855&#x2F;https:&#x2F;&#x2F;www.v3.co...</a>

But that stuff tends to be much lower margin, and while this year you might have the best power&#x2F;price numbers, next year someone figures out their product is even lower power on some newer fab that is slowly lowering its price and now the competition forces the margin even lower. Repeat until you have some 40 year old fabs and no customers.

They decided to pivot to innovation that does not require extreme CMOS scaling. For example, they focussed heavily on ultra-low-power SOI at 28nm.Keep in mind that your iphone only has very few chips in &lt;10nm technology. The rest is using much larger groundrules, even the memory.

SMIC is someone without EUV who is shipping 7nm for two years now.

Not having euv means you have old fabs.

&gt;&gt; Suddenly another company that has (old?) fabs and a cpu design team in-houseGlo-flo is leading edge for anyone without EUV.

Suddenly another company that has (old?) fabs and a cpu design team in-houseThis could be interesting to see how much they try to loss-lead to get market share in the low-end

I think program counter is backed up and branch is just re-executed. Though it&#x27;s annoying if handler wants to skip over faulting instruction (eg. it was a syscall), as it now needs to emulate the branch behavior in software. Most of the complexity is punted on the software, I think only hardware tweak needed is keeping in-delay-slot flag in fault description, and keeping address of currently executing instruction for fault reporting and PC-relative addressing (which probably could be omitted otherwise, keeping only next instruction address would be enough).

Or &quot;make interlocks programmed in software&quot;. But later MIPS versions had hardware interlocks I believe.

It seemed like a good idea in 01981; the purported expansion of MIPS was &quot;Microprocessor without Interlocked Pipeline Stages&quot;, although of course it&#x27;s a pun on &quot;millions of instructions per second&quot;. By just omitting the interlock logic necessary to detect branch hazards and putting the responsibility on the compiler, you get a chip that can run faster with less transistors. IBM&#x27;s 45000-transistor 32-bit RISC &quot;ROMP&quot; was fabbed for use in IBM products that year, which gives you an idea of how precious silicon area was at the time.Stanford MIPS was extremely influential, which was undoubtedly a major factor in many RISC architectures copying the delay-slot feature, including SPARC, the PA-RISC, and the i860. But the delay slot really only simplifies a particular narrow range of microarchitectures, those with almost exactly the same pipeline structure as the original. If you want to lengthen the pipeline, either you have to add the interlocks back in, or you have to add extra delay slots, breaking binary compatibility. So delay slots fell out of favor fairly quickly in the 80s. Maybe they were never a good tradeoff.One of the main things pushing people to RISC in the 80s was virtual memory, specifically, the necessity of being able to restart a faulted instruction after a page fault. (See Mashey&#x27;s masterful explanation of why this doomed the VAX in <a href="https:&#x2F;&#x2F;yarchive.net&#x2F;comp&#x2F;vax.html" rel="nofollow">https:&#x2F;&#x2F;yarchive.net&#x2F;comp&#x2F;vax.html</a>.) RISC architectures generally didn&#x27;t have multiple memory accesses or multiple writes per instruction (ARM being a notable exception), so all the information you needed to restart the failed instruction successfully was in the saved program counter.But delay slots pose a problem here! Suppose the faulting instruction is the delay-slot instruction following a branch. The next instruction to execute after resuming that one could either be the instruction that was branched to, or the instruction at the address after the delay-slot instruction, depending on whether the branch was taken or not. That means you need to either take the fault before the branch, or the fault handler needs to save at least the branch-taken bit. I&#x27;ve never programmed a page-fault handler for MIPS, the SPARC, PA-RISC, or the i860, so I don&#x27;t know how they handle this, but it seems like it implies extra implementation complexity of precisely the kind Hennessy was trying to weasel out of.The WP page also mentions that MIPS had load delay slots, where the datum you loaded wasn&#x27;t available in the very next instruction. I&#x27;m reminded that the Tera MTA actually had a variable number of load delay slots, specified in a field in the load instruction, to allow the compiler to allow as many instructions as it could for the memory reference to come back from RAM over the packet-switching network. (The CPU would then stall your thread if the load took longer than the allotted number of instructions, but the idea was that a compiler that prefetched enough stuff into your thread&#x27;s huge register set could make such stalls very rare.)

Allow me to introduce you to register windows.<a href="https:&#x2F;&#x2F;www.jwhitham.org&#x2F;2016&#x2F;02&#x2F;risc-instruction-sets-i-have-known-and.html" rel="nofollow">https:&#x2F;&#x2F;www.jwhitham.org&#x2F;2016&#x2F;02&#x2F;risc-instruction-sets-i-hav...</a>

Many assemblers had an option to reorder on assembly so you could write it normally, while only taking care to avoid hazards near branches.At least one toolchain would just pad the slots with nops

Whoa, had no idea this existed. Wild stuff. Might be &quot;somewhat&quot; confusing to read assembler code like that without knowing about this particular technique..

SPIM says &quot;all shall be efficient single cycle instructions and to heck with the MHz wars!&quot; &#x2F;s

Put that in your delay slot and smoke it.<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Delay_slot" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Delay_slot</a>I&#x27;m surprised by how many other architectures use it.

That whacky multiplier setup though. Who could&#x27;ve ever foreseen that bottleneck.

MIPS seems like a story of missed (mipsed?) opportunities. If MIPS had really been (or remained) an open architecture, there would have been little need for RISC-V. They had a decade+ head start in terms of tool support and silicon implementation, compressed&#x2F;16-bit instruction formats, full 64-bit instruction sets, and scaling from embedded systems to HPC.

Maybe you shouldn&#x27;t have to, but I still need it explained to me

There are a lot of different CPU IP vendors working on RISC-V. China&#x27;s a big source of it, and I shouldn&#x27;t have to explain why.

Esperanto just shut down. <a href="https:&#x2F;&#x2F;www.eetimes.com&#x2F;ai-startup-esperanto-winds-down-silicon-business&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.eetimes.com&#x2F;ai-startup-esperanto-winds-down-sili...</a>

For ISA? Certainly not. For actual designs, for sure. Why wouldn&#x27;t they unless there&#x27;s some open source designs they&#x27;d be using?

Companies that are putting down millions for fab runs absolutely pay shitloads of money for it. The cost of design and verification of those components is enormous and that&#x27;s mostly what you pay for. People have been shipping Andes and SiFive IP for years now. Downloading source dumps for C910 cores is not the hard part.For most places that kind of high-cost work doesn&#x27;t make much sense when their product isn&#x27;t &quot;a CPU&quot;, and they also typically have to buy other IP anyway like memory controllers or I&#x2F;O blocks -- so buying a CPU core isn&#x27;t that strange in the grand scheme.

They do if they aren&#x27;t implementing the ISA in silicon themselves. Its interesting to see who&#x27;s designs are selling, who&#x27;s aren&#x27;t and why.

I don&#x27;t think people generally pay for RISC-V CPU IP.

How are the various riscv cpu IP vendors generally doing financially?Is this the very beginning of a market consolidation?

(BTW why do you write years with a leafing zero? Do you expect these post to still matter past year 9999?)

off-topic but: I&#x27;ve noticed you prefix years with a zero in your HN comments. First I thought it was just a typo, but I see you&#x27;ve made several comments like that. Is there some significance, or are you just raising awareness of the year 9999 problem?

It was some time ago that MIPS did announce that they had competitive RISC-V cores and had signed customers for them: LG and in the automotive sector. I&#x27;d think those should be taped out by now, but who knows...I think the C910 looks better on paper than it performs in practice. I hope that isn&#x27;t the case for MIPS.

&gt; AFAIK MIPS still hasn&#x27;t shipped a high-end processor competitive with the XuanTie 910 that article is aboutThe last high end MIPS was in the SGI times, 30 years ago.

The critical mass of talent and capital forming in the RISC-V space happened in 02019 at Alibaba: <a href="https:&#x2F;&#x2F;www.cnx-software.com&#x2F;2019&#x2F;07&#x2F;27&#x2F;alibaba-unveils-xuantie-910-16-core-risc-v-processor&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.cnx-software.com&#x2F;2019&#x2F;07&#x2F;27&#x2F;alibaba-unveils-xuan...</a>AFAIK MIPS still hasn&#x27;t shipped a high-end processor competitive with the XuanTie 910 that article is about. And I think the billions of RISC-V microcontroller cores that have shipped already (10 billion as of 02022 according to <a href="https:&#x2F;&#x2F;wccftech.com&#x2F;x86-arm-rival-risc-v-architecture-ships-10-billion-cores&#x2F;" rel="nofollow">https:&#x2F;&#x2F;wccftech.com&#x2F;x86-arm-rival-risc-v-architecture-ships...</a>) are also mostly not from MIPS.

&gt; an ISA that anyone could implement.You want to burn your initial capital on lawyers? This is MIPS we&#x27;re talking about.

It&#x27;s an interesting comparison because MIPS used to occupy the niche that RV does now - an ISA that anyone could implement.Lots of companies had their own mips implementation, but still might use an implementation from mips-the-company because even if you have your own team, you probably don&#x27;t want to implement every core size that you might need. But then for some reason lots of them switched to using ARM, within a few years (in some cases getting an architecture licence and keeping their CPU team).It seems like RV has a more stable structure, as the foundation doesn&#x27;t licence cores, so even if one or two of the implementors die it won&#x27;t necessarily reflect on the viability of the ecosystem

Interesting but complementary foray into owning the end-to-end pipeline of chip design, fabrication, and packaging - especially for embedded use cases.MIPS has also hitched it&#x27;s horse to RISC-V now, and I am seeing a critical mass of talent and capital forming in that space.

AMD&#x27;s former girlfriend now married MIPS. Yikes

GlobalFoundries to Acquire MIPS