Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!sun-barr!apple!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!liuida!isy!lysator.liu.se!bellman From: bellman@lysator.liu.se (Thomas Bellman) Newsgroups: comp.arch Subject: Re: Segmented Architectures ( formerly Re: 48-bit computers) Message-ID: <572@lysator.liu.se> Date: 8 Apr 91 02:40:28 GMT References: <1991Apr04.023845.3501@kithrup.COM> <1991Apr04.230953.15294@kithrup.COM> <1991Apr06.030330.1533@kithrup.COM> Sender: news@isy.liu.se (Lord of the News) Organization: Lysator Computer Club, Linkoping University, Sweden Lines: 60 [ This is a comment on this whole thread, not aimed directly at the articles in the References line. ] This post is intended to make people look at segmentation from a slightly different angle, hopefully calming down this discussion just a little bit. (Not very much hope, though...) Take a typical file system. Say you have a 4 Gbyte disk. You can have 4'294'967'296 files of 1 byte each (modulo such things as directory information, a minimum physical file size due to sector sizes, and other things), or you can have 1 file containing 4 Gbyte data, or anything in between. How do you specify what data you want? Normally, you first open the file you want, receiving a file descriptor from the OS. Then you seek in the file, handing the file descriptor and an offset to the OS. Hmm, doesn't this look familiar? Substitute "create/attach a segment" for "open file" and substitute "index in the segment" for "seek in the file", and you have a segmented memory model. In the file system, you have (say) 8 bits of file descriptor, and 32 bits of offset, but even though you have 40 bits of "pointer", you can't address more than 32 bits. People doesn't seem to have any problem with doing this in a file system, so why the dislike for doing this with the memory too? Now, for memory, you probably want more that 256 segments, and in a modern machine (i e one that hits the market in -93) you might want 64 bit offsets, but the principle remains the same. Sometimes you don't want the segmentation. Sometimes you want the flat address modell. This is equivalent to accessing the physical disk in a file system. The file system it self want to do this, but will probably not want to let the user do that himself. Same for memory, the OS wants to address the memory as a flat space, but might not want the user programs to do this. This post seems to imply that segments are great. But actually, I haven't really made up my mind yet. I can see advantages for both segmented and non-segmented memory. A flat address space is a simple model that is easy to understand and use. I just wanted to point out that on other levels of the computer, people don't object to exactly the same system. There might be some advantages to segments, since they are so popular in the file systems. It's just that they are called files instead of segments. Perhaps the best would be to let the programmer choose for himself. Have two types of instructions for accessing memory -- one type that uses pointers that consists of a segment number and an offset, and one type that has a flat view of the address space, both usable from user mode. Say SEGSTORE and SEGLOAD that takes a segmented address, and FLATSTORE and FLATLOAD that takes a non-segmented address. And then some way of converting between the two types of pointers. Then those that like segments, can take advantage of them, and those that likes a flat address space, can take advantage of that. -- Thomas Bellman, Lysator Computer Club ! "Make Love - Nicht Wahr" Linkoping University, Sweden ! "Too much of a good thing is e-mail: Bellman@Lysator.LiU.Se ! WONDERFUL." -- Mae West