- cross-posted to:
- programming@lemmy.ml
- cross-posted to:
- programming@lemmy.ml
You must log in or register to comment.
Interesting, if old, article.
It was published a while back, but everything it talks about still very much applies today.
Imagining a Non-C Processor
Oh OK, I like this song.
All this argument does is bump up ASM to a low-level language.
I get the resistance in calling C low level but we aren’t about to mistake C runtimes for a JIT.
LLVM certainly makes the comparison easier.
That’s not what the article is saying though. It’s arguing that the memory model that imperative languages assume is not actually how modern chips work. What we end up with effectively is a VM on the chip that pretends to be a really fast PDP-11 style architecture. Writing assembly against this VM still has the same problem. Interestingly, the way modern chips are designed actually fits better with functional style that doesn’t rely on global state.
i got there at the end
Do you think Habit and Ante are better candidates to improve this situation?
I’m not familiar enough with how Habit and Ante represent memory allocation to say, but part of the problem right now is that there’s already a VM baked into the chip to provide the PDP-11 style emulation on top of it. Ideally, we’d want chips that expose their native behavior, and then craft languages to take advantage of it. Similarly to what we’re seeing happening with graphics chips.
Is this issue persistent in RISC-based processors too, like SPARC, POWER or RISC-V? Or is this a modular component that can go in with any architecture?
I imagine it would be the same dynamic, and you could have an emulation layer on the chip with its own instruction set for legacy code while providing direct access to the native instruction set.
