Re: segmented addression, was New assembly language instructions

gneuner2@comcast.net (George Neuner) wrote:


> I spent some quality time in the early 90's hacking the MINIX VMM to
> behave like an experimental segmented 386 OS I had read a paper about
> (I don't recall the name of the paper, if I can find it again I'll
> post an update).


That would be of some interest. Application code, especially
applications that need a lot of memory and manage it in reasonably
sophisticated ways, can have a very different experience.


> Unfortunately I never got the process swapping mechanism to work
> reliably.


This somewhat detracts from the credibility of the idea.


> But the real problem is having to change permissions on the pages (not
> just NX) individually to maintain a secure system when the pages
> toggle between code and data. To be secure, the pages have
> to be R-W-NX when they are data and RO-X when they are code. Changing
> page permissions is a fairly expensive operation in many systems and
> doing it repeatedly page by page vs one update for the segment's whole
> range of addresses can quickly become costly.


So don't change them back and forth, unless you're running out of
memory. Set up a bunch of pages in each style, and use them; if you
run out, allocate some more. That's what I meant by having two
pools. The solution to running out of memory is 64-bit addressing,
which makes application-driven segmentation far less necessary anyway.


> I do think that if there was a way to tell the processor that a
> page will be used both ways that some switching overhead could
> be eliminated.


Well, yes, if you have special hardware for that kind of page.
Otherwise? Seems less plausible.


> I'm guessing that much or all of your experience is with Intel's
> half-assed implementation of 16-bit segments.


Yes. And it will require a lot more than newsgroup postings to change my
mind on the subject.


> A lot of people think back to the 80286 and knock the requirement for
> consecutive virtual addresses, but 32-bit segments are a lot more fun
> to work with. For one thing, unless you go crazy, you don't need to
> change segment registers very often so almost all your pointers are
> just the 32-bit offset - comparable to "flat" mode.


"Go crazy" would involve "using more than 4GB of data"? The code I
work on needs to do that, if customers use if for complex enough
models, and they want to do that. While most of the world of desktop
computing is still wondering what 64-bit is good for, my customers
have been demanding it for years. We first delivered it in 1993, on
the Alpha, and while we still have 32-bit platforms in production for
legacy users, all of our platforms (Windows, Linux, Mac OS X, Solaris,
AIX, and HP-UX) are produced in preferred 64-bit versions. We are
working on dropping the 32-bit builds.


A few years ago, Intel would tweak nicely in response to statements like
"We consider 32-bit addressing a hallmark of legacy technology", but now
they accept it.


Yes, segments would let us address more memory on 32-bit operating
systems. But what are the practical advantages of running a 32-bit OS as
opposed to a 64-bit one? Practically none, unless controlling USB toys
is important to your customers.


> Also using segments effectively expands virtual memory. The 386 and
> 32-bit follow-ons have a total virtual address space of 64TB (that's
> Terabyte with a Tee) ... of course, you have to multiplex it into 4GB
> at a time (or 64GB at a time with PAE). Most 32-bit OSes use a
> degenerate form of this capability to make each application think it
> has the whole 4GB available. They do it just with page table
> manipulation, but by combining deliberate segmentation you can go
> farther.


Yes, I know. Adapting code that uses flat addressing to segments is
quite hard work, and it seems to lack practical advantages in a world
with 64-bit available.


> Segments could have solved some legacy software problems caused by
> short sighted developers ... for example, the well known Windows DLL
> loading problem which can result in multiple private copies of a
> supposedly shared DLL. ... Refitting Windows to use segmentation could
> have provided an immediate (if not simple) fix for the DLL problem. ...
> I _think_ if implemented right, it could have been 99% backward
> compatible while requiring no application or compiler changes. The
> only sticky problems I can think of offhand are callbacks (mentioned
> already) and direct access by the application to DLL data (I don't
> know how often that is done in practice). API controlled data access
> would be no problem.


Direct application access to DLL data is a complete pain, and blocking
it is fine with me. But "no callbacks" is deadly for any kind of
sophisticated API; the idea fails at that point.


> Back when memory was expensive and 64-bits were a dream, something
> like that would have been a godsend. Now it's just a mental exercise.


I'm glad you appreciate that.


--
John Dallman, jgd@cix.co.uk, HTML mail is treated as probable spam.

Return to the comp.compilers page.
Search the comp.compilers archives again.