Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!bbn!drilex!dricejb From: dricejb@drilex.UUCP (Craig Jackson drilex1) Newsgroups: comp.arch Subject: Re: unconventional architectures Message-ID: <1235@drilex.UUCP> Date: 10 May 89 00:00:38 GMT References: <112@centaure.UUCP> <422@unicads.UUCP> <11579@cgl.ucsf.EDU> <89May6.165030edt.10782@ephemeral.ai.toronto.edu> <1989May6.234007.23517@utzoo.uucp> <89May7.001514edt.39763@neat.ai.toronto.edu> <40284@think.UUCP> Reply-To: dricejb@drilex.UUCP (Craig Jackson drilex1) Organization: DRI/McGraw-Hill, Lexington, MA Lines: 88 In article <40284@think.UUCP> barmar@kulla.think.com.UUCP (Barry Margolin) writes: >In article <89May7.001514edt.39763@neat.ai.toronto.edu> bradb@ai.toronto.edu (Brad Brown) writes: >>In article <1989May6.234007.23517@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >>>In article <89May6.165030edt.10782@ephemeral.ai.toronto.edu> bradb@ai.toronto.edu (Brad Brown) writes: >>>>Unfortunately, a machine like this can't run C very well, 'cause C presupposes >>>>a flat, uniform memory space... >>>Untrue. (Consider all the C compilers for the revolting 8086 and its ugly >>>descendants, which most definitely don't have a flat uniform memory space.) >>But consider how C is implemented on the 8086 and it's brethren: You simulate >>a flat address space and give the programmer a bunch of different memory models It really is true that a segmented machine which uses the segmentation to control access rights (most do) must make some compromises to implement C. Most of these compromises come under the heading of simulating a flat address space. >Multics and Burroughs segments, however, don't get in the way in that >manner, unless you want to have a single object that doesn't fit in a >segment (in the case of Multics, the max size is 1MB). All pointers >include a segment number, there aren't separate segment and offset >registers (i.e. a pointer register can address any location in >memory). Unless a program cares about segments, it can ignore them. > >> The point is that C wants to >>be able to point anywhere in memory, more or less, whereas really segmented >>machines like the Buroughs I was talking about get thier protection ability >>from having a segment for each (more or less) object in the system. Generally true. Wouldn't have to be, though. >Why can't a segmented pointer point anywhere in memory? It can. However, some architectures (such as the Burroughs) place restrictions on how pointers can be manipulated. This is done to prevent illegal pointers from being formed. It is up to the compilers to enforce these restrictions. Illegal pointers cannot be formed because there is nothing stopping them from being used-- the normal address space/protection mechanisms for keeping tasks separated are not there. (At one time, this was considered a Good Idea: put your protection in the compilers, where it only needs to be done per compilation, rather than in the hardware, where it needs to be done on every memory access. See Per Brinch Hansen's books. Nowadays, the universality of C makes this idea impossible and the cleverness of the hardware architects seems to make this idea unnecessary.) (Aside to the real architects of the audience: would it be possible to shave any nanoseconds off the cycle time if it were unnecessary to perform any protection checking on memory references?) >I don't know about Burroughs software, but on Multics we don't assign >a segment to every object. There's a segment for every command or >subroutine library, a stack segment for each ring, and some number of >heap segments for dynamic allocation. In addition, when files are >mapped into the address space (which is the only way to access files) >they are assigned unique segments, and applications may allocate >temporary segments for data rather than allocating out of the heap >segment (this is generally done for performance reasons, as it can >reduce page faults by separating unrelated data). >Barry Margolin >Thinking Machines Corp. Burroughs machines (now called the Unisys A-Series) really do allocate a segment for every object. Segments may vary in size from 6 bytes to 360k bytes. There is a mechanism for doing hidden fixed-size segmentation on very large segments--this is close to paging. However, each segment has its own set of pages and page tables. On these machines, it isn't really meaningful to talk about a virtual address space size-- every new object (array, subroutine code area, etc) is its own address space. C has been announced for the A-Series, for delivery in June-July 1989. It simulates a flat address space. It has four memory models, which allow the programmer to choose the nature of the flat address space simulation. The choice is basically a tradeoff between the size of the simulated address space, and efficiency of access. Note: this compiler has a number of other interesting aspects; I hope to post a description in comp.lang.c when I get around to it (and after I make sure that I'm not violating non-disclosures). -- Craig Jackson {bbn,ll-xn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}