Far and near pointers on the 80286 and later
|
Prev: The 6809 and 680xx instruction sets
Next: DANGER DANGER THIRD DAY CPU FAN FAILURE DANGER DANGER
From: Jonathan de Boyne Pollard on 27 Mar 2010 02:24 > >>>>> >>>>> And segmentation hasn't been used by any production operating >>>>> system on ia32 since the 386; [...] >>>>> >>>> Untrue. It has been used on all of them. In addition to the >>>> obvious requirements at the systems programming level, some of them >>>> permit (or even require!) applications softwares to know of it. >>>> Multithreaded applications programming on 32-bit OS/2 and (x86) >>>> Win32 can involve the explicit use of the FS register by >>>> applications softwares, for example. >>>> >>> They're using FS (and GS) as base registers, not technically as >>> segments, since the storage referred to by FS is also visible via DS >>> and CS (which both flat map the entire 4GB). >>> >> That's a fairly weaselly distinction. "Using segmentation" isn't >> restricted to segments never overlapping or aliasing one another. >> Indeed, that's a common thing that production x86 operating systems >> do with segmentation, from the aforementioned TIB segments in 32-bit >> OS/2 and Win32 to creating data selector aliases for code segments >> via DPMI in DOS-Windows 3.1/9x/ME. >> > Granted, although I'd not call either OS/2 or Win32 running DOS as > modern operating systems. > TIB segments are native 32-bit programming entities. They have nothing at all to do with OS/2 or Windows NT Virtual DOS Machines. They are entities dealt with in ordinary Win32 and 32-bit OS/2 programs. > But fundamentally, in both Windows (NT4+) and Linux, segmentation is > only used insofar as the legacy architecture requires it (e.g. CPL > changes) transitioning from real-mode through protected mode to > paging, then long mode; Were other methods available or if they're > added, segmentation would be relgated to the junk heap of history. > That's the point, though. It has not been so relegated, and it is not the case that it isn't, or even hasn't been, used by production operating systems. As explained, production operating systems use it all of the time, even today, and have done in the past, certainly since the advent of the 80386. "legacy" doesn't mean what you think, by the way.
From: Bill Davidsen on 27 Mar 2010 17:03 George Neuner wrote: > On 22 Mar 2010 23:09:34 GMT, Seebs <usenet-nospam(a)seebs.net> wrote: > >> On 2010-03-22, Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups(a)NTLWorld.COM> wrote: >>> You make the point for me, would you but realize it. Intel was spending >>> its time and effort doing things the "right" way, which is why it took >>> "so long" for x86-64 to become widespread across the board. >> Time from first distribution of x86-64 to at least two major >> vendors shipping parts in large quantities: ??? >> >> Time from first distribution of IA64 to at least two major >> vendors shipping parts in large quantities: ??? >> >> I wouldn't say that x86-64 took long to become widespread, compared with >> IA64. I'm also not at all sure that IA64 counts as doing things the "right" >> way. >> >> So far, the largest impact I've seen from IA64 is that it's increased >> confusion because people keep thinking it means x86-64. >> >>> Untrue. It has been used on all of them. In addition to the obvious >>> requirements at the systems programming level, some of them permit (or >>> even require!) applications softwares to know of it. Multithreaded >>> applications programming on 32-bit OS/2 and (x86) Win32 can involve the >>> explicit use of the FS register by applications softwares, for example. >> I was not aware of any remaining uses of the segmented address space stuff >> in modern BSD or Linux on x86. So far as I can tell, they jump into the >> flat memory model and stay there. > > Most 32-bit x86 OS's defined 2 segments representing user and kernel > mode spaces. This was done because the x86's protection ring traps > were based on the ring bits in the segment selector. > > x86-64 still has protection rings although it only implements rings 0 > and 2 (the others being rarely, if ever, used). Ring traps are now > triggered on a kernel mode bit in the page address. > If anyone ever ports MULTICS to modern CPUs, the rings will all be used again. Actually MULTICS run eight rings, but half were used to run stuff in debug mode, IIRC. That was a *long* time ago. > 32-bit Linux and Windows use the FS register to point to thread > information blocks. FS still works in compatibility mode on x86-64. > In long mode the GS register is used for this purpose although the > segment selector is not checked and the value is simply used as a > pointer. > > George
From: George Neuner on 27 Mar 2010 17:57 On Sat, 27 Mar 2010 17:03:41 -0400, Bill Davidsen <davidsen(a)tmr.com> wrote: >George Neuner wrote: >> On 22 Mar 2010 23:09:34 GMT, Seebs <usenet-nospam(a)seebs.net> wrote: >> >> x86-64 still has protection rings although it only implements rings 0 >> and 2 (the others being rarely, if ever, used). Ring traps are now >> triggered on a kernel mode bit in the page address. ^ should have been a "3" > >If anyone ever ports MULTICS to modern CPUs, the rings will all be used again. >Actually MULTICS run eight rings, but half were used to run stuff in debug mode, >IIRC. That was a *long* time ago. Leaving aside why anyone would _want_ to bring back Multics ... ia32 has only 4 hardware rings. x86-64 in native long mode really has only kernel/user separation and does not implement protection rings as such. I'm not sure it _really_ implements rings even in compatibility mode - I don't know for sure but I suspect the kernel mode trap creates the illusion of rings and that setting the ring bits on any segment to anything other than "3" simply results in all the segments pages being marked as kernel mode. George
From: jmfbahciv on 28 Mar 2010 09:16 George Neuner wrote: > On Sat, 27 Mar 2010 17:03:41 -0400, Bill Davidsen <davidsen(a)tmr.com> > wrote: > >> George Neuner wrote: >>> On 22 Mar 2010 23:09:34 GMT, Seebs <usenet-nospam(a)seebs.net> wrote: >>> >>> x86-64 still has protection rings although it only implements rings 0 >>> and 2 (the others being rarely, if ever, used). Ring traps are now >>> triggered on a kernel mode bit in the page address. > > ^ should have been a "3" > >> If anyone ever ports MULTICS to modern CPUs, the rings will all be used again. >> Actually MULTICS run eight rings, but half were used to run stuff in debug mode, >> IIRC. That was a *long* time ago. > > Leaving aside why anyone would _want_ to bring back Multics ... To study how to make an OS secure from the beginning project plan to the last edit for shipping? <snip> /BAH
From: George Neuner on 30 Mar 2010 00:59
On Sun, 28 Mar 2010 08:16:02 -0500, jmfbahciv <jmfbahciv(a)aol> wrote: >George Neuner wrote: > >> Leaving aside why anyone would _want_ to bring back Multics ... > >To study how to make an OS secure from the beginning project plan >to the last edit for shipping? Ok, but there are other secure systems to study such as Amoeba and EROS. They are more modern than Multics, and in particular, were designed to be distributed. I don't mind anyone studying Multic - there is plenty to learn from it (including what not to do) ... but I would be against trying to revive it as a working operating system. George |