• Guest, The rules for the P & N subforum have been updated to prohibit "ad hominem" or personal attacks against other posters. See the full details in the post "Politics and News Rules & Guidelines."

Nvidia has approached Softbank and is considering buying ARM Holdings

Page 12 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

teejee

Senior member
Jul 4, 2013
322
125
116
That's the only market currently embracing RISC V. They know exactly what software will run on those SoCs, and they can churn out an SoC that has only bare-minimum support for that software/firmware. Hence the appeal of RISC-V.



Let's all take a trip down memory lane by remembering about an Intel SoC called Baytrail. Baytrail had several variants, and Intel practically paid people to use these things (contrarevenue, for the tablet variant specifically). Because Baytrail was cheap-as-in-free, enterprising low-end market OEMs began using the tablet-oriented Baytrail in desktop applications, which wasn't "supposed" to happen. Baytrail-T found its way into set top boxes and mini PCs. Fortunately for people who bought those . . . things, Baytrail-T supported all the same instructions (I think) as other Baytrail products, so it's not like software that worked on one Baytrail wouldn't work on another. Baytrail-T products just ran things very slowly when used in hardware applications that were inappropriate for the SoCs. Not that Baytrail-D was that much better, but oh well.

Now imagine if Baytrail-T had been missing some key ISA features of standard Intel x86 CPUs of the day (and I'm not talking cutting-edge-for-its-time SIMD like AVX). Like . . . I don't know, SSE3 or SSE4. There are probably a fair number of x86 programs out there that won't even boot without SSE4 today, and there were probably some in Baytrail's time that required at least SSE2 or SSE3. A dodgy PC vendor could sell you a Baytrail-T for a song, preloaded with an OS that would boot and some software carefully selected to work without needing whatever ISA extension was missing from this hypothetical Baytrail (let's call it Bayfail). Try loading some third-party x86 software on there and whabam, now you can't run it because . . . SSE2/3 unsupported? What's that? Consumer is confused. Not like the OEM would care. Of course this hypothetical Bayfail would only be intended for, I don't know, an embedded application or a closed-OS consumer device that will never run third-party software anyway (without some hackery). If Intel couldn't stop real-life Baytrail-T from finding itself in applications for which it was never intended, do you think the RISC-V world will fare any better?

Show me a RISC-V vendor that tries to sell a cheap phone SoC that doesn't support RISC-V P, and I'll show you a chincey OEM that will try to slip that SoC into phones that can access an app store with apps that (sometimes) use packed SIMD (presumably as an equivalent to 128b NEON). Someone buys this mysteriously cheap phone, only to discover that now they can't load a whole raft of applications that are supposed to be RISC-V compatible.

ARM dodges this neatly by setting standards for its own designs that are targeted to a specific market. For consumer devices, you can either have Cortex-M for embedded microcontrollers, or you get an A-series chip. And . . . that's about it! As long as the OEM chooses an A-series SoC, all the same instructions will be supported no matter what across that generation. No exceptions. There are some weird circumstances where you have ARM with custom ISA extensions (notably Apple), but that's for a closed software environment. You run exactly one OS from one vendor with apps that follow that vendor's design guidelines (or else). Bottom line is, though, that any application that will run on A76 or A77 will also run on A53. It may be slow on A53, but it'll run. It'll even support NEON.

RISC-V doesn't even try to set standards like that. It really is aimed at embedded where maybe the OEM doesn't want a full-fledged Cortex-M, opting instead for something simpler and cheaper that only needs support for a fraction of the functions offered by ARM's cheapest offering. Also, at least the last time I checked, not all of the RISC-V ISA extensions are "frozen", which means they are subject to change. That could be a mess. And then you have the possibility of propietary ISA extensions . . . ugh.
There will always be extensions under development, that the development is open is good thing. That is not an issue, and you should of course only rely on approved specifications for HW development.


There is also a Risc-V working group called UNIX-Class Platform Specification Task Group that defines common things for more powerful general computer systems.

I don't see any issues for Risc-V to succeed in many different markets, but it will be step by step.
 

Insert_Nickname

Diamond Member
May 6, 2012
3,854
510
126
Now imagine if Baytrail-T had been missing some key ISA features of standard Intel x86 CPUs of the day (and I'm not talking cutting-edge-for-its-time SIMD like AVX). Like . . . I don't know, SSE3 or SSE4. There are probably a fair number of x86 programs out there that won't even boot without SSE4 today, and there were probably some in Baytrail's time that required at least SSE2 or SSE3. A dodgy PC vendor could sell you a Baytrail-T for a song, preloaded with an OS that would boot and some software carefully selected to work without needing whatever ISA extension was missing from this hypothetical Baytrail (let's call it Bayfail). Try loading some third-party x86 software on there and whabam, now you can't run it because . . . SSE2/3 unsupported? What's that? Consumer is confused. Not like the OEM would care. Of course this hypothetical Bayfail would only be intended for, I don't know, an embedded application or a closed-OS consumer device that will never run third-party software anyway (without some hackery). If Intel couldn't stop real-life Baytrail-T from finding itself in applications for which it was never intended, do you think the RISC-V world will fare any better?
Thankfully, x86-64 mandates SSE2 support. Everything above that is optional, but an x86-64 OS and 64bit programs have to use that baseline.

What was a bit nastier was some Baytrails were provided with x86-only UEFIs, so you can't even run a 64bit OS on them.

Otherwise, I agree completely.
 

DrMrLordX

Lifer
Apr 27, 2000
16,371
5,281
136
Thankfully, x86-64 mandates SSE2 support. Everything above that is optional, but an x86-64 OS and 64bit programs have to use that baseline.

What was a bit nastier was some Baytrails were provided with x86-only UEFIs, so you can't even run a 64bit OS on them.
True. It doesn't mandate SSE3 though. And fortunately, "Bayfail" never happened. Even lowly Baytrail-T supports SSE4. I didn't know about the UEFI deficiency though, ouch.

@teejee

We'll see if RISC-V can step in for ARM, but I'm not filled with much confidence if there's a working group pushing the standard forward for "powerful general computer systems". The way I see it, one strident RISC-V vendor needs to aim at a low-end ARM target (A76, I suppose?) and produce an out-of-order RISC-V CPU that supports everything except 128bit operation and quad-precision FP (FP128) to challenge that target. Once someone actually tries to release a phone/tablet/SBC SoC and makes hardware available for hackers, they've established themselves as the de facto standard in the RISC-V world. Then everyone can follow their lead, so that RISC-V will have some cohesiveness.

SiFive hasn't really done anything that fits the bill yet. And I don't know of anyone else selling RISC-V hardware at this time.
 

Hitman928

Platinum Member
Apr 15, 2012
2,774
2,125
136
Even if there is a new administration, is there a promise that they'll lift sanctions against China and it's domestic firms ? That's the only policy that matters. Anything less will be viewed as belligerence to them ...
We won't know unless/until it happens, I am just giving my opinion of what would happen IF the current admin loses in the election.
 

Cogman

Lifer
Sep 19, 2000
10,247
80
91
Now imagine if Baytrail-T had been missing some key ISA features of standard Intel x86 CPUs of the day (and I'm not talking cutting-edge-for-its-time SIMD like AVX). Like . . . I don't know, SSE3 or SSE4. There are probably a fair number of x86 programs out there that won't even boot without SSE4 today, and there were probably some in Baytrail's time that required at least SSE2 or SSE3.
I think you are forgetting some history. AMD and intel have pretty much always had different extensions of x86. It took AMD a couple of years to get SSE2, for example. AMD has not failed as a company (Though, admittedly they've been on the brink a couple of times).

RISC-V doesn't even try to set standards like that. It really is aimed at embedded where maybe the OEM doesn't want a full-fledged Cortex-M, opting instead for something simpler and cheaper that only needs support for a fraction of the functions offered by ARM's cheapest offering. Also, at least the last time I checked, not all of the RISC-V ISA extensions are "frozen", which means they are subject to change. That could be a mess. And then you have the possibility of propietary ISA extensions . . . ugh.
The thing about proprietary extensions is hardly anyone will dare to use them. Very likely what you will see is a standard set of extensions that ultimately get adopted as some standard level of support. Much like you see with video codecs today where several different levels are defined and devices have varying support for each. Eventually, things settle.

You'll probably still see embedded environments exploring on the best mix for cost/performance with the potential for custom ISA. That won't go away, why should it? For SoCs, you'll likely see just a standard set of extensions and nothing else. Heck, you'll likely end up seeing what happened to ARM, that is, 2 or 3 major players that everyone buys SoCs from.
 
  • Like
Reactions: Vattila

DrMrLordX

Lifer
Apr 27, 2000
16,371
5,281
136
I think you are forgetting some history. AMD and intel have pretty much always had different extensions of x86. It took AMD a couple of years to get SSE2, for example. AMD has not failed as a company (Though, admittedly they've been on the brink a couple of times).
They almost did! Several times. Intel frequently used ISA extensions as a way to marginalize competitors (like AMD). AMD's fp performance was quite bad for a long time (due to k6 not having a pipelined fpu, and their reliance on poorly-supported 3DNow! and later XOP). The only thing that really kept AMD alive was that despite ISA extensions, AMD had two advantages:

1). Intel had to cross-license everything, so all such ISA extensions were almost immediately available for AMD to copy
2). The core x86 instruction set didn't change that much, meaning that outside of SIMD extensions, AMD could support everything

That and the x86-64 vs IA64 battle kept AMD in the game.

x86 and x86-64 remained mostly monolithic standards that anyone with a license (even VIA/Zhaoxin!) could copy in perpetuity with absolute confidence that they could make x86 software run. Well, near-absolute confidence. I still remember Dragon Dictate somehow not working correctly on k6 . . .

The thing about proprietary extensions is hardly anyone will dare to use them.
I mean . . . it depends? If they're used in embedded then no one will notice. Until someone takes an SoC intended for embedded, discovers it works great in some set top box or "PC" intended for down-market countries, and louses up the supply chain with an SoC that was never really meant for general-purpose consumer devices. All it'll take is some hardware support from hackers or software vendors that choose to support the device due to its ubiquity, and now RISC-V will be defined for a significant portion of its market by a proprietary ISA extension (and it will also be defined by whichever standard extensions are NOT supported in that SoC). See my post above about Baytrail-T.

Very likely what you will see is a standard set of extensions that ultimately get adopted as some standard level of support.
If that happens, then great, RISC-V is in the game. But if someone really wants to supplant ARM, they're going to have to roll out a not-exactly-performant SoC based on almost every RISC-V extension out there ASAP. It's gotta be out-of-order, it's gotta have functional L1/L2/L3, it's gotta be multicore, it's gotta have a functioning DDR memory controller, all the crap you expect from a phone SoC circa 2018. The exotic packaging and funky interconnects of the future will have to wait. That first-gen of RISC-V SoCs will not be competitive performance-wise, and they probably won't make any money.

If that's the product that defines RISC-V in the eyes of the market, great! As it stands, there seem to be RISC-V devices proliferating now that might not even support extension B, and that seems . . . really weird? Correct me if I'm wrong, but SiFive's top-end RISC-V product doesn't seem to support it.
 

Vattila

Senior member
Oct 22, 2004
541
540
136
For example if someone plans to do a Risc-V smart phone soc, then they will of course collaborate with an owner of a ecosystem/OS (e g Google/Android), otherwise their product won't have a market.
Good point. And the Linux kernel development community will set a standard for RISC-V.
 

Thala

Golden Member
Nov 12, 2014
1,072
412
136
No exceptions. There are some weird circumstances where you have ARM with custom ISA extensions (notably Apple), but that's for a closed software environment. You run exactly one OS from one vendor with apps that follow that vendor's design guidelines (or else). Bottom line is, though, that any application that will run on A76 or A77 will also run on A53. It may be slow on A53, but it'll run. It'll even support NEON.
Where did you get the idea from that Apple has custom ISA extensions?
 

ThatBuzzkiller

Senior member
Nov 14, 2014
979
127
106
Where did you get the idea from that Apple has custom ISA extensions?
There's a custom AMX instruction set on the A13 ...

The ARM architecture is extremely lucky to be able to have a mostly unified compiler. x86 has enjoyed this benefit for many years such as when AMD CPUs could run on Intel compilers even if it did have suboptimal codegen so the in-house develop AMD compiler still offered the most optimal codegen for AMD HW and the same applies respectively for Intel's hardware/software stack ...

If the ARM architecture starts seeing massive implementation differences then it'll means more incentives for the hardware vendors to produce their own compilers just so they can win some more benchmarks at the cost of rendering it incompatible with other ARM architecture implementations ...
 

Doug S

Senior member
Feb 8, 2020
326
455
96
There's a custom AMX instruction set on the A13 ...
Of which there has been zero hint over the past year. Doesn't show up in compilers, or in any code anyone is aware of. Do we even know for sure that the AMX instructions (whatever they are) are part of the CPU's instruction set, rather than the GPU?
 

ThatBuzzkiller

Senior member
Nov 14, 2014
979
127
106
Of which there has been zero hint over the past year. Doesn't show up in compilers, or in any code anyone is aware of. Do we even know for sure that the AMX instructions (whatever they are) are part of the CPU's instruction set, rather than the GPU?
Yes, they are executed in the CPU microcode that some guy reverse engineered so it's not some separate hardware block or a part of the GPU but it's actually taking up real instruction encoding space on the CPU!

Also this won't show up in any open source compiler but it will definitely rear it's head in Xcode when you're using Apple's proprietary fork of the LLVM compiler ...
 

ThatBuzzkiller

Senior member
Nov 14, 2014
979
127
106
Here's what the Chinese state media had to say ...

The fact that the lowest echelons of the government have expressed paranoia should be a cause of concern for Nvidia's acquisition of ARM currently undergoing anti-trust review by Chinese regulators ...

Edit: They really might be going in for the kill ...
 
Last edited:

DrMrLordX

Lifer
Apr 27, 2000
16,371
5,281
136
Oh good, someone wants to downvote me.


This AMX instruction set is seemingly a superset of the ARM ISA that is running on the CPU cores.


There’s been a lot of confusion as to what this means, as until now it hadn’t been widely known that Arm architecture licensees were allowed to extend their ISA with custom instructions. We weren’t able to get any confirmation from either Apple or Arm on the matter, but one thing that is clear is that Apple isn’t publicly exposing these new instructions to developers, and they’re not included in Apple’s public compilers. We do know, however, that Apple internally does have compilers available for it, and libraries such as the Acclerate.framework seem to be able to take advantage of AMX. Unfortunately, I haven't had the time or experience to investigate this further for this article.


Arm’s recent reveal of making custom instructions available for vendors to implement and integrate into Arm’s cores certainly seems evidence enough that architecture licensees would be free to do what they’d like – Apple’s choice of hiding away AMX instructions at least resolves the concern about possible ISA fragmentation on the software side.
Thank you very much have a nice day.
 

NostaSeronx

Diamond Member
Sep 18, 2011
3,188
691
136
Is anyone actually manufacturing this SoC? From what I could tell, you can't buy anything like that from SiFive.
We have to look at China to produce RISC-V first apparently.

Huami Huangshen No. 1(E3-core/"E301") & No. 2(E3-core/"E316") both use SiFive ip(through Starfive?).

The other case is T-Head's 910 core, but it isn't SiFive, while it is Chinese--again.

StarFive is more pro-actively working on custom designs based on templates much faster than SiFive in the US;
- Freedom Revolution -
vs

- Freedom Unleashed -
vs

And, Samsung is apparently hoping to sample a full high-end/ultra-premium RISC-V smartphone sometime this year with SemiFive: https://semifive.com:4438/
RISC-V SGPU should also be used in the above SoC.
 
Last edited:
Apr 30, 2015
124
7
81
Thinking about Nvidia buying ARM Ltd, I still cannot understand this. Softbank bought ARM on the basis of pouring capital in, and increasing the labour force in Cambridge. However, they are planning to retain part of ARM, so it is not clear how much is the net benefit to ARM Ltd of being owned by Softbank; capital in v. asset stripping.
As for Nvidia, they may set up a research centre in Cambridge for AI research, but if this is not legally tranferred to ARM Ltd, as a separate legal entity, then it is not an investment in ARM. Furthermore, Nvidia say that they will use ARM to market and sell Nvidia IP licences, but would they transfer that IP to ARM? It seems unlikely.
Softbank appear to be in financial trouble, and are selling ARM to raise capital.
Nvidia do not seem to have any real justification for owning ARM Ltd. They may copy Softbank and act as asset strippers, after a time.
Currently ARM are in the ascendant, and do not need Nvidia; it is more a case of Nvidia having a limited future, as GPGPUs may not last long as a technical solution.
 

ASK THE COMMUNITY