Xref: utzoo comp.lang.c:20792 comp.arch:10999
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!usc!basil.usc.edu!blarson
From: blarson@basil.usc.edu (bob larson)
Newsgroups: comp.lang.c,comp.arch
Subject: Re: Memory Models
Message-ID: <19208@usc.edu>
Date: 16 Aug 89 23:10:07 GMT
References: <5653@ficc.uu.net> <309@hitech.ht.oz> <19158@usc.edu> <1989Aug14.163909.9920@esegue.uucp>
Sender: news@usc.edu
Reply-To: blarson@basil.usc.edu (bob larson)
Followup-To: comp.arch
Organization: USC AIS, Los Angeles
Lines: 64

In article <1989Aug14.163909.9920@esegue.uucp> johnl@esegue.UUCP (John Levine) writes:
>In article <19158@usc.edu> blarson@basil.usc.edu (bob larson) writes:
>>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.  The Prime address space
>is only sort of segmented, because some instructions and address formats pay
>attention to segment boundaries and some don't.

You must have a different definition of segmented than I do.  All
Prime addresses include a segment number and offset, and (with the
excpetion of the new ix mode instructions) no address calcualtion
instruction or addressing mode will carry from the offset to the
segment portion of the address.  (Instructions not designed to
manipulate addresses may of course be used to do so.)

>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.

The C compiler could be taught how to allocate additional memory on
procedure entry if this ever becomes a problem.

>Don't even think about alloca.

It's available from pl1 (called aloc$s) in the standard system
library, and there is a special instruction (stex) just for dynamicly
extending the stack frame.  Why shouldn't I think of it?  (I don't use
alloca because I consider it a bad non-portable hack, but one that
could easily be supported by prime C.)

>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,

The instructions were added to do these operations effeciently, they
are the difference between the i and ix instruciton sets.  C compilers
are available for V and ix instruction sets.

> which of course means that Prime's
>customers whose machines predate the new instructions are unable to run C
>programs.  Great.

The V mode c compiler was written before the ix instruction set was
available, and works reasonably well.  Prime has versions of all
programs they sell except the ix mode C compiler that work on non-ix
prime systems.  They are planning future code that won't work without
the ix mode instrucitons however.  Prime hasn't made a system that
won't support ix mode in 5 years.  Not supporting old systems isn't
something I would fault prime for.

>The '86 architecture, all its innumerable faults notwithstanding, has quite
>consistent memory addressing.

Consistantly bad isn't a virtue in my book.

-- 
Bob Larson	Arpa:	blarson@basil.usc.edu
Uucp: {uunet,cit-vax}!usc!basil!blarson
Prime mailing list:	info-prime-request%ais1@usc.edu
			usc!ais1!info-prime-request