Re: Virtual Memory let loose...

pardo@cs.washington.edu (David Keppel)
17 Jan 1997 23:35:19 -0500

          From comp.compilers

Related articles
Virtual Memory let loose... john@dwaf-hri.pwv.gov.za (John Carter) (1997-01-15)
Re: Virtual Memory let loose... s_harris@gsde.hso.link.com (Samuel T. Harris) (1997-01-16)
Re: Virtual Memory let loose... pardo@cs.washington.edu (1997-01-17)
| List of all articles for this month |

From: pardo@cs.washington.edu (David Keppel)
Newsgroups: comp.compilers
Date: 17 Jan 1997 23:35:19 -0500
Organization: Computer Science & Engineering, U of Washington, Seattle
References: 97-01-114
Keywords: storage

John Carter <john@dwaf-hri.pwv.gov.za> wrote:
>[If you were designing a new language, how about keeping segmentation
> and getting two levels of indirection "in hardware" on each memory
> access, plus automatic bounds checking.]


I think it's a good idea to separate the programmer architecture (the
language) from the underlying hardware and then provide an extension
mechanism for hardware access. There are many old languages in use
today and few of them run on machines that look anything like the
machines they ran on when they were new.


I think it's a fine idea to try and take advantage of hardware
features. I think it's a bad idea to build that in to the language.
A while back I spent some time looking at architectures to support
languages like LISP, Smalltalk, etc. and also features like dynamic
linking, segmentation, etc., I looked at quite some machines, for
example the Caltech Object Machine, LISP machines, i432, GE640, old
Burroughs machines, and so on. With few exceptions, the special
hardware is bettered by good software on a commodity processor that
gets faster every year.


Now, you might argue that the x86 is pretty much a given, so we can
presume the existence of the extra segmentation-based addition, etc.
However, you do pay for those features, and Intel is nominally moving
away from the x86 architecture (I forget the name, but the Intel/HP
thing).


So, if you want to design a new language, I'd say provide whatever
features you think are "right". If you like segmentation, do that,
but don't presume the underlying machine will have segmentation.
Instead, presume that you'll develop a back end that makes them run
moderately efficiently -- on the widest varity of fast machines. In
the long run, the machine will evolve "under" you but you'll likely
benefit from those changes.


;-D on ( If my virtual memory serves me correct ) Pardo
[Sort of counter argument: languages die if they can't be implemented
efficiently enough, whatever that means, so the design is always a
compromise between an aesthetic ideal and making it run fast on the
computers on which it's implemented. Furthermore, my two-minute
mental survey of computers being built in the late 1990s suggests that
they all have linear address spaces, 8 bit bytes, paging, and address
spaces large enough that the page table has to have at least two
levels. (Yeah, those 36 bit machines were fun, but they're all dead.)
So it seems to me that expecting VM based segmentation on some address
bit boundary is a pretty safe bet. -John]


--


Post a followup to this message

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