10 Apr
2017
10 Apr
'17
3:14 p.m.
Sean Conner via cctalk wrote on Mon, 10 Apr 2017 17:39:57 -0400
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.
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. 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.
-- Jecel
p.s.: sorry about the word wrapped link in my other post. It should have
been: