Conversation

What if C isn't portable, only non-C-compatible architectures went extinct?

I'm half joking, but:

VLIW/EPIC architectures are dead, despite CPUs desperately needing instruction-level parallelism.
Instead of SIMT we have hyperthreading at home, and bug-prone threads with context switching in software.
Instead of hierarchical memory, we waste 8 bytes on all pointers & emulate thread-local memory in software. Larabee was DOA & SIMD barely exists. MOS6502-style stack+registers are only on GPUs.

4
6
0

@kornel Do CPUs desperately need more ILP? I thought modern CPUs were quite crazy good at that (Apple is a good example).

I think the issue is most software isn't parallelizable and sequential code is much easier to reason about... that's why VLIW didn't really catch on. Nobody wants to schedule instructions manually, and compilers aren't any better at it than superscalar CPU frontends.

That's how we ended up with the CPU/GPU dichotomy. Sequential code that can be parallelized at the batch level ("SPMD") runs on multicore CPUs, the subset of that which can process multiple data units at once uses SIMD (manually or autovectorized), and embarrassingly parallel code (low branching) that doesn't need low latency for dispatch ends up as SIMT on GPUs, while still being programmed mostly as sequential code working on a single unit (the parallelization is implemented in hardware/drivers).

At the end of the day there will always be underutilized silicon... any time you have different types of resources (ALUs, etc.) their distribution will never match the usage of real world workloads most of the time.

0
0
0

@kornel Itanium EPIC wasn't that bad at C was it - I seem to remember it was OK at the time? It was quite different than an actual VLIW to program.

1
0
0

@penguin42 @kornel Itanium was a disaster, because it put the burden of predicting hot paths on the compiler.
So, no, it was quite hostile to C.

1
0
0

@kornel Even more non-traditional architectures went extinct long before that. Take Setun as an example. That was a ternary computer and it was very incompatible with C.
https://en.wikipedia.org/wiki/Setun

0
0
0

@ptesarik Ah ok from the hot paths; I guess since most of the IA64 work I did was for a JIT backend, we already knew which hot paths we were working on.

0
0
0
@kornel Well, you can do some crazy stuff. 6502 was quite hostile to C, for example. As are GPUs. You could do 3-state logic, there's no real reason why byte has to have 8 bits, there are other options than two bit complement, and certainly non-C-compatible FPU options. We are quite lucky word is not even crazier than what we have now.
0
0
0