A general programming discussion community.
Rules:
- Be civil.
- Please start discussions that spark conversation
Other communities
Systems
Functional Programming
Also related
- 0 users online
- 6 users / day
- 7 users / week
- 21 users / month
- 111 users / 6 months
- 1 subscriber
- 326 Posts
- 596 Comments
- Modlog
- mods:
- Evan
- @Restioson@lemmy.ml
Interesting, if old, article.
It was published a while back, but everything it talks about still very much applies today.
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.
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.
i got there at the end