dave@lethe.UUCP (Dave Collier-Brown) (04/12/89)
>In article <1989Apr7.194933.4861@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >>*Real* segments, as on the Multics machines, are part of the normal >>pointer format, and to access something in a segment, you just indirect >>through the pointer. In article <2534@scolex.sco.COM> seanf@scolex.UUCP (Sean Fagan) writes: >I do admit that Intel segments are, um, unpleasant (at least, on the 8086). >On the '286 and '386, they are better, and, in fact, on the '386, they're >quite pleasant (as segments go...). >>One can argue about the merits of breaking the >>linear address space up into segments, but the point is that normal >>pointer manipulation is not penalized in either efficiency or simplicity. > >Neither is it on the '386. Er, its probably better to say that the usual problems of segments are not as visible on the '386. In the long run, any machine which makes a hard limit on segment or address-space size **programmer-visible** will cause hair-tearing and anguish. This is my main remaining complaint with Mutlicks: as of the time I last worked with it, extended objects had not yet managed to make the segment-related maximum size of a file disappear into the noise. One still worked with multi-segment files, waved ones' arms and tried to hide the standard-file -vs- multi-segment-file difference from dummies like me who were trying to write applications. >>The real problem with >32 bit addresses is that avoiding the dreaded >>Intel Pointer Syndrome requires a 64-bit word. Which costs more than >>a lot of people want to pay just now. > >I still maintain that segments are possible a Good Thing, although I don't >like some implementations. Personally, I'd like a systems-programming language translator that manipulated a vector of fixed-size chunks (measured in, say, 2^32 byte page aggregates) as a single named thing, declared fairly conventionally: FILE *fp; where FILE turns into a typedef for something bloody awfull. For a higher-level language, maybe I'd even submit to declare fp pointer(options system); I'd expect that with any finite number of segments one would have to use the Multics tactic of staging segment base-registers in and out of address base-registers (the GE 635/645 had eight, but they had to be used in pairs, giving four intel-like 8086 segment registers). From the architectural point of view, a good mechanism for having a large and varying set of segment base-registers would be nice, and fits reasonably well with register-files in various RISC machines. Lots of subtlety in address formation is nice too: having to do things **the one true brand x way** is not smart. --dave (ok, so maybe even I like risc) c-b -- David Collier-Brown, | {toronto area...}lethe!dave 72 Abitibi Ave., | Joyce C-B: Willowdale, Ontario, | He's so smart he's dumb. CANADA. 223-8968 |