10 Apr
2017
10 Apr
'17
6:43 p.m.
It was thus said that the Great Jecel Assumpcao Jr. via cctalk once stated:
Sean Conner via cctalk wrote on Mon, 10 Apr 2017
17:39:57 -0400
Just because a ton of C code was written with that assumption doesn't make
it actually true. A lot of C code assumes a byte-addressable, two's
compliment architecture but C (technically Standard C) doesn't require
either and goes out of its way to warn programmers *not* to make such
assumptions.
The C Standard is very careful to note what is and isn't allowed with
respect to memory and much of what is done is technically illegal and
anything can happen.
What about C made it difficult for the 432 to
run?
-spc (Curious here, as some aspects of the 432 made their way to the 286
and we all know what happened to that architecture ... )
C expects memory addresses to look like integers and for it to be easy
to convert between the two. If your architecture uses a pair of numbers
or an even more complicated scheme then you won't be able to have a
proper C but only one or more less than satisfactory approximations. The iAPX432 and 286 used logical segments. So there is
no sequence of
increment or decrement operations that will get you from a byte in one
segment to a byte in another segment. For the 8086 that is sometimes
true but can be false if the "segments" (they should really be called
relocation registers instead) overlap.
Given:
p1 = malloc(10);
p2 = malloc(65536);
There is no legal way to increment *or* decrement one to get to the other.
It's not even guarenteed that p2 > p1.
Another feature of C is that it doesn't take types
too seriously when
dealing with pointers. This means that a pointer to an integer array and
a pointer to a function can be mixed up in some ways.
This is an issue, but mostly with K&R C (which had even less type checking
than ANSI C). These days a compiler will warn if you try to pass a function
even with *no* cranking of the warning levels.
Yes, C has issues, but please try not to make ones up for modern C.
But if the point was, back in the day (1982) that this *was* an issue,
then yes, I would agree (to a point). But I would bet that had the 432 been
successful, a C compiler would have been produced for it.
If an application
has been written like that then the best way to run it on an
architectures like these Intel ones is to set all segments to the same
memory region and never change them during execution. This is sometimes
called the "tiny memory model".
https://en.wikipedia.org/wiki/Intel_Memory_Model
Most applications keep function pointers separate from other kinds of
pointers and in this case you can set the code segment to a different
area than the data and stack for a total of 128KB of memory (compared to
just 64KB for the tiny memory model).
The table in the page I indicated shows options that can use even more
memory, but that requires non standard C stuff like "far pointers" and I
don't consider the result to be actually C since you can't move
programer to and from machines like the VAX or 68000 without rewriting
them.
"Far" pointers exist for MS-DOS to support mixed memory-model programming,
where library A wants object larger than 64K while library B doesn't care
either way. Yes it's a mess but that's pragmatism for you.
But there's still code out there with such remnents, like zlib. For
example:
ZEXTERN int ZEXPORT inflateBackInit OF((z_stream FAR *strm, int windowBits,
unsigned char FAR *window));
ZEXTERN, XEXPORT, OF and FAR exist to support different C compilers over the
ages. And of those, XEXTERN and XEXPORT are for Windows, FAR for MS-DOS (see a
pattern here?) and OF for pre-ANSI C compilers.
-spc