Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!rex!uflorida!gatech!udel!sbcs!libserv1.ic.sunysb.edu!jallen From: jallen@libserv1.ic.sunysb.edu (Joseph Allen) Newsgroups: comp.arch Subject: Re: Segmented Architectures ( formerly Re: 48-bit computers) Message-ID: <1991Apr7.192433.17198@sbcs.sunysb.edu> Date: 7 Apr 91 19:24:33 GMT References: <1991Apr04.230953.15294@kithrup.COM> <1991Apr6.211320.18594@athena.mit.edu> Sender: usenet@sbcs.sunysb.edu (Usenet poster) Organization: State University of New York at Stony Brook Lines: 61 In article <1991Apr6.211320.18594@athena.mit.edu> jfc@athena.mit.edu (John F Carr) writes: >In article > peter@ficc.ferranti.com (Peter da Silva) writes: >>No, I didn't miss the point. If I have a 48 bit wide VM address and can't >>operate on any object larger than a 32 bit wide pointer can address, then >>it's a problem. >Why do you care what the address size is? A programmer's concern should be: >how many objects can I have, how big can each be, and how fast does the code >run? Let the system designers decide whether to have a flat address space >or segments. If you have code which requires 2^40 byte objects, put this in >your requirements when you buy a system. The cost of 2^40 bytes of memory >can finance the OS and compiler changes needed to support such objects on a >segmented MMU. This closed-system view is something I disagree with very strongly. One of the great things about UNIX is that instead of using the system manufacture's compilers, you have a great range of third party software as well (everything from the WATCOM fortran and C compilers to GNU C). I guess what I'm trying to say is that system programers are programmers too and also shouldn't have to deal with badly implimented segments either. Making your system difficult for 3rd party developers is not a good marketing strategy (even IBM is switching to UNIX these days). I'm not trying to say that UNIX is perfect either. It isn't. But if there's to be a new standard which includes segments, it should be done right. Probably it should be a 64 bit data/address machine with the top 16 bits of the address being the segment number (although this is probably too small for dynamic linking with segments, it would be ideal for huge databases and mapped files). Actually, if you have a flat 64-bit address, it's so huge that you probably don't need segments at all: The paging system would detect lower and upper bound "segment violations". You probably also want to add a mechanism to indicate how full the last page of a segment is (with byte granularity) so that memory mapped files could grow automatically a byte at a time. This is a much more dynamic approach to segmenting- the actual segment size is just whatever the maximum file size is. Plus you wouldn't have to divide the memory map up equally (or in powers of two). Read-only libraries and files wouldn't need space to grow- so they could be loaded adjacently. I guess it comes down to whether you prefer segmented addresses, .EXE library files (I.E., libraries which are relocated when loaded) or address independant code (the 6809 was a truely great uP- OS9 had dynamicly linked libraries without even a memory manager). Note that the last two options are not incompatible with each other and the first option is gross- it may have far pointers but it definately would have to have MK_FP(segment, offset), FP_SEG(addr) and FP_OFF(addr). Sorry about the length of this article. I've decided for myself now: I definately don't want segments. There's too many other easier ways to get the same effect. -- #define h 23 /* Height */ /* jallen@ic.sunysb.edu (129.49.12.74) */ #define w 79 /* Width */ /* Amazing */ int i,r,b[]={-w,w,1,-1},d,a[w*h];m(p){a[p]=2;while(d=(p>2*w?!a[p-w-w]?1:0:0)|( p