Virtual Memory let loose...

Greetings all,


This is almost a cross post from the gclist, but I would like to open
this question up to a broader community.


Given that one is in the process of designing a new language and hence
is not stuck with the constraints of the old, how would one
incorporate Virtual Memory.


Even the lowly PC these days comes with multi segmentation and
paging. Yet our only response as software writers is to demand a flat
memory model.


Think what we are throwing away :-


1) Two levels of indirection (segmentation and paging) implemented at
      hardware level and performed every time we access memory.


2) Automatic bounds checking.


3) Automatic read barriers and write barriers.
3.1) Copy-On-Write pages.


Does anyone have experience of such systems? I have used some of these
things on Vax/VMS Vax C, but found that using only library level
support was painful in the extreme. (But then on ye olde Vax 750 most
things were very painful)


Could we make implicit (within the compiler) use and explicit (user
level) use of these features?


Could we make every aggregate type a separate i*86 segment? What would
be the penalty? Would we have to fight the operating system for
control? Garbage collectors become easier, no need to the garbage
collector to fiddle the users pointers after a sweep, just fiddle the
segment descriptors!


Could we allow users to create read/write barriers? Eg. Server creates
a vast empty array. But fills the required elements "just-in-time"
for the client to read it. When memory fills up, pages are just forgotten...


What other fun toys can we create for the user?




John Carter EMail: ece@dwaf-hri.pwv.gov.za
Telephone : 27-12-808-0374x194 Fax:- 27-12-808-0338


[I wrote a pair of articles for Microprocessor Report a few years back
on the topic "Why Programmers Hate the Intel Architecture." There's
two problems with x86 segments. One is performance, loading a segment
register takes about 10 times as long as loading a regular register
due to all of the memory crud the CPU has to fetch, and it's not even
smart enough to notice if you reload the same value that's already
there. The other problem is that segment+offset addresses are an odd
size that the processor doesn't handle easily, to load, store, or
compare them takes multi-instruction sequences. Segments seemed to
work OK back on the GE 635 family because addresses were smaller so a
pointer fit in a word, and the penalty for switching segments wasn't
so bad. On the 386, you can get a very segment-like effect without the
performance penalty by treating the address space as 1K 22-bit segments,
because that matches the way the paging system divides the address space,
but almost nobody seems to do that. -John]


--

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