Re: New assembly language instructions to support OO languages?

On Sun, 07 Dec 2008 10:30:46 -0600, jgd@cix.compulink.co.uk wrote:


>
> gneuner2@comcast.net (George Neuner) wrote:
>
>> Using segments+paging in 32-bit mode on the 386 and 486 was fun.
>
>What were you writing?


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). Unfortunately I never got the process swapping
mechanism to work reliably.




>> Page tables suffice for isolating processes, but segmentation allows
>> isolation within processes and (to me) more logical control of access
>> permissions. Page level NX (no execute) is too fine grain - it
>> quickly becomes a PITA when you're implementing any kind of in-memory
>> code generator, e.g., a JIT compiler ... particular in a GC'd system
>> which may relocate the code (temporarily making it data again).
>
>So you want a logical segment which is writable data, and executable
>for JIT code? But you presumably don't want the ordinary data that the
>JIT code is dealing with to be executable, else there's little point
>in having no-execute memory?


NX memory is useful for system security.




>What's wrong with just having ... two separate pools ...


Depends on the implementation - it could be wasteful if you can't
easily adjust the pool size for utilization (e.g., with a 2 level
allocator). 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.




>> Most processors will incur a pipeline stall if the code is also in
>> the data cache and will flush the pipeline if prefetched code is
>> referenced as data again.
>
>Having segments would not appear to help with that problem.


Segments don't solve the problem. That was just a lead-in to my
thoughts about "executable data". 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. As I said previously, I
expect we'll see increasing performance problems going forward
coinciding with increased use of multiple cores, GC and "hotspot"
reoptimizing JIT compilers.




>> but I vote for a return to logical segments anyway because
>> they are more convenient for programmers
>
>No, they aren't more convenient for programmers. They're an utter pain
>IME. They make talking to the OS much more complex, make pointers and
>references far more complex and less portable, and generally add vast
>amounts of friction to the tasks of programming, testing and maintenance.


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


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.


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.




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. It happens because Windows uses relocatable
code rather than position independent code, as in Unix and Linux.


Refitting Windows to use segmentation could have provided an immediate
(if not simple) fix for the DLL problem. On first load, each DLL
would be mapped to a unique segment. No address conflicts - each DLL
starts at a default address just like an application. By limiting
segments to something less than 4GB, the runtime linker/loader could
map DLL entry points to "illegal" trap addresses which it would then
supply to applications. No copies - all applications can share the
DLL code. By treating DLLs as concurrent services (ala Mach), some
kind of kernel-layer RPC and thread context switching could handle
calls into (and maybe also out of) the DLL without either needing to
be aware of explicit segmentation.


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.


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.


George

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