Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!ncar!asuvax!ukma!hsdndev!cmcl2!sbcs!csserv1.ic.sunysb.edu!jallen From: jallen@csserv1.ic.sunysb.edu (Joseph Allen) Newsgroups: comp.arch Subject: Re: Segmented Architectures ( formerly Re: 48-bit computers) Message-ID: <1991Apr5.200219.6451@sbcs.sunysb.edu> Date: 5 Apr 91 20:02:19 GMT References: <23615@as0c.sei.cmu.edu> <4919@lib.tmc.edu> <1991Apr04.234928.8637@iecc.cambridge.ma.us> Sender: usenet@sbcs.sunysb.edu (Usenet poster) Organization: State University of New York at Stony Brook Lines: 28 In article <1991Apr04.234928.8637@iecc.cambridge.ma.us> johnl@iecc.cambridge.ma.us (John R. Levine) writes: >A segmented address space need not be a disaster for large arrays, though >the much reviled Intel implementation is for two reasons: > -- Segment arithmetic is very complicated due to Intel's inexplicable > decision to make the low three bits of the segment number magic. > -- Loading a segment register is so slow on existing implementations (on > a 486, a segment load takes 6 cycles, a regular load takes 1) that > you have to handle intrasegment addresses differently from Though this doesn't have as much to do with large arrays, here's another intel (386) segement gripe: -- The segment bounds register is only 20 bits. This means you're limited to 1MB segments or 4GB segments with 4K pages. This is a big problem when you want to impliment mapped files with intel segemnts: you can't make the file grow a byte at a time (automatically) unless they're less than 1MB. (You could kludge it by switching between 1MB and 4GB modes and by changing the base address- but that's stupid and inefficient). -- #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]=1;while(d=(p>2*w?!a[p-w-w]?1:0:0)|( p