Memory Models

[John Levine]

In article <19158 at usc.edu> blarson at basil.usc.edu (bob larson) writes:
>In article <309 at hitech.ht.oz> clyde at hitech.ht.oz (Clyde Smith-Stubbs) writes:
>>From article <5653 at ficc.uu.net>, by peter at ficc.uu.net (Peter da Silva):
>>>> [near and far pointers are] not a C language issue.  It's kludgery
>>>> introduced specifically in the IBM PC environment.

>>It IS a language issue - you could argue that near and far address spaces
>>are not part of the Standard C, therefore it is not a C issue, however
>>there are sufficient architectures that REQUIRE a useful language  to

>Just because your address space is segmented dosn't mean you have to
>kludge your language around.  Prime C does quite nicely without memory
>models.  ...

I am probably one of the few people in the world to have had the dubious
pleasure of writing an assembler for the Prime, intended to be the back end
for a C compiler that never saw the light of day.  The Prime address space
is only sort of segmented, because some instructions and address formats pay
attention to segment boundaries and some don't.  The C compiler wherever
possible uses the latter set, so the segmentation is more or less invisible
at the architecture level.  (Well, not quite, the address mode you have to
use to get to the stack is segmented, so the stack frame for any single
procedure is limited to slightly under one segment.  Don't even think about
alloca.)

I also note that since the word-addressed Prime was unable to reference
characters in a reasonable way they added some new instructions specifically
for the benefit of the C compiler that load characters, store characters,
and increment character pointers, which of course means that Prime's
customers whose machines predate the new instructions are unable to run C
programs.  Great.

The '86 architecture, all its innumerable faults notwithstanding, has quite
consistent memory addressing.  The segments are really there, and from other
extensive experience (I did most of the Prime assembler in Turbo C at home!)
I can testify that large model C code is much larger and slower than small
model, so you really need to have some sort of address space hackery to
write useful programs.  Sad, but true.

What I would really like to see is a data declaration language that lets you
take advantage of segments rather than just tolerating them, e.g. group
useful data into segments, map structures into segments in interesting ways,
pass segment handles around.  Never seen one.  Even Multics PL/I just
kludged it.
-- 
John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 492 3869
{ima|lotus}!esegue!johnl, johnl at ima.isc.com, Levine at YALE.something
Massachusetts has 64 licensed drivers who are over 100 years old.  -The Globe