From: johnl@iecc.com (John R Levine) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: awful 286 segmentation, was 8086 Segmentation Date: 1 Dec 2000 13:15:55 -0500 Organization: I.E.C.C., Trumansburg NY USA Lines: 31 Message-ID: <908psr$io7$1@xuxa.iecc.com> References: <8v9pbs$meb@netaxs.com> <3A1D838B.467A3BC1@moreira.mv.com> <3A27B1AC.5BD3D413@moreira.mv.com> NNTP-Posting-Host: xuxa.iecc.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!sunqbc.risq.qc.ca!logbridge.uoregon.edu!newsfeed.stanford.edu!xuxa.iecc.com!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:69865 >Segments in the 286 can overlap! Also, whatever value your >"segment" variable has, it can go in the descriptor. The effect >you are describing is actually a safety bonus: while in the 8086 >one can straddle out of a segment boundary, you can't do that in >a 286. The segment base on an 80286 can be placed at any 16-byte >boundary, so you can achieve precisely the same effect you want >in your 8086 by placing the upper 16-bits in the segment base >and using the lower 4 bits as offset. Nope. Remember that the low two bits of a 286 segment descriptor are the RPL, protection info that is always zero in user mode, and the next bit is the TI bit, selecting the global or local segment table. This means that in practice the low three bits of each segment number in a user program have to be zero and segments N, N+1, N+2, and N+3 are all the same segment (assuming N was divisible by 4.) There's no architectural reason why those three bits couldn't have been at the top rather than the bottom of the segment number, in which case it'd have been easy to set up 286 segmentation to mimic real mode paragraphs and permit a gradual migration from real to segmented code. My best guess is that some designer with 432 envy thought "now they'll HAVE to use segments the way we want." The all new bolted on paging in the 386 shows how wrong that idea was. -- John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 387 6869 johnl@iecc.com, Village Trustee and Sewer Commissioner, http://iecc.com/johnl, Member, Provisional board, Coalition Against Unsolicited Commercial E-mail ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: alt.folklore.computers,comp.arch Subject: Re: awful 286 segmentation, was 8086 Segmentation Date: 01 Dec 2000 23:03:16 +0100 Organization: My own Private Self Lines: 68 Message-ID: <6uk89jsst7.fsf@chonsp.franklin.ch> References: <8v9pbs$meb@netaxs.com> <3A1D838B.467A3BC1@moreira.mv.com> <3A27B1AC.5BD3D413@moreira.mv.com> <908psr$io7$1@xuxa.iecc.com> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 975708199 839 10.0.3.2 (1 Dec 2000 22:03:19 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 1 Dec 2000 22:03:19 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch alt.folklore.computers:69914 johnl@iecc.com (John R Levine) writes: > >Segments in the 286 can overlap! Also, whatever value your > >"segment" variable has, it can go in the descriptor. Every segment descriptor can have any 24 bit address in its "base address" field. > >you are describing is actually a safety bonus: while in the 8086 > >one can straddle out of a segment boundary, you can't do that in > >a 286. The segment base on an 80286 can be placed at any 16-byte There are 24 base address bits on the 286, so the base can be set to any byte. The 16byte granularity is only in the 8086/86 (and 80186/188). > >boundary, so you can achieve precisely the same effect you want > >in your 8086 by placing the upper 16-bits in the segment base > >and using the lower 4 bits as offset. > > Nope. Remember that the low two bits of a 286 segment descriptor are > the RPL, protection info that is always zero in user mode, and the > next bit is the TI bit, selecting the global or local segment table. Yes. Emulating real mode in protected mode is not possible. That is why the 286 had real mode support. > There's no architectural reason why those three bits couldn't have > been at the top rather than the bottom of the segment number, But production cost reasons. > in which > case it'd have been easy to set up 286 segmentation to mimic real mode > paragraphs and permit a gradual migration from real to segmented code. No, because with RPL and IT at left, there would have only been 1/8 size memory in this simulated real mode. 128k anyone? Useless for migrating any 8088-outgrowing system to 286. > My best guess is that some designer with 432 envy thought "now they'll > HAVE to use segments the way we want." Bad guess. It was because the GDT and LDT entries are 8 bytes per selector [1]. And as the GDT/LDT are each max 64k (like all other segments), the obvious thing was to make descriptor base address = selector & 0xFFF8. That made the 3 bottom bits free. They were then used for RPL and TI. [1] 16 bits "reserved for 386", 8 bits flags, 24 bits base, 16 bits limit > The all new bolted on paging in > the 386 shows how wrong that idea was. Paging and segmentaton address 2 totally different things: - segmentation does address space extention and in-process memory managment - paging does virtual memory and between-process memory managment. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, Mystic ###### From: Alberto Moreira Newsgroups: alt.folklore.computers,comp.arch Subject: Re: awful 286 segmentation, was 8086 Segmentation Date: Sun, 03 Dec 2000 10:37:12 -0500 Organization: MV Communications, Inc. Lines: 49 Message-ID: <3A2A68A8.88D9BC94@moreira.mv.com> References: <8v9pbs$meb@netaxs.com> <3A1D838B.467A3BC1@moreira.mv.com> <3A27B1AC.5BD3D413@moreira.mv.com> <908psr$io7$1@xuxa.iecc.com> Reply-To: alberto@moreira.mv.com NNTP-Posting-Host: moreira.mv.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: pyrite.mv.net 975857899 18263 207.22.43.212 (3 Dec 2000 15:38:19 GMT) X-Complaints-To: abuse@mv.com NNTP-Posting-Date: 3 Dec 2000 15:38:19 GMT X-Mailer: Mozilla 4.04 [en] (WinNT; U) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.tesion.net!news.belwue.de!news-stu1.dfn.de!news-koe1.dfn.de!news-was.dfn.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.mathworks.com!news.mv.net!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:70030 John R Levine wrote: > Nope. Remember that the low two bits of a 286 segment descriptor are > the RPL, protection info that is always zero in user mode, and the > next bit is the TI bit, selecting the global or local segment table. > This means that in practice the low three bits of each segment number > in a user program have to be zero and segments N, N+1, N+2, and N+3 > are all the same segment (assuming N was divisible by 4.) The lower bits of a selector in a user program must have the right table - GDT or LDT - and the right ring level, or the app's going to get a protection fault. Besides, not every developer writes apps, some of us work at ring 0 too. And you must mean selector, not descriptor. The 80286 segment descriptor is a 64-bit field: it has a 24-bit base, a 16-bit limit, 8 bits worth of control information: 2 bits for the DPL, a present bit, two segment type bits, and three rights bits. An entry in the segment table has 8 bytes, and no, segments N, N+1, N+2 and N+3 aren't the same: the descriptor for segment N is located at offset 8*N in the GDT or LDT: segment 0 goes at offset 0, segment 1 goes at offset 8, and so on. That's why there's only 8K segment descriptors in a 64K table, because each requires descriptor requires 8 bytes. Now, 8K segments require 13 bytes worth of segment number. So, there's three bits available in the selector: one distinguishes between the LDT and the GDT, while the other two give the RPL. Selectors have the same format in the 386, and descriptors are upward compatible. > There's no architectural reason why those three bits couldn't have > been at the top rather than the bottom of the segment number, in which > case it'd have been easy to set up 286 segmentation to mimic real mode > paragraphs and permit a gradual migration from real to segmented code. > My best guess is that some designer with 432 envy thought "now they'll > HAVE to use segments the way we want." The all new bolted on paging in > the 386 shows how wrong that idea was. But you are assuming that it is somehow "good" to mimic real mode, or flat mode. I do not share that opinion. Those three bits can be anywhere, but the nice thing about having them in the lower order positions is, you and the selector with 0xfff8 and you get the descriptor's offset in the GDT or LDT. Remember, the segment number isn't an 8-bit extension to an address! The segment number establishes an address space: up to 64K bytes in an 80286, or 4Gb in an 80386.