Intel Reportedly Interested In Acquiring RISC-V Firm SiFive

[skeevy420]

Well not really 'cos you're still trying to qualify, say, the x86 latest iteration, AMD64 instruction set, as "RISC". The implementation may be use RISC concepts inside but to the outside world, this remains a quintessentially CISC instruction set and the last one really remaining of its kind so it's kind of a stretch to call it RISC.

It's a bit like saying because HACK, the facebook modern iteration of PHP, now uses a JIT, it's Java.

Alternatively, we can swing your argument around. Okay, let's assume modern x86 is RISC. That means there is no CISC anywhere anymore. So why are we talking about RISC as a demarcator of difference, if everything is RISC? The entire argument becomes moot.

yeah I'm being slightly pedantic about this but really x86 is not RISC unless you really stretch the definition down to deeply buried logic paths which nobody can see.

It is. My last discussion was ended when bridgman corrected me about Zen -- RISC internals with instructions on top to simplify it. I believe some of the Intel people corrected me in the same way. I'm just repeating what the people who work for the companies told me. I'll take their opinion on this matter over anyone else's.

....really??? If modern x86 is RISC then this potentially has everything to do with everything and would make the purchase or consideration of SiFive totally not moot.

Intel RISC internals; SiFive RISC patents. I don't see the correlation. You're right. It is totally moot.

[Syfer]

Correct me if I'm wrong, but has any company used Intel fabs and not been approached about being acquired by Intel? They've already bought a machine learning accelerator company using their fabs and now they're interested in buying SiFive. Is Intel's drive to have their fabs used by more companies all about selecting new targets to acquire?

[edwaleni]

Hot take: the world would be a better place if companies simply could not buy other companies. It should be seen as an anti-trust violation.

Then we would still have a dozen flavors of Unix System V, who knows how many RISC implementations and they would all be charging DEC and IBM levels of prices.

[andresdju]

On the other hand, by now both Android and iOS ecosystems are married to ARM. There's way too much legacy prioprietary blobs for a switch to a different arch to be interesting.

This isn't true at all, Android doesn't depend on any proprietary blob to run, is the devices' hardware what requires proprietary blobs to run Android. For example, Android has an interface for image hardware composition (HWC), if your hardware has a linux drm driver you can run drm_hwcomposer (free software) instead of any HWC proprietary blob. Some quite common smartphones used x86 in fact (like most Asus Zenphone and some Zenphone 2) and Android x86 is still maintained (running mostly on top of mainline linux interfaces). Replicant also works without proprietary blobs even using the Lima drive. The hardest part of porting Android to RISC-V is probably porting bionic (Android's C library) and ART (Android Runtime) and configuring a riscv build system. Of course you can't run Android apps that use native code for other archs.

Android has run on arm, arm64, x86, x86-64, mips... and now it has been ported to riscv. Are the devices manufacturers who have chosen ARM, not Google.

Linux by being opensource is much more nimble, so a Linux-running, Intel RISC-V powered smartphone is technically feasible.

Android _is_ a Linux operating system.

But not as much marketable as it will be missing the large app ecosystem.
(See the success of Ubuntu Touch which still doesn't have out-of-the-box anbox, ...)

The difficulty of anbox is running Android interfaces (like HWC or binder) on top of non-Android interfaces (like Wayland, systemd or dbus) not running on x86 or riscv.

(Contrast with stuff like Jolla's Sailfish OS which even if it has only a small niche following is still alive and going, because is offers access to the wide app ecosystem).

Sailfish OS uses libhybris to run on top of the proprietary blobs you were complaining about, and it isn't totally open source.

The reason I am happy for device that officially support running Linux mainline.

I totally agree on that.

[juarezr]

Hot take: the world would be a better place if companies simply could not buy other companies. It should be seen as an anti-trust violation.

Hotter take: the world would be a better place if the workers owned the means of production.

Hotter polemic takes:

• "the world would be a better place if" ramblings hardly materializes to real world.
• Power structures aren't willing to change the existing rules because it would either affect or destroy them.
• Keeping the discussion polarized between Red/Blue, Capitalist/Comunist, blessed/damned is a convenient way to:
  • divert people attention from power structures modus operandi, unequality, unfairness, or tirany.
  • find a scape goat to explain people suffering (even when it don't justifies)
  • survive an thrive agains other power structures and people dissatisfaction
• There will be always one or many power structures at many levels of hierarchy and coverage over people
  • Any power structure will float between levels of democracy and tirany
  • People are lucky if live in places where they are united enough to force a high level of democracy
  • It's easier to few people control and manipulate the situation than every people to become wise and agree to avoid it.
• If all resources in our planet would be fairly and equality distributed there wold be only poor people.

[juarezr]

We're talking Intel's "Roots". The "roots" of X86 are the 8086, the 80286 thru 80486. These were all CISC. Indeed throughout the early 90s the debate raged about Intel in the CISC corner and everyone else going RISC. Only by the time the "80586" (aka Pentium) came around did Intel embrase internal RISC but the exposed external instruction set is, was, and will be, most definitely CISC. Intel == CISC especially if you're talking about "roots".

Yes!

From that I have read:

• RISCV is:
  • a RISC ISA
    • chosen to be compiler friendly
    • chosen to be flexible, adaptative, and extensible
  • a register style processor (load/store) regarding memory
• x86 is until today:
  • a CISC ISA regarding programmer, compiler, or assembler interface
  • a Stack machine style processor (push/pop) regarding memory
    • however, Intel evolved x86 to a register machine style for performance reasons
    • this was done by establishing conventions on how to write x86 assembly to access virtual/fake register besides the few original basic ones
  • CISC model was chosen in 8086 aiming to be programmer-friendly
    • Because of this, there is a lot of instructions suited to please the user
    • Assembly programming nowadays is done by the programmer only for high-performance algorithm tunning. All hard work it up to languages, compilers, and toolsets.
  • We don't know exactly if x86 processors use RISC models inside their cores:
    • probably the instruction will vary between processors architecture families, sizes, and destinations
    • probably the instruction could apply to different parts of the processor's pipelines (like execution, retirement, reservation, ALU, SIMD, cache) instead of a whole processor RISC instruction

The main differences between the ISA architectures/models for a similar target processor remain:

• the concurrency/acceptance between companies/community/players
• the budget and the design/execution competency for creating a processor/architecture ecosystem
• the existing traction on software compatibility and software disponibility
• the extra cost of gates in silicon for an x86 to microcode decoder
• the extra power used by the microcode decoder
• the impact in caches due to higher size of RISC generated code (softened by compressed instruction like ARM's thumb or RISC-V C instruction sets)
• some branch prediction extra complexity for x86 designs

[ryao]

Back in March during the announcement of Intel Foundry Services it was mentioned that SiFive and Intel were working together to allow RISC-V chips to be fabbed within Intel's facilities.

In hindsight, this was a trap. It seems as if anyone that is permitted to use Intel foundary services is an acqusition target. The work in getting their stuff onto Intel's foundary services seems to be the first step of the acqusition. In the past, I would not say that, but we saw this happen with Altera and now Intel is trying to do it with SiFive. It is not clear to me if there is any company allowed to use Intel's foundary services that is not an acquisition target. :/

[ssokolow]

Android _is_ a Linux operating system.

Android is an operating system with a Java-based primary API which happens to use the Linux kernel as an implementation detail.

When people talk about Linux as an operating system, they're generally talking about "An operating system based on the Linux kernel which exposes POSIX as its primary core API and X11 or Wayland as its primary GUI API"... and they're possibly specifically thinking about only the ones which expose a glibc-compatible libc ABI.

[jayN]

Intel's eyeq5 Mobileye chips are built with MIPS chips. The MIPS chips are going to switch to use RISC-V, according to announcements in April. I wonder if part of Intel's interest is to make sure they have input into the new designs, to guarantee the continuation of the features they need for the automotive safety concerns.

[jayN]

Codeplay reportedly worked on SYCL and openCL support for RISC-V, which would be required for support in Intel's oneAPI.
Intel is the innovator behind CXL. They could conceivably support RISC-V chips as CXL slave accelerators.