But you can't implement peek and poke without asm then. The great advancement of mmio was that you *can* write code driving memory-mapped devices purely in C (or C++) without needing hideous inb/outb/inw/outw/etc. asm.
-
-
peek and poke are library functions or just use asm. I've written a ton of microcontroller code and there is zero sense in pretending that code accessing memory-mapping i/o is portable
1 reply 0 retweets 4 likes -
Except all the modern mmio drivers in Linux *just work* on all archs, even ones they were never designed for. Essentially, they *are* portable. This was not the case with old io-insn stuff.
2 replies 0 retweets 1 like -
Replying to @RichFelker @johnregehr and
Yes you could achieve the same with peek and poke functions for each bus access size, but unless they were part of the stdlib you'd have all sorts of gratuitous portability problems from ppl implementing their own just for arm and x86.
1 reply 0 retweets 0 likes -
maybe we should quibble about a specific piece of code-- do you have one in mind? my guess is that the implementation style is already pretty close to what I want. all I'm really talking about is replacing x = 1 where x is volatile with poke(x, 1).
3 replies 0 retweets 2 likes -
If we were designing the language from scratch today, no objection at all. OTOH if the request is "remove volatile [and force everyone to replace it with non-portable hacks]" I have a big problem with that.
1 reply 0 retweets 0 likes -
yes to eventually forcing everyone to move away from volatile, but that would be a long time from now. no to non-portable hacks -- the volatile replacement would be precisely as portable as the current code, just with explicit loads/stores instead of implicit ones.
2 replies 0 retweets 1 like -
Replying to @johnregehr @RichFelker and
As formerly pointed, today peek and poke can be implemented in C due to volatile, and final user can have their peek and poke API. Removing volatile equates to obligatory peek and poke APIs + no C implementation.
1 reply 0 retweets 1 like -
-
Replying to @johnregehr @pepper_chico and
The whole model of MMIO makes no sense without volatile types. Hypothetical peek/poke functions would have no reason to take pointer arguments you couldn't validly dereference anyway. They would take some sort of integer address arguments...
1 reply 0 retweets 0 likes
And then they don't even look memory-mapped anymore.
-
-
Replying to @RichFelker @johnregehr and
Indeed. Personally, obligating asm implementation by removing a feature of a language whose main purpose was to replace asm is not right for me.
0 replies 0 retweets 1 likeThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.