Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: George Neuner <gneuner2@comcast.net>
Newsgroups: comp.arch
Subject: Re: 80286 protected mode
Date: Wed, 16 Oct 2024 23:06:24 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <rhq0hj5h9nfd9qbb64mc8jvaf8bonf61q9@4ax.com>
References: <2024Oct8.092821@mips.complang.tuwien.ac.at> <ve5ek3$2jamt$1@dont-email.me> <be506ccef76d682d13205c69c761a086@www.novabbs.org> <ve6oiq$2pag3$1@dont-email.me> <ve6tv7$2q6d5$1@dont-email.me> <86y12uy8ku.fsf@linuxsc.com> <jwv34kx5afd.fsf-monnier+comp.arch@gnu.org> <3f2cb127c8d5dc2381fc80631a495e3e@www.novabbs.org> <8HBPO.471560$_o_3.464389@fx17.iad> <d8cffb389b3fd055ee70e87da9a3403a@www.novabbs.org> <b6RPO.380391$FzW1.307451@fx14.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Injection-Info: i2pn2.org;
	logging-data="2379762"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="h5eMH71iFfocGZucc+SnA0y5I+72/ecoTCcIjMd3Uww";
User-Agent: ForteAgent/8.00.32.1272
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 4028
Lines: 67

On Wed, 16 Oct 2024 15:38:47 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:

>mitchalsup@aol.com (MitchAlsup1) writes:
>>On Tue, 15 Oct 2024 22:05:56 +0000, Scott Lurndal wrote:
>>
>>> mitchalsup@aol.com (MitchAlsup1) writes:
>>>>On Tue, 15 Oct 2024 21:26:29 +0000, Stefan Monnier wrote:
>>>>
>>>>>> There is an advantage to the C approach of separating out some
>>>>>> facilities and supplying them only in the standard library.
>>>>>
>>>>> It goes a bit further: for a general purpose language, any existing
>>>>> functionality that cannot be written using the language is a sign of
>>>>> a weakness because it shows that despite being "general purpose" it
>>>>> fails to cover this specific "purpose".
>>>>
>>>>One of the key ways C got into the minds of programmers was that
>>>>one could write stuff like printf() in C and NOT needd to have it
>>>>entirely built-into the language.
>>>>
>>>>> In an ideal world, it would be better if we could define `malloc` and
>>>>> `memmove` efficiently in standard C, but at least they can be
>>>>> implemented in non-standard C.
>>>>
>>>>malloc() used to be std. K&R C--what dropped if from the std ??
>>>
>>> It still is part of the ISO C standard.
>>
>>The paragraaph with 3 >'s indicates malloc() cannot be written
>>in std. C. It used to be written in std. K&R C.
>
>K&R may have been 'de facto' standard C, but not 'de jure'.
>
>Unix V6 malloc used the 'brk' system call to allocate space
>for the heap.   Later versions used 'sbrk'.
>
>Those are both kernel system calls.

Yes, but malloc() subdivides an already provided space.  Because that
space can be treated as a single array of char, and comparing pointers
to elements of the same array is legal, the only thing I can see that
prevents writing malloc() in standard C would be the need to somhow
define the array from the /language's/ POV (not the compiler's) prior
to using it.

Which circles back to why something like 

  char (*heap)[ULONG_MAX] = ... ;

would/does not satisfy the language's requirement.  All the compilers
I have ever seen would have been happy with it, but none of them ever
needed something like it anyway.  Conversion to <an integer type> also
would always work, but also was never needed.

I am not a language lawyer - I don't even pretend to understand the
arguments against allowing general pointer comparison.


Aside: I have worked on architectures (DSPs) having disjoint memory
spaces, spaces with differing bit widths, and even spaces where [sans
MMU] the same physical address had multiple logical addresses whose
use depended on the type of access.

I have written allocators and even a GC for such architectures.  Never
had a problem convincing C compilers to compare pointers - the only
issue I ever faced was whether the result actually was meaningful to
the program.