Xref: utzoo comp.arch:17234 comp.lang.functional:301 comp.lang.lisp:3421 comp.lang.prolog:2954
Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!samsung!xylogics!world!paradigm!gjc
From: gjc@paradigm.com
Newsgroups: comp.arch,comp.lang.functional,comp.lang.lisp,comp.lang.prolog
Subject: Re: GC triggering and stack limit checking by MMU hardware
Message-ID: <1267@paradigm.com>
Date: 19 Jul 90 20:11:37 GMT
References: <1990Jul19.151524.22544@diku.dk>
Organization: Paradigm Associates Inc, Cambridge MA
Lines: 26

> Most implementations (that I know) of programming languages with
> stacks or heaps, use some kind of explicit check to see when a stack
> or heap is full...
> By using the MMU facilities present in most modern computers, these
> tests can be entirely done in hardware...

The VAX-NIL implementation of lisp, cica 1981, did this. The heap was
easy, but the stack was trickier, requiring a supervisor mode handler
in the case of the MAIN CONTROL stack, (and to be honest, the scheme for 
stack overflow detection was never implemented that way, and instead a
check was made, which only added an instruction to the function call
setup after entry).

But in current processor technology, where you have multi-mip RISC
processors running at many times faster rates than available
memory bandwith you can just initiate the memory operation first,
and then do the bounds check while you are waiting for the memory
operation to complete. The kind of thing you might do in a
microcoded lisp implementation.

More complete MMU implementations that could differentiate between
tagged pointer data references and untagged, and could help keep
track of object volatilities on memory pages would of course really
be a help.

-gjc