[cogman10]

I think that's very much the case.

Qualcomm has been price gouging while limiting features from each new release (for example, the new 888 doesn't have AV1 decode support... WTF!)

This is google forcing them to up their game if they want to keep playing.

Will google keep doing this? Probably not (IMO). Rather, it's likely just a demonstration of "Hey, we don't need you, so straighten up!"

That being said, if Qualcomm ignores them (since Pixel isn't a major player in the phone market) google may keep producing their own chips.

Another interesting aspect here is that Google may decide that they don't want to keep paying for the ARM licenses. This is an avenue for them to start getting RISC-V as a first class Android citizen.

[kevin_thibedeau]

Android on RISC-V will go over as well as it did on Atom. Apps with native ARM code will suck or be unusable.

[cogman10]

I actually think there's a pretty easy way around this for Google. They could create a ARM -> RISC-V translation layer. That works well because RISC-V already has a very limited instruction set. In order to make things fast, you don't need to do a lot of fancy transforms.

The issue with doing the same ARM->x86 translation is the x86 instruction set is vast and to get the best performance requires you effectively use those instructions. That requires you to merge instructions that you wouldn't have merged (think of things like the lea instruction).

There's less of an instruction impedance mismatch going from ARM to RISC-V.

Interestingly, I think going from x86->ARM or RISC-V would present less of a performance problem. That's because most of the work would be splitting one instruction into many. The evidence of this is the x86->IA-64 which resulted in something like a 10->20% performance loss vs a natively compiled IA-64.

[lern_too_spel]

The real risk to Qualcomm is if Samsung uses this in their phones and Chromebooks as well.

[patmorgan23]

Samsung had their own mobile proccesser division as well.