Re: 80286 protected mode

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.