Idk what you're on about, I mmaped a `/dev/uio` from Python this morning. Yeah, I had to add it in a .dts file and rebuild my image, but even slow as shit high level languages like Python let you bang on registers if you really want to.

That worked because you were on an OS that supported it, using a device with simple enough behavior that things like timing or extra/elided writes didn't matter. It's great when that works, but there are very many environments and devices for which that option won't exist.

> That worked because you were on an OS that supported it

I mean... yeah? I'd be surprised if most operating systems didn't have a facility for directly accessing memory mapped devices in some capacity. Even Windows does I think. Have any examples of an OS that doesn't support banging directly on memory?

> using a device with simple enough behavior that things like timing or extra/elided writes didn't matter

Yeah, but that's less of a function of the language like GP was referring to and more a property of using a non-RTOS that doesn't play nice with timing sensitive things from user-space. The language itself is not really the issue there, which was my point.

>I mmaped a `/dev/uio` from Python this morning.

You might want to go and have a look at the implementation of 'mmap' in CPython. Here's a clue: it's in the name 'CPython'.

As it is for an OS written in C, sure it does have some helper C wrappers.

It is still “syscall”s at the end of the day, and many programming languages can output assembly just fine.

There's nothing special about C that makes it possible to use mmap. Just because CPython happens to be implemented in C doesn't mean anything in this context. I could do the same thing in Go or Hare, neither of which have any C in them and be able to do the same thing.

Perhaps, but C and C++ assume flat address spaces and modern hardware includes many programmable devices with their own device memory, e.g. GPUs. Naturally this discontinuity causes a great deal of pain and many schemes have been developed to bridge this gap such as USM (Unified Shared Memory).

Personally I would like to see a native language which attempts to acknowledge and work with disjoint and/or "far away" address spaces. However the daunting complexity of such a feature would likely exclude it from any portable programming language.

Those disjoint memory addresses can be an absolute pain to deal with, ask anyone who had to spend time dragging performance out of the PS3 despite it being faster on paper. UMA/USM can also bring it's own set of issues when you have pathological access patterns that collide with normal system memory utilization.

For what its worth UMA/USM wasn't build to bridge a gap but rather to offer greater flexibility in resource utilization for embedded platforms, that's been moving upstream(along with tiling GPUs) over the years. With UMA you can page in other data on a use-case basis which is why they were relatively popular in phones, if you don't have a bunch of textures loaded on the GPU you can give that space back to other programs. Although come to think of it we used to stream audio data from GPU memory on certain consoles that didn't have large discrete system memory(the bus connecting System <-> GPU memory had some pretty harsh restrictions so you had to limit it to non-bursty, low throughput data which audio/music fit well into).

There is a technical report for C (from the C standards committee) called 'Embedded C' which extends C with 'named address space' storage qualifiers. So you can do 'float _Gpu myarray[1<<14];' As far as I know, nobody uses it.

Rust is making advances here (look at “embedded Rust” efforts). I am curious since I haven’t written kernel code since C went sideways: how easy is it to write a driver that has to manipulate registers with arbitrary behavior at arbitrary addresses with modern C compilers and avoid all undefined behavior? I seem to recall Linus has a rant on this.