trebor@lkbreth.foretune.co.jp (Robert J Woodhead) (04/03/91)
[*** Warning : tongue-in-cheek-detected ***] I've programmed a lot of beasts of both species in my day, down in the computer game trench wars (including implementeding UCSD pascal on 6502's, 8086's, and 6809's -- at one point I had a Japanese MSDOS box that would tell me "Welcome to Apple Pascal" after an appropriate incantation [and a totally useless copy of Apple Pascal to make it legal!]). I'm firmly of the opinion that segments suck bigtime [translation for those with PHd's : "segmented architectures are a solution to a problem that no longer exists, and arguably, never did"] The quintessential segmented architecture of recent days is Intel's 80X86 series. The original 8086 used segments as a quick and dirty way to expand the address space past 16 bits. With segments, you didn't need to have an ALU greater than 16 bits in length; this saved real estate on the chip. Segments also reduced the average length of an instruction, and thus reduced the amount of memory a program took up [and, as we all knew, memory had been expensive, was expensive, and forever would be expensive!] Given that, with a simple translation, it was claimed that 8080 programs would run on the 8086 (not that, to my knowledge, anyone was insane enough to ever try it!), the 8086 could be described, in a vernacular stolen from Data General, as "a chip with a bag on it's side containing an 8080"). This proud Intel tradition of baggy cpu's lives on to this day. Given the current environment of fast, cheap memory, cpu's should worry about reading, writing, and 'rithmetic. "Segmentation," which is really just a special case of virtual memory, should be handled by the memory system and the operating system. Hopefully, after we get through the 80986, Intel will run out of digits and the "segmentation heresy" will be relegated to the dusts of ancient history (which, in our business, is any date older than the oldest unexpired message in your news spool). Unless, of course, they decide to count in hex; in which case, the 80F86 may be proudly inflicted upon the world! -- +--------------------------------------------------------------------------+ | Robert J. Woodhead, Biar Games / AnimEigo, Incs. trebor@foretune.co.jp | | "The Force. It surrounds us; It enfolds us; It gets us dates on Saturday | | Nights." -- Obi Wan Kenobi, Famous Jedi Knight and Party Animal. |
rminnich@super.ORG (Ronald G Minnich) (04/05/91)
In article <9234@lkbreth.foretune.co.jp> trebor@lkbreth.foretune.co.jp (Robert J Woodhead) writes: >I'm firmly of the opinion that segments suck bigtime [translation for >those with PHd's : "segmented architectures are a solution to a problem >that no longer exists, and arguably, never did"] If you don't understand why arguing for or against segmentation as a way of grouping pieces of an address space is UNRELATED to the question of segmented architectures, then you are missing the point. On, e.g, V6 Unix, there were three segments for split I/D processes: stack, data, and code. Do you think this sort of segmentation was a bad idea? Even the most basic Unix systems use segmentation, whether or not the architecture they run on is a segmented architecture. Segments are a way of grouping things. I can't see that going away. ron
trebor@lkbreth.foretune.co.jp (Robert J Woodhead) (04/05/91)
rminnich@super.ORG (Ronald G Minnich) writes: (in response to a msg by me) >Even the most basic Unix systems use segmentation, whether or not >the architecture they run on is a segmented architecture. Segments >are a way of grouping things. I can't see that going away. Ron, the point is not whether segments can be useful -- they can. The point is that quite often they can be a royal pain in the nether regions, and thus, they should not be imposed by the hardware. "Objectionable segmentation" is that imposed by the hardware (eg:INTEL). "Good segmentation" is that imposed by the software (OS) (eg:virtual memory). For example, consider the proposal that was made in a recent message on this topic, for a 32 bit segment and 32 bit address. If that was implemented in the memory system (so that the cpu goes "duhh, here is a 64 bit address, gimme my memory, dude!") then you get the best of both worlds; you can treat your memory as a 64 bit address space, or you can have up to 2**32 segments 2**32 bytes long, or you can have segments >2**32 bytes long that just happen to be set up as 2 or more contiguous segments by the OS. The only restriction is that when a program asks the OS to allocate a new segment, it's gonna get a pointer back that is on an 2**32 bit boundary in the virtual address space. And since it's all virtual memory anyway, that's not a problem. Now, in the real world, we may not get there overnight, because of the obvious tradeoffs that hardware designers make. But for us software people, flat address spaces are "a good thing". And having to work on segmented machines ala INTEL is an exercise in torture. Although there are worse machines; you wouldn't believe the shenanigans the hardware designers inflict on Nintendo- level programmers to save 5 cents per machine in costs -- and I have to design an object oriented system for one of them! Ye gods! -- +--------------------------------------------------------------------------+ | Robert J. Woodhead, Biar Games / AnimEigo, Incs. trebor@foretune.co.jp | | "The Force. It surrounds us; It enfolds us; It gets us dates on Saturday | | Nights." -- Obi Wan Kenobi, Famous Jedi Knight and Party Animal. |
kers@hplb.hpl.hp.com (Chris Dollin) (04/05/91)
Ronald G Minnich writes:
[Quotes Robert Woodhead, then continues]
On, e.g, V6 Unix, there were three segments for split I/D processes:
stack, data, and code. Do you think this sort of segmentation was a bad idea?
If it means I can't construct code at run-time and execute it, yes, I think
this sort of segmentation is a bad idea.
[This doesn't mean that I'm against the idea of segmentation, simply that
segmentation at that coarse a level seems counterproductive. Just Because the
architect doesn't want to dynamically generate code desn't mean that it's a Bad
Thing. The 80-20 rule shouldn't be interpreted as ``make 80% of the jobs easy
at the cost of making the other 20% impossible''.]
--
Regards, Kers 24059 | "You're better off not dreaming of the things to come;
Caravan: | Dreams are always ending far too soon."rminnich@super.ORG (Ronald G Minnich) (04/06/91)
In article <9244@lkbreth.foretune.co.jp> trebor@lkbreth.foretune.co.jp (Robert J Woodhead) writes: >Ron, the point is not whether segments can be useful -- they can. The >point is that quite often they can be a royal pain in the nether regions, >and thus, they should not be imposed by the hardware. >"Objectionable segmentation" is that imposed by the hardware (eg:INTEL). >"Good segmentation" is that imposed by the software (OS) (eg:virtual memory). So we agree. My main objection was to the conclusion that some people are drawing: "I had a bad time with Intel chips therefore segmentation is bad" or "The number line is continuous so segmentation is bad" Sloppy thinking on their part. Fact is, segmentation is a fact of life NOW in our operating systems whether the hardware supports it or not. And maybe the hardware should not. But concluding from limited experience with one processor family that a whole idea is bad strikes me as shortsighted (and I don't mean you). ron
rex@cs.su.oz (Rex Di Bona) (04/08/91)
In article <9244@lkbreth.foretune.co.jp> trebor@lkbreth.foretune.co.jp (Robert J Woodhead) writes: > For example, consider the proposal that was made in a recent message on this > topic, for a 32 bit segment and 32 bit address. If that was implemented in > the memory system (so that the cpu goes "duhh, here is a 64 bit address, > gimme my memory, dude!") then you get the best of both worlds; you can treat > your memory as a 64 bit address space, or you can have up to 2**32 segments > 2**32 bytes long, or you can have segments >2**32 bytes long that just happen > to be set up as 2 or more contiguous segments by the OS. The only problem is what happens when you move your pointer from 0x0000 0000 ffff ffff (spaces for clarity) up by a character? Does it go to 0x0000 0000 0000 0000 or does it go to 0x0000 0001 0000 0000 It is the difference in these two answers that differentiate a 'real' 64 bit flat address space from a truly segmented address space. If I wanted objects greater than 2^32 bytes I would prefer the former. If I was satisfied with smaller objects, but better ways? of handling them I would stay with the latter. I don't know, I still can't see anything (besides backward compatability :-) that segments provide that cannot be provided with flat addressing, and a smarter? virtual to physical translation. -------- Rex di Bona (rex@cs.su.oz.au) Penguin Lust is NOT immoral
trebor@lkbreth.foretune.co.jp (Robert J Woodhead) (04/09/91)
rex@cs.su.oz (Rex Di Bona) writes: >In article <9244@lkbreth.foretune.co.jp> trebor@lkbreth.foretune.co.jp (aka ME) wrote: >> For example, consider the proposal that was made in a recent message on this >> topic, for a 32 bit segment and 32 bit address. If that was implemented in >> the memory system (so that the cpu goes "duhh, here is a 64 bit address, >> gimme my memory, dude!") then you get the best of both worlds; you can treat >> your memory as a 64 bit address space, or you can have up to 2**32 segments >> 2**32 bytes long, or you can have segments >2**32 bytes long that just happen >> to be set up as 2 or more contiguous segments by the OS. >The only problem is what happens when you move your pointer from >0x0000 0000 ffff ffff (spaces for clarity) up by a character? Does it go >to 0x0000 0000 0000 0000 or does it go to 0x0000 0001 0000 0000 It is >the difference in these two answers that differentiate a 'real' 64 bit >flat address space from a truly segmented address space. Most assuredly. If you read my message again, you'll note that the cpu says "duhh, here is a 64 bit address." The cpu doesn't care how the memory system works -- thats the job of the memory hardware and the o/s. Thus, to the cpu you have a flat memory space, and the memory hardware and the o/s can cooperate to provide any attractive architecture they want to. Segmented, flat space, multilevel VM, whatever is required by the particular needs of the system. Now, I'm not a hardware guy -- I have trouble with dimmer switches -- but it has occurred to me for some time that what would be REALLY nice would be a chipset that seperates various processor functions (CPU,FPU,MMU,CACHE...) onto seperate chips (or chips on a carrier) -- and have several flavors of each chip. Then the system designer would be able to design in, and pay for, only those features he or she really wants, and produce a more efficient design. But what do I know -- I write games for a living! ;^) >I don't know, I still can't see anything (besides backward >compatability :-) that segments provide that cannot be provided with >flat addressing, and a smarter? virtual to physical translation. >-------- >Rex di Bona (rex@cs.su.oz.au) >Penguin Lust is NOT immoral -- +--------------------------------------------------------------------------+ | Robert J. Woodhead, Biar Games / AnimEigo, Incs. trebor@foretune.co.jp | | "The Force. It surrounds us; It enfolds us; It gets us dates on Saturday | | Nights." -- Obi Wan Kenobi, Famous Jedi Knight and Party Animal. |
beede@sctc.com (Mike Beede) (04/18/91)
> For example, consider the proposal that was made in a recent message on this > topic, for a 32 bit segment and 32 bit address. If that was implemented in > the memory system (so that the cpu goes "duhh, here is a 64 bit address, > gimme my memory, dude!") then you get the best of both worlds; you can treat > your memory as a 64 bit address space, or you can have up to 2**32 segments > 2**32 bytes long, or you can have segments >2**32 bytes long that just happen > to be set up as 2 or more contiguous segments by the OS. What about two processes that want to share a segment containing in-segment pointers? Would be pretty nice if the segments didn't have to be mapped at the same location for both processes, wouldn't it? Of course, we can just use PL/I BASED types and forget about it . . . . Nah. This seems like a natural kind of thing to do. Mike Beede -- Mike Beede SCTC beede@sctc.com 1210 W. County Rd E, Suite 100 Arden Hills, MN 55112 (612) 482-7420
rod@isi.edu (Rodney Doyle Van Meter III) (04/19/91)
I came in late on this discussion, so forgive me if if this has been mentioned. I don't know what became of it, but in 1984 Jim Kajiya and William Dally of Caltech proposed a segmented architecture with floating point addresses. The exponent determines where in the remaining bits the division between segment number and offset into the segment occurs. The exponent is also considered to be part of the segment number, so an exponent of 1 and segment fraction of 0 is different from an exponent of 2 and a segment fraction of 0. They give as an example MULTICS addressing. MULTICS had 36-bit addresses partitioned as an 18-bit segment number and an 18-bit offset. This is awkward if you want segments bigger than a quarter meg, or if you need more than a quarter million segments. With their architecture, 5 bits out of 36 would be the exponent, indicating how the other 31 bits are partitioned between segment and exponent. This gives the ability to address up to 8 billion segments, and segments can be up to 2 billion words long. This work of theirs was part of a proposed object-oriented machine. They expecet one segment per object. Access between segments will have to be very fast, unlike some other machines. Check out Caltech Technical Report 5168:TR:84 if you're interested. --Rod
peter@ficc.ferranti.com (peter da silva) (04/22/91)
In article <1991Apr18.163123.21963@sctc.com>, beede@sctc.com (Mike Beede) writes: > What about two processes that want to share a segment containing > in-segment pointers? Would be pretty nice if the segments didn't have > to be mapped at the same location for both processes, wouldn't it? Well, it'd be a little more convenient I guess. With all that address space, though, you could do what *I* dream of: put all programs into a common address space. This would speed message-passing, and solve all the problems of pointers in shared memory. You would have to deal with non-contiguous address space within a process, but that's a given in this discussion anyway. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"