4 ms·

I'm not sure that that is much related to systems programming, that sounds like a pretty high level library feature.

by rpnx 3y ago

simonblack 3y ago
I don't see it like that. I see it as the system having only one interface with all peripherals. Or conversely, all peripherals get treated exactly the same way. Maybe something as simple as: "Are you ready to send me data?" "Send me data" (Some predefined size of data, maybe an 8-bit byte, maybe a 32-bit word, but only one defined size of data.) "Are you ready to receive data?" "Receive this data." That goes down into the bowels of the system, probably at the hardware level. And the architecture of the interface has to be part of the low-level system language otherwise it gets fragmented. But then again, I'm not a systems programmer so what I'm looking for may not be possible.
- AlotOfReading 3y ago
  There's quite a lot of details that go into something like that and it's often not possible for the code to know all of them. Languages will sometimes abstract similar things out (e.g. have a function call run on some other processor across a network/bus and get the results), but it's quite a high level feature. Systems programmers tend to demand a lot of visibility into what, when and how every line of code executes instead of abstracting that behind the language runtime. For example, a systems programmer might care that the data being received is transferred over DMA with zero copy. As for features, honestly getting placement new without pointer shenanigans would be nice. C, C++ and Rust all make that (somewhat niche) use case more verbose and obtuse than it strictly has to be.
- rpnx 3y ago
  The main distinction between systems languages (e.g. C, C++, Zig) and non-systems languages is that in a systems language you can interface directly with the OS/hardware or at least a very lightweight runtime. If you need to talk in a language other than what the hardware speaks, you would need a layer inbetween the programmer and the hardware. Systems programming languages are what we use to create abstractions for non-systems languages, in particular runtimes. E.g. Java's JVM is written in C/C++. A defining characteristic of a systems programming language is that 99% of the runtime could be written in said systems programming language (maybe with some assmebly in the last 1% for system calls). That isn't possible in Java for example, you can't have a garbage collector that needs a functional garbage collector to exectute. Systems languages compile directly to machine code, and have enough features that can be used to interface with drivers and hardware. Systems languages have a very close association between what you write and how the computer works under the hood. Deviating from that von neuman model to make it do whatever you want is possible, but then it's no longer a systems programming language.

I'm not sure that that is much related to systems programming, that sounds like a pretty high level library feature.

by rpnx 3y ago

I'm not sure that that is much related to systems programming, that sounds like a pretty high level library feature.

I don't see it like that. I see it as the system having only one interface with all peripherals. Or conversely, all peripherals get treated exactly the same way. Maybe something as simple as: "Are you ready to send me data?" "Send me data" (Some predefined size of data, maybe an 8-bit byte, maybe a 32-bit word, but only one defined size of data.) "Are you ready to receive data?" "Receive this data." That goes down into the bowels of the system, probably at the hardware level. And the architecture of the interface has to be part of the low-level system language otherwise it gets fragmented. But then again, I'm not a systems programmer so what I'm looking for may not be possible.

AlotOfReading 3y ago
There's quite a lot of details that go into something like that and it's often not possible for the code to know all of them. Languages will sometimes abstract similar things out (e.g. have a function call run on some other processor across a network/bus and get the results), but it's quite a high level feature. Systems programmers tend to demand a lot of visibility into what, when and how every line of code executes instead of abstracting that behind the language runtime. For example, a systems programmer might care that the data being received is transferred over DMA with zero copy. As for features, honestly getting placement new without pointer shenanigans would be nice. C, C++ and Rust all make that (somewhat niche) use case more verbose and obtuse than it strictly has to be.
rpnx 3y ago
The main distinction between systems languages (e.g. C, C++, Zig) and non-systems languages is that in a systems language you can interface directly with the OS/hardware or at least a very lightweight runtime. If you need to talk in a language other than what the hardware speaks, you would need a layer inbetween the programmer and the hardware. Systems programming languages are what we use to create abstractions for non-systems languages, in particular runtimes. E.g. Java's JVM is written in C/C++. A defining characteristic of a systems programming language is that 99% of the runtime could be written in said systems programming language (maybe with some assmebly in the last 1% for system calls). That isn't possible in Java for example, you can't have a garbage collector that needs a functional garbage collector to exectute. Systems languages compile directly to machine code, and have enough features that can be used to interface with drivers and hardware. Systems languages have a very close association between what you write and how the computer works under the hood. Deviating from that von neuman model to make it do whatever you want is possible, but then it's no longer a systems programming language.