Re: New assembly language instructions to support OO languages?

  gneuner2@comcast.net (George Neuner) wrote:


> Using segments+paging in 32-bit mode on the 386 and 486 was fun.


What were you writing?


> 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?


What's wrong with just having a reasonably large pool of executable
memory for JIT code, and GC'ing inside that separately from the main
GC? Yes, two separate pools makes GC less efficient. But the
alternative would seem to be having all data executable.


> 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: it's
surely a problem with where the data is actually stored, and what the
cache and prefetch hardware is doing with it, in the interests of
getting decent throughput.


> AFAIK, no existing processor is able to distinguish "executable data"
> as unique from regular data and code. ISTM that if it could be
> recognized, processors might be able to better streamline some of the
> gyrations that occur when the code is data cached.


Well, tag bits on each word, or maybe byte, of memory should solve the
problem nicely. Good luck with persuading manufacturers to adopt them.


> Of course, a page level XD bit could be implemented (or a multiple bit
> type code),


Err, isn't that what you said was too fine-grained above?


> but I vote for a return to logical segments anyway because
> they are more convenient for programmers ... users don't care.


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.


--
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.