Follow

C Is Not a Low-level Language

queue.acm.org/detail.cfm?id=32

(Long explanation on what caused Meltdown and Spectre and why we really need some new architectures.)

Honestly, after reading it, I think it's time to ditch the x86 instruction set.

@juliobiason All I can say about it is "duh"…

OTOH, x86 isn't that special, and it's main disadvantage is non-technical, but that it's IP'd, thus can't evolve.

@amiloradovsky You have no idea how much I wanted ARM to be that architecture, but it seems they are doing the same mistakes.

@juliobiason What is ARM? A company existing solely because of the IP and spreading FUD about RISC-V in particular. Nah, next.

@amiloradovsky @juliobiason

Ehhh... ARM actually competes with MIPS who has the same business model.

@klomb @juliobiason were going to compete with -V instead. I mean to open the ISA for implementation by anybody.
Need to check where is that now.

@amiloradovsky @juliobiason What is RISC-V but an open source clone of the 64-bit proprietary Riscs? It's good that it exists, but it's not exciting.

To get a worthy successor to Berkeley RISC, we need new ideas.

@tfb @juliobiason There don't seem to be any new ideas in that area for a long time. My guess, what is a priority now is to sort out the copyright issues, only then one may hope for a progress.

(There are some more constructive thoughts in another branch.)

@juliobiason @amiloradovsky ARM is better on this front than x86, but with ARM64 they've moved closer to the model that article was arguing against.

It's ironic that Itanium was the closest we've seen to what the author was arguing for, and now Intel is the worst offender. I'd really hoped to see Intel try again with Itanium on 10 or 14 nm, but it seems they're all in on AMD64. It's too bad.

@tfb @juliobiason Just a few thoughts:

• even if ARM is just as evil as the x86 oligopoly (which isn't the case, IMO), more competition there is better

• the problem with Itanium was non-technical — it was simply boycotted, because it was no less (or more) IP'd

• looking at the list of Qemu's supported ISAs, I guess, there is plenty of candidates, besides Itanium, to revive…

• AFAIK, no flavor of RISC-V is targeted at HPC, but extending it into EPIC/WLIW isn't the problem, the compilers are

@amiloradovsky @juliobiason It's a chicken/egg problem, a language problem, and a social one. EPIC is interesting, and was successful in a technical sense. The performance of Intel Fortran on IA-64 was fantastic. Intel C got good results, too, though less impressive.

I remember the major objections being that g++/visualc++ codebases didn't run much better there. Today with Spectre and plateauing clocks, things could be different for EPIC.

@tfb @juliobiason And with better libre compilers.

The advantage of explicit parallelism is that the compiler's parallelization is potentially more optimal (shorter time), since it's "window" is only restricted by the available RAM. So, for some programs, it may indeed be faster, but not by far amount.
And the better energy-efficiency. And the lesser complexity, and thus associated risks, of course.

@tfb @juliobiason Anyway, a completely new ISA has not to be owned by a company (or small set of them) in order to expect any wider adoption.

@tfb @juliobiason P.S. By the window I mean the set of elementary blocks on which the dependency graph/matrix is built.

functional.cafe/@amiloradovsky

Sign in to participate in the conversation
Functional Café

functional.cafe is an instance for people interested in functional programming and languages.