Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Paul A. Clayton" <paaronclayton@gmail.com>
Newsgroups: comp.arch
Subject: Re: C and turtles, 80286 protected mode
Date: Wed, 16 Oct 2024 15:07:14 -0400
Organization: A noiseless patient Spider
Lines: 41
Message-ID: <vep2t7$2c62t$1@dont-email.me>
References: <2024Oct6.150415@mips.complang.tuwien.ac.at>
 <3f2cb127c8d5dc2381fc80631a495e3e@www.novabbs.org>
 <8HBPO.471560$_o_3.464389@fx17.iad>
 <d8cffb389b3fd055ee70e87da9a3403a@www.novabbs.org>
 <ven3mo$11b4$1@gal.iecc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 16 Oct 2024 21:07:20 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0085cf96d908ff9def3e765ffce47f4c";
	logging-data="2496605"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18Y2vRwOHsqRSpYalRn1a24qCtI4KIn5+k="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.0
Cancel-Lock: sha1:AQ8pFlPymX3FJw9VeYH7jgSpIsg=
In-Reply-To: <ven3mo$11b4$1@gal.iecc.com>
Bytes: 3289

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.)