Re: Computer architects leaving Intel...

On Thu, 12 Sep 2024 08:15:29 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

Michael S <already5chosen@yahoo.com> writes:
 

On Wed, 11 Sep 2024 17:34:38 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
 

Michael S <already5chosen@yahoo.com> writes:
 

>
Real mode x86 C compilers operating in Large and Compact Models
that were popular on IBM-compatible PCs 30-40 years ago could
have more than one representation for the pointer to the same
memory location.  If my memory serves me, the rules of pointers
comparison for equality were the same as rules of comparison for
<>.  In both cases for reliable result pointers had to be
explicitly normalized (i.e. converted from 'far' to 'huge' or
something like that).
>
It was long time ago and even back then I didn't use Large model
very often, so it's possible that I misremember.  But if I
remember correctly, does it mean that those C compilers now would
be considered non-compliant? 

>
The C standard was first ratified (by ANSI) in 1989.  The rules
for pointer comparison were clarified in the C99 standard, but it
has always been true that pointers to the same object have to
compare equal.
>
C environments that have things like 'far' or 'huge' pointers,
etc, are not standard C but must have extensions so that they can
deal with the different kinds of pointers.  Depending on how the
non-standard kinds of pointer worked, the implementation might or
might not be conforming.  Most likely though it's a moot point
because once a program starts using an extension all the rules
can change, and the C standard allows that.  It's only programs
that look like really standard C that have to do what the C
standard says (for the implementation to be conforming);  any
code that declares a 'far' pointer or 'huge' pointer certainly
isn't standard C. 

>
In Compact and Large models data pointers are 'far' by default.  So,
the source doesn't have to use non-standard declarations. 

 
In that case, if the defaulted 'far' pointers don't follow the
rules given in the C standard for regular pointers, then the
implementation is not conforming.  Extensions are allowed only if
they don't change the behavior of any strictly conforming
program.  If undecorated pointer declarations don't observe this
condition then it's not a valid extension, which in turn causes
the implementation to be non-conforming.

Thinking about it, there likely were no way to create aliases via using
only standard language constructs. That's assuming that any use of
preserved values of pointers to de-allocated heap storage, including
use for comparison, is non-standard.
So it probably was conforming implementation at the end.