tony@wldrdg.UUCP (Tony Andrews) (11/14/86)
> What I hope that this group does not become is a flaming ground for 68K > fanatics to expound the Motorola propaganda, or as the standard cross > posting catagory for comp.sys.ibm.pc. > tomk@intsc.UUCP Tom Kohrs > Regional Architecture Specialist > Intel - Santa Clara Oh perfect. What a nice objective start we've gotten off to. Anyone who doesn't like intel products must be a 68K FANATIC and will tend to spout Motorola PROPAGANDA. My favorite propaganda is the stuff Intel puts out about segmentation. I hated segmentation long before I ever worked with the 68K. I've been doing kernel level work (SVR2 & SVR3) on the 286 for the last year, and I hate it. And that has nothing to do with Motorola. What *I* hope this group does not become is a sales brochure for Intel. Tony Andrews ...!ihnp4!onecom!wldrdg!tony Wildridge Consulting, Inc. Boulder, CO
phil@amdcad.UUCP (Phil Ngai) (11/16/86)
In article <110@wldrdg.UUCP> tony@wldrdg.UUCP (Tony Andrews) writes: >My favorite propaganda is the stuff Intel >puts out about segmentation. > >I hated segmentation long before I ever worked with the 68K. I've been >doing kernel level work (SVR2 & SVR3) on the 286 for the last year, and >I hate it. And that has nothing to do with Motorola. I think your opinions on segmentation are just opinions, and very poorly informed ones at that. Certainly small segments are painful but big enough segments are very useful. After all, if you really love linear addressing so much, just declare a large segment and be done with it. (this assumes segments which can support 32 bit addresses) -- The VT220 keyboard is an <iS<o standard. That means the French can hate it as well as the Americans. <phil <ngai +1 408 749 5720 <u<uC<p: <[ucbvax,decwrl,ihnp4,allegra<]!amdcad!phil AR<pA<; amdcad!phil@decwrl.dec.com
dan@prairie.UUCP (Daniel M. Frank) (11/16/86)
In article <110@wldrdg.UUCP> tony@wldrdg.UUCP (Tony Andrews) writes: >Oh perfect. What a nice objective start we've gotten off to. Anyone >who doesn't like intel products must be a 68K FANATIC and will tend >to spout Motorola PROPAGANDA. My favorite propaganda is the stuff Intel >puts out about segmentation. I think this sort of thing belongs somewhere else. As I understand it, this group isn't here to talk about whether the general architecture of the Intel processor family is good or bad; that can go on endlessly in several other groups. I hope this is going to be a forum for much more detailed technical discussion about the details of the architecture and its development. If it degenerates into religious wars, the technical people (myself included) will quickly unsubscribe. Please don't ruin the newsgroup because you don't like the architecture. -- Dan Frank uucp: ... uwvax!prairie!dan arpa: dan%caseus@spool.wisc.edu
caf@omen.UUCP (Chuck Forsberg WA7KGX) (11/17/86)
In article <13772@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: :In article <110@wldrdg.UUCP> tony@wldrdg.UUCP (Tony Andrews) writes: :>My favorite propaganda is the stuff Intel :>puts out about segmentation. :I think your opinions on segmentation are just opinions, and very :poorly informed ones at that. Certainly small segments are painful but :big enough segments are very useful. After all, if you really love :linear addressing so much, just declare a large segment and be done :with it. (this assumes segments which can support 32 bit addresses) Sure sounds like AMD has made some significant enhancements to the 80286. Please send me two of these miracle chips for my PC-AT's ASAP, I've run out of time trying to get all this neat net.sources software to fit within segments on the Intel 80286 chips in my machines. Also, a compatible 287 chip would be nice. P.S.: What S/W changes are needed to correct the segment size? ... radio! -Mr. Spock
tony@wldrdg.UUCP (Tony Andrews) (11/17/86)
> I think your opinions on segmentation are just opinions, and very > poorly informed ones at that. Certainly small segments are painful but > big enough segments are very useful. After all, if you really love > linear addressing so much, just declare a large segment and be done > with it. (this assumes segments which can support 32 bit addresses) > > <phil <ngai +1 408 749 5720 > <u<uC<p: <[ucbvax,decwrl,ihnp4,allegra<]!amdcad!phil > AR<pA<; amdcad!phil@decwrl.dec.com Okay, so I over-generalized slightly. The 386 is a reasonable chip and will support UNIX quite nicely. But the SVR3 port to the 386 just makes all UNIX processes small model, which is effectively the same address space as a 32032 or 68K. The segmentation isn't really used other than to support 286 binaries. Sure, if you have big enough segments, they can be ignored and everything works nicely. But if they're small enough that I have to support multiple memory models, then forget it. And last year's big segments tend to become this year's small segments. I think that's what happened with the 286. I really didn't want to dredge up this whole war again. Honest. Of course, my opinions are just opinions and so are yours and Intel's. That's not the point. I just couldn't stand such a blatant example of the pot calling the kettle black. Tony Andrews ...!ihnp4!onecom!wldrdg!tony Wildridge Consulting, Inc. Boulder, CO
herman@marlin.UUCP (John W. Herman) (11/17/86)
Expires:11/21/86 Maybe all newsgroups dealing with CPU chips should be moderated to prevent flaming wars.
phil@amdcad.UUCP (Phil Ngai) (11/18/86)
In article <423@omen.UUCP> caf@.UUCP (PUT YOUR NAME HERE) writes: >In article <13772@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >:In article <110@wldrdg.UUCP> tony@wldrdg.UUCP (Tony Andrews) writes: >:>My favorite propaganda is the stuff Intel >:>puts out about segmentation. >:I think your opinions on segmentation are just opinions, and very >:poorly informed ones at that. Certainly small segments are painful but >:big enough segments are very useful. After all, if you really love >:linear addressing so much, just declare a large segment and be done >:with it. (this assumes segments which can support 32 bit addresses) > >Sure sounds like AMD has made some significant enhancements to the >80286. Please send me two of these miracle chips for my PC-AT's ASAP, >I've run out of time trying to get all this neat net.sources software to >fit within segments on the Intel 80286 chips in my machines. Also, a >compatible 287 chip would be nice. > >P.S.: What S/W changes are needed to correct the segment size? You're complaining about 16 bit processors, not segmentation. That's like buying a Honda instead of a truck and then complaining it doesn't carry pianos very well. No, 16 bit processors can't address more than 64Kbytes very well but they weren't intended to. If they were, Intel wouldn't have introduced the 386. Which, by the way, still has segments. But big ones. Large enough for Unix, finally. -- The VT220 keyboard is an <iS<o standard. That means the French can hate it as well as the Americans. <phil <ngai +1 408 749 5720 <u<uC<p: <[ucbvax,decwrl,ihnp4,allegra<]!amdcad!phil AR<pA<; amdcad!phil@decwrl.dec.com
phil@amdcad.UUCP (Phil Ngai) (11/18/86)
In article <111@wldrdg.UUCP> tony@wldrdg.UUCP (Tony Andrews) writes: >Okay, so I over-generalized slightly. The 386 is a reasonable chip >and will support UNIX quite nicely. But the SVR3 port to the 386 >just makes all UNIX processes small model, which is effectively >the same address space as a 32032 or 68K. The segmentation isn't >really used other than to support 286 binaries. I assume when you say small model, you mean things fit in one segment. Really, that's how things should be. Trying to manage objects too big to fit in one segment by using multiple segments is clearly a losing proposition. Now, Intel advertises the 80286 as a 16 bit machine. People who try to use it as a 32 bit machine really shouldn't complain when they find out it doesn't work well. It does sound like SVR3 doesn't use segments for anything useful. I don't think there is any version of Unix which does. But a long time ago, an operating system named Multics did some neat things with segments. That Unix doesn't use them doesn't mean segments are a useless idea. >Of course, my opinions are just opinions and so are yours and Intel's. >That's not the point. I just couldn't stand such a blatant example >of the pot calling the kettle black. Well, I think a lot of so called Intel propaganda has actually been people putting words in Intel's mouth. I've never seen Intel refer to the 80286 as a 32 bit machine. All the flames I have seen have been from people trying to use it as such. Now who's fault is that? -- The distance from the North end of Vietnam to the South end is about the same as the distance from New York to Florida. Phil Ngai +1 408 749 5720 UUCP: {ucbvax,decwrl,hplabs,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.dec.com
mcvoy@rsch.WISC.EDU (Lawrence W. McVoy) (11/20/86)
In article <13801@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >don't think there is any version of Unix which does. But a long time >ago, an operating system named Multics did some neat things with >segments. That Unix doesn't use them doesn't mean segments are a >useless idea. OK, all you intel hackers, here's a question for you. This will tell me very quickly if I want to ever deal with segments or not. By the way, my question could be quickly answered if I had a 386 reference in front of me, but I don't so here goes: Suppose I use your bloody segments. I put the stack in one, the data in another, and the text in another. [ Oops, forgot context, this is the layout for the memory management of Unix process, but could be any OS that multi tasks. ] My questions are 1) How does virtual to physical (page => frame) mapping occur? Are there seperate page tables for each segment, or what? (I know, dumb question). 2) OK, a better question: suppose my process forks (spawns a child) and I would like to set things up as follows: o child gets personal copy of stack. o child gets shared copy of text. o child gets gets shared (with parent) copy of data addresses 0x01ffff..0xffffff (for example). o child gets personal copy of data addresses 0x1ffffff and above. In other words, I want to take the section of memory with virtual addresses 0x01ffff to 0xffffff and have that shared. Can this be __easily__ done with the 386 memory management? Seems like it would be a nice thing to support. Don't forget, there may be valid data addresses both above and below the segment in question; you can't split it into two, have to go to three chunks. 3) And yet another nifty question: can I make the new non-shared data segments be copy-on-write? 4) How about using a segment to catch stack overflow? Dynamically altering segment size? From user mode? Supervisor mode? After or during allocation? Finally, how much is this is handled by software and how much is supported by the hardware (directly). So, waddya say, intel? -- Larry McVoy mcvoy@rsch.wisc.edu, {seismo, topaz, harvard, ihnp4, etc}!uwvax!mcvoy "They're coming soon! Quad-stated guru-gates!"
dricej@drilex.UUCP (Craig Jackson) (11/20/86)
In article <2971@rsch.WISC.EDU> mcvoy@rsch.WISC.EDU (Lawrence W. McVoy) writes: >OK, all you intel hackers, here's a question for you. This will tell >me very quickly if I want to ever deal with segments or not. > >Suppose I use your bloody segments. I put the stack in one, the data >in another, and the text in another. [ Oops, forgot context, this is >the layout for the memory management of Unix process, but could be >any OS that multi tasks. ] My questions are > >1) How does virtual to physical (page => frame) mapping occur? Are there > seperate page tables for each segment, or what? (I know, dumb > question). The memory management is two stage: First you map segmented virtual address to linear virtual address. Then you run through the page tables to change the linear virtual address to a linear real address. The segmentation and the paging are somewhat orthogonal. Normally a segment will begin on a page boundary, but I don't think that's required. (Can't be exactly sure, my 386 manual is right here, either.) >2) OK, a better question: suppose my process forks (spawns a child) > and I would like to set things up as follows: > > o child gets personal copy of stack. > > o child gets shared copy of text. > > o child gets gets shared (with parent) copy of data addresses > 0x01ffff..0xffffff (for example). > > o child gets personal copy of data addresses 0x1ffffff and above. > > In other words, I want to take the section of memory with virtual > addresses 0x01ffff to 0xffffff and have that shared. Can this be > __easily__ done with the 386 memory management? Seems like it > would be a nice thing to support. Don't forget, there may be > valid data addresses both above and below the segment in question; > you can't split it into two, have to go to three chunks. How this is done in a Unix(R) environment isn't completely clear. C doesn't provide simple mechanisms for saying "These variables are in segment N". However, if you can work that, this can be done. (It might be easier in some other languages. I haven't seen any 386 compilers or linkers yet.) The proper way of thinking of this is: o Child gets a personal copy of the stack segment. o Child gets a descriptor pointing to a shared copy of the text segments. o The child gets descriptors pointing to the data segments, with appropriate bits set for copy-on-write on most of them. One of them (call it segment 4) is marked simply to be shared (no copy-on-write). (Here's the big win for segments, BTW. Rather than marking many page table entries, only a few segment table entries needed to be marked.) Once again, how you indicate that this should occur in C is unclear. If the memory region contains static variables, you have to be able to tell C or the linker to put them in segment n. If the memory region is dynamicly allocated, I expect that there will be a system/library call for allocating memory in a new segment. Of course, this would require the availablility of 48-bit pointers. (The same problem occurs in linear-address Unix; you have to be able to indicate which variables are in the specified address range.) Note also that I haven't exactly done what you want--instead of addresses 0x01ffff to 0xffffff, what we are talking about here are addresses 0x0100000000 to 0x01ffffffff. (Or whatever segment number is chosen.) >3) And yet another nifty question: can I make the new non-shared > data segments be copy-on-write? As I said, this is easy, and requires a good deal less work than in a paged machine. (Unfortunately, there's no bit reserved in the segment entry for this, so there will need to be a shadow table. Won't be the first time.) >4) How about using a segment to catch stack overflow? Dynamically altering > segment size? From user mode? Supervisor mode? After or during > allocation? Stacks will normally be expand-downward segments. (Similar to P1 space on a Vax.) A segment-violation interrupt occurs on stack overflow. The interrupt handler runs with its own stack, and can allocate new memory. It can even move the stack in linear-address memory, if need be. This can certainly be done for user stack segments; system stack segments may need to be nailed down (made non-pagable and fixed size). >Finally, how much is this is handled by software and how much is supported >by the hardware (directly). As usual, normal cases and detection of unusual cases are handled in hardware, and handling the unusual cases is done in software. I think that this is really what you'd prefer. >So, waddya say, intel? I hope I've shown that several interesting things can be done with segments (when the segment size is not a problem). I hope that a Unix port is done which allows these things. (I suspect that several Unix ports will be done which use segments in a totally degenerate manner, treating the 386 as a separate I/D, linear address space machine. All of the things you want can be done that way, too, in a conventional Unix manner.) >-- >Larry McVoy mcvoy@rsch.wisc.edu, > {seismo, topaz, harvard, ihnp4, etc}!uwvax!mcvoy P.S. I found my 386 book, so I really do think this is right. -- Craig Jackson UUCP: {harvard!axiom,linus!axiom,ll-xn}!drilex!dricej BIX: cjackson
tony@wldrdg.UUCP (Tony Andrews) (11/20/86)
phil@amdcad.UUCP (Phil Ngai) writes: > It does sound like SVR3 doesn't use segments for anything useful. I > don't think there is any version of Unix which does. But a long time > ago, an operating system named Multics did some neat things with > segments. That Unix doesn't use them doesn't mean segments are a > useless idea. It's hard to do within UNIX. I've thought about the problem a lot. If you take the approach of putting each data structure in its own segment then you wind up doing a lot of segment register loads which are slow. The two new segment registers in the 386 will help alleviate this problem. A couple of days ago I ran a quick benchmark to see how much a small model program would slow down when compiled large model. I used the UNIX "od" command and measured a performance decrease of 35%. I ran the same experiment with "sum" and it slowed down by 50%. In both cases I used an optimizer which eliminates redundant segment loads for a single symbol, but not for different symbols. So this corresponds fairly well to your example of putting each data structure in its own segment. The advantages you discussed may be worth the performance penalty, but there is a penalty. Another problem with making better use of segments in UNIX is that the brk and sbrk primitives don't work out very well. You really need to be able to have a finer level of control over the allocation and deallocation of segments. > Well, I think a lot of so called Intel propaganda has actually been > people putting words in Intel's mouth. I've never seen Intel refer to > the 80286 as a 32 bit machine. All the flames I have seen have been > from people trying to use it as such. Now who's fault is that? Intel representatives (yes, actual employees) have repeatedly stated that the 286 is a good UNIX machine, in comparison to 32-bit processors like the 68K and 32032. (And if you only support small model, and really use it as a 16 bit machine, that's actually true.) This may not be a globally accepted view within Intel, but at least some Intel people have marketed the 286 as a 32-bit machine. Granted, this was all a couple of years ago. I'm sure their strategy has changed now that the 386 is around. Tony Andrews ...!ihnp4!onecom!wldrdg!tony Wildridge Consulting, Inc. Boulder, CO
crowl@rochester.ARPA (Lawrence Crowl) (11/20/86)
In article <2971@rsch.WISC.EDU> mcvoy@rsch.WISC.EDU (Lawrence W. McVoy) writes: >2) OK, a better question: suppose my process forks (spawns a child) ... > In other words, I want to take the section of memory with virtual > addresses 0x01ffff to 0xffffff and have that shared. Can this be > __easily__ done with the 386 memory management? Seems like it > would be a nice thing to support. Don't forget, there may be > valid data addresses both above and below the segment in question; > you can't split it into two, have to go to three chunks. This is a biased question. It askes "how do I use segments to share a portion of my linear address space?" The answer is that with segments you don't share portions of your linear address space, you share collections of data contained entirely within segments. You would place the data you want to share in its own segment and share the segment instead of carefully placing your data at a known location in your linear address space and then sharing those locations. Consider, suppose I want to share addresses 0x10010 through 0x10020, but MUST NOT share 0x10000 through 0x1000F or 0x10021 through 0x20000. How am I going to do this in a paged virtual address space, assuming pages are 1 Kb large. Don't scream "unfair", because it is the same question in a different guise. -- Lawrence Crowl 716-275-5766 University of Rochester crowl@rochester.arpa Computer Science Department ...!{allegra,decvax,seismo}!rochester!crowl Rochester, New York, 14627
kds@mipos3.UUCP (Ken Shoemaker ~) (11/21/86)
In article <2971@rsch.WISC.EDU> mcvoy@rsch.WISC.EDU (Lawrence W. McVoy) writes: >1) How does virtual to physical (page => frame) mapping occur? Are there > seperate page tables for each segment, or what? (I know, dumb > question). No, there isn't a page table for each segment. The segment and offset combine to create a 32-bit "linear address," which is then translated by the paging hardware into a 32-bit physical address. >2) OK, a better question: suppose my process forks (spawns a child) > and I would like to set things up as follows: > > o child gets personal copy of stack. > > o child gets shared copy of text. > > o child gets gets shared (with parent) copy of data addresses > 0x01ffff..0xffffff (for example). > > o child gets personal copy of data addresses 0x1ffffff and above. > > In other words, I want to take the section of memory with virtual > addresses 0x01ffff to 0xffffff and have that shared. Can this be > __easily__ done with the 386 memory management? Seems like it > would be a nice thing to support. Don't forget, there may be > valid data addresses both above and below the segment in question; > you can't split it into two, have to go to three chunks. Maybe I'm dense, but I don't quite see the problem. Aside from having to create a new fork call that can do all you ask. If you look at the 386 as a straight paged machine, which it can easily be, then it isn't any different than any other paged machine. If you look at it as a segmented/paged machine, they you need to rethink your terms. Instead of looking at addresses as offsets in a single linear address space, you'd look at them as segments and offsets into the segments. Instead of sharing address ranges, you'd work sharing segments. If you want to have a non-shared segment spanned by a shared segment in linear space, you can do it, but it doesn't really buy you much except for having two different ways of addressing the same memory location. But then again, if you are working with an eye to segmentation, you aren't working with offsets in a single linear address space, but offsets into multiple segments. >3) And yet another nifty question: can I make the new non-shared > data segments be copy-on-write? sure, just make them read-only, and any attempt to write to the segment will trigger a segmentation fault, and the os will have to copy the contents of the old segment to a new area in linear address space, and point up the segment table to the new segment (to the programmer, the segment number he uses to address the segment will remain the same). >4) How about using a segment to catch stack overflow? Dynamically altering > segment size? From user mode? Supervisor mode? After or during > allocation? sure, why not? Segments are variably sized and these sizes can be changed if a segment fault occurs and the offending instruction restarted. >Finally, how much is this is handled by software and how much is supported >by the hardware (directly). All the memory checks are handled in hardware. What happens when one is detected needs to be handled in software, just like any other addressing fault (e.g., page faults in a normal system). I think part of the problem is that segments are user visible selections of the address space. c doesn't provide the facility to change segments, to put various data structures in different segments, or anything like that. It also likes to be able to address static data structures in the same linear address space as dynamic data structures. It would be a lot easier to work with segmentation if it wasn't something that had to be hidden from the user because the programming language doesn't support it. With the 386 you have the option of not using segmentation because the straight linear address size of the machine is 4 GBytes. But just because it is difficult to use with c doesn't mean that there isn't anything out there that could use it. I could think of "enhancements" to c that would make segmentation programmer visible in the language, and adding os calls to return to the user new segments to play with, but it is something that is very specific to segmented or segmented/paged machines, so you couldn't run it too easily on your vax or sun or whatever, so it probably wouldn't be done. -- The above views are personal. The primary reason innumeracy is so pernicious is the ease with which numbers are invoked to bludgeon the innumerate into dumb acquiescence. - John Allen Paulos Ken Shoemaker, Microprocessor Design, Intel Corp., Santa Clara, California uucp: ...{hplabs|decwrl|amdcad|qantel|pur-ee|scgvaxd|oliveb}!intelca!mipos3!kds csnet/arpanet: kds@mipos3.intel.com
phil@amdcad.UUCP (11/22/86)
In article <113@wldrdg.UUCP> tony@wldrdg.UUCP (Tony Andrews) writes: >Intel representatives (yes, actual employees) have repeatedly stated >that the 286 is a good UNIX machine, in comparison to 32-bit processors >like the 68K and 32032. (And if you only support small model, and really >use it as a 16 bit machine, that's actually true.) Well, it's no worse than a PDP-11. But I'm not going to defend such claims. I have actually heard people at my company say similar things. But they were marketing types, not engineers. With regard to the high cost of reloading segment registers, maybe what is needed is the equivalent of what TLBs do in the paging world. -- The distance from the North end of Vietnam to the South end is about the same as the distance from New York to Florida. Phil Ngai +1 408 749 5720 UUCP: {ucbvax,decwrl,hplabs,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.dec.com
shap@sfsup.UUCP (J.S.Shapiro) (11/25/86)
> OK, all you intel hackers, here's a question for you. This will tell > me very quickly if I want to ever deal with segments or not. > > 1) How does virtual to physical (page => frame) mapping occur? Are there > seperate page tables for each segment, or what? (I know, dumb > question). Right. Dumb question. It does the right thing. > > 2) OK, a better question: suppose my process forks (spawns a child) > and I would like to set things up as follows: > > o child gets personal copy of stack. > > o child gets shared copy of text. > > o child gets gets shared (with parent) copy of data addresses > 0x01ffff..0xffffff (for example). > > o child gets personal copy of data addresses 0x1ffffff and above. > > In other words, I want to take the section of memory with virtual > addresses 0x01ffff to 0xffffff and have that shared. Can this be > __easily__ done with the 386 memory management? Seems like it > would be a nice thing to support. Don't forget, there may be > valid data addresses both above and below the segment in question; > you can't split it into two, have to go to three chunks. All easy, though the sharing naturally has to happen in page-sized increments. > > 3) And yet another nifty question: can I make the new non-shared > data segments be copy-on-write? Yes, write protect the pages and use software to figure out what to do. Straightforward. There is also a user-use bit out there to play with in the PTE. > > 4) How about using a segment to catch stack overflow? Dynamically altering > segment size? From user mode? Supervisor mode? After or during > allocation? There is a stack segment size notion.