Re: C and turtles, 80286 protected mode

On 10/15/24 9:08 PM, John Levine wrote:

According to MitchAlsup1 <mitchalsup@aol.com>:

The paragraaph with 3 >'s indicates malloc() cannot be written
in std. C. It used to be written in std. K&R C. I am not asking
if it is still in the std libraries, I am asking what happened
to make it impossible to write malloc() in std. C ?!?

 It's easy enough to write malloc() in standard C if your flavor of the
standard includes a way to ask the operating system for heap space.
Back in the old days it was sbrk().  Now it's mmap(MAP_ANON).

Another possibility might be for the OS/hardware to support
allocate on use. This would be similar to an implicit
mmap(MAP_ANONYMOUS | MAP_FIXED) on a page fault. Obviously, this
would not be portable, but sbrk() and mmap() are not portable.
(unmap() might be supported by memsetting a page as zero. With
hardware support, this information could be communicated to the
OS. Using deduplication to "free" such memory would also be
possible, but that seems relatively expensive.)
Permissions would seem to require some kind of system call. (Separating the address space into execute, read-only, and read-write segments might extend the use cases for such a "simple" allocation interface. JIT compilation seems problematic.)
I am not certain how/if this could handle an allocation failure
(from the OS) other than by catching signals (SIGSEGV?) from the
OS. If malloc() only found a suitably-sized free chunk in the
address space and did not access any of that page (if it is new),
the signal would point to the first load/store instruction to
access the chunk, which sounds more difficult to handle.
This is not terribly dissimilar to the Mill's backless storage
where hardware allocates a free page when a write is performed to
an appropriately marked region (unitialized backless store reads
as zero). (An OS handles underflow and overflow of the hardware
free list with watermarks to avoid actual, stalling underflow and
overflow.)