Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!uw-beaver!cornell!batcomputer!itsgw!nysernic!cmx!billo From: billo@cmx.npac.syr.edu (Bill O) Newsgroups: comp.arch Subject: Re: Is the Intel memory model safe from NO-ONE ?!? Message-ID: <491@cmx.npac.syr.edu> Date: 15 May 88 20:48:54 GMT References: <353@cf-cm.UUCP> <3565@okstate.UUCP> Reply-To: billo@cmx.npac.syr.edu (Bill O'Farrell) Organization: Northeast Parallel Architectures Center, Syracuse NY Lines: 87 In article <3565@okstate.UUCP> gregg@a.cs.okstate.edu (Gregg Wonderly) writes: >Instruction stream references are vastly different from those of data, and >for that very reason, I would vote for a variable size segment capability. >To clarify, typically you either need a 'functional unit of a program' or >you don't i.e. you are only executing one procedure at a time, so either >the whole thing should be resident, or none of it (I don't write 4.2Gbyte >functions do you?). Actually, this isn't necessarily true. Example: A main procedure which reads-in and manipulates data, calls a subprogram to do a lengthy computation on the data, then, upon completion of the subprogram, prints some results. In a segmented system, the first and last portions of this main procedure would be in the same segment, and yet the last portion isn't needed until after the completion of some other lengthy computation. In a paged system, the pages that comprise that last portion wouldn't reside in memory until needed. The point of view that Gregg expresses was one of the stated premises for the design of the Burroughs B{5,7}6700, and yet I have never seen any studies (I may have missed them -- please tell me if you know of some) on the effect of (unpaged) procedural segmentation on effective working set size. Working set size is a term usually applied to paged systems, but one could still apply it to systems like the B6700, by studying segment-fault rates vs amount of real memory devoted to code. This could then be compared to the performance of paging in the same context. (hmmm, I wonder what the terms of comparison would be -- maybe I/O rates). Unpaged segmentation may still be a win over paging, I just don't think it can be assumed to be so. >Even for the 64K segment processors, the compiler >can discover how a local branch within a function > 64K should be >handled i.e. is it a NEAR or a FAR branch. Yes, but most linear address space machines also have near and far branches. Near branches allow code to be more compact than would be the case if full-size addresses were used exclusively. In fact, linear address space code may be more compact than code on a "real" segmentation machine (like Multics or the B6700) because when calling procedures in other segments, the latter typically has to provide a segment specifier as well as an offset into the segment. Even the 80(2)86, if I remember correctly, requires a 32 bit pointer for long jumps, even though the machine has a 20 bit address space. Still, code compactness may not be a big issue in segmentation -- it could still be a performance winner overall. > >Data references on the other hand are highly erratic. For this reason, >data memory management should be page oriented so that only the most >necessary portions are present. Because of the typical way that data addresses >are calculated using integer arithmetic, the data address space should be >representable in a single general purpose register. If variable length segments >are used, so that each data entity is contained within a segment, there >should be some paging mechanism provided within the segmentation ... As in Multics... >...to make >unreferenced address space available for allocation to other processes. I think by this you mean "to make the use of real memory more efficient by applying the principle of locality to data references via a paging mechanism". You may have a point there. >Gregg Wonderly >UUCP: {cbosgd, ihnp4, rutgers}!okstate!gregg >Internet: gregg@A.CS.OKSTATE.EDU I am actually a fan of segmentation (if done right, as in Multics) for a lot of reasons, such as dynamic linking, increased security, and the blending of the concepts of "file" and "segment" into a unified whole. One way that Multics has been maligned was the choice of what we now regard (in this age of mega-bit DRAMS) as relatively small limits on segment sizes. I am certain that that problem would have been addressed in the successor to Multics if it hadn't been killed by Honeywell. With gigabyte segment sizes (combined with paging), one would have the choice between a paged, monolithic address and data space, or logical segmentation. And it should be noted that even data space can sometimes benefit from logical segmentation -- consider how data-base record locking might be done with a good segmentation system (one segment per record, maybe?). Would anyone from Honeywell or Burroughs (or former employees familiar with these systems) care to comment on or add to the above? Paul S., are you out there?