> Just suck it up and put the OS interface into your language’s standard runtime.
The OS interface is a huge and complex animal that provides crucial primitives for writing high-performing programs (async IO, memory management, timers, etc.). If you want your language to be practical for system-level programming, you need a 1:1 mapping between them.
Crafting a runtime that abstracts those calls and presents a new world to the programmer adds another layer of complexity and will probably worsen the performance.
> Crafting a runtime that abstracts those calls and presents a new world to the programmer adds another layer of complexity and will probably worsen the performance.
But that’s what the article is calling for — claiming (correctly IMHO) that the C interface is pretty cruddy.
Unfortunately whichever higher level interface you choose will be inappropriate for most languages that aren’t the implementation language. I didn’t mention the 432 by accident: its baked in “object-oriented” architecture turned out not only not to help but instead slowed down the whole processor for no gain.
The only exception is when only one language is intended and there’s a tight coupling between silicon and that language (e.g. the lispm case).
The OS interface is a huge and complex animal that provides crucial primitives for writing high-performing programs (async IO, memory management, timers, etc.). If you want your language to be practical for system-level programming, you need a 1:1 mapping between them.
Crafting a runtime that abstracts those calls and presents a new world to the programmer adds another layer of complexity and will probably worsen the performance.