4 ms·
I wouldn't call that the C memory model, as it's imposed by the OS on all programs.
by vacuity 3y ago
I wouldn't call that the C memory model, as it's imposed by the OS on all programs.
- nedbat 3y agoExcept you can't see that model from (for example) Python, and you don't need to.
- vacuity 3y agoPython presents an abstraction, but underneath, it's bound by the address space just as C is.
- nedbat 3y agoYes, but why do I need to know that as a Python programmer? What mistakes might I make if I don't know about it?
- vacuity 3y agoI was just making it clear that the OS policy pervades. That is, the developers of CPython or another execution context need to care about it, and so it informs some of the implementation details that may leak into programs. We agree that Python presents an abstraction so that Python programmers (usually) don't have to see this.
- deaddodo 3y agoC requires an OS to provide CRT and syscalls for it to function. So you're correct in that the memory model is more akin to "what the OS decides to offer you", with the singular guarantee that specific pieces of data will be contiguous. If you were to write freestanding C code, this certainly changes. At which point the memory model becomes "what you decide to provide".
- yjftsjthsd-h 3y ago> C requires an OS to provide CRT and syscalls for it to function. That doesn't make sense; the OS itself is written in C. > If you were to write freestanding C code, this certainly changes. At which point the memory model becomes "what you decide to provide". Okay, so we're back to, C doesn't impose anything on you, though the OS may.
- vacuity 3y agoThe C memory model is what imposes pointer provenance and all that jazz on C programs. The OS provides an abstraction over physical memory, and programming languages abstract over individual address spaces.
- deaddodo 3y ago> That doesn't make sense; the OS itself is written in C. Please point to a non-userspace memory allocation library/implementation that does not rely on lower level logic to function. > Okay, so we're back to, C doesn't impose anything on you, though the OS may. You're just reversing the original statement. The statement was "you can't assume anything about memory in C" (paraphrasing). They then asked "why not?" The explanation is that: What you think is 'memory' in C isn't, and certainly doesn't map to what most people assume about memory; because C doesn't impose a memory model, it relies on the underlying OS/environment to do so. The only "memory model" is thus: a requested allocation (whether on the stack or heap), if provided to you, will match your request; all other assumptions are invalid. If you want to move goalposts, argue about logical boundaries, etc, have at it. Or if that answer doesn't satisfy you, I don't know what to tell you; but simply rephrasing the original problem does even less.
- jacurtis 3y agoI'm not sure that abstraction is even in the OS. I think its on the memory controller itself. The OS reads from the memory controller.
- yjftsjthsd-h 3y agoI'm pretty sure it's more of a cooperative arrangement; the OS writes the configuration that the MMU uses, thereby imposing its rules on programs.
- vacuity 3y agoThe OS controls the MMU.
- yjftsjthsd-h 3y agoI mean, sure, that's also a valid description. If we're to be precise, at least on x86 the OS sets up a global descriptor table[0] and then uses the LGDT instruction to tell the CPU to use it[1], and LGDT is a privileged instruction so only the OS (kernel) can do that. [0] https://wiki.osdev.org/Global_Descriptor_Table https://wiki.osdev.org/Global_Descriptor_Table [1] https://wiki.osdev.org/GDT_Tutorial#Telling_the_CPU_Where_the_Table_Is https://wiki.osdev.org/GDT_Tutorial#Telling_the_CPU_Where_th...