Xref: utzoo comp.arch:17269 comp.lang.functional:311 comp.lang.lisp:3432 comp.lang.prolog:2969
Path: utzoo!attcan!uunet!ns-mx!iowasp.physics.uiowa.edu!maverick.ksu.ksu.edu!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.arch,comp.lang.functional,comp.lang.lisp,comp.lang.prolog
Subject: Re: GC triggering and stack limit checking by MMU hardware
Summary: EMAS
Keywords: GC, stack, heap, MMU
Message-ID: <3452@goanna.cs.rmit.oz.au>
Date: 22 Jul 90 11:25:04 GMT
References: <1990Jul19.151524.22544@diku.dk> <3265@ecs.soton.ac.uk>
Followup-To: comp.arch
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 12

If my memory serves me correctly, EMAS Prolog (a Prolog interpreter
written in IMP, running under the EMAS operating system on ICL 2900s)
handled Prolog's several stacks by mapping each of them to a scratch
file, leaving unmapped pages in between.  This was _early_ 80s.  The
C Prolog interpreter was derived from EMAS Prolog, and it was going
to use the same scheme just as soon as Berkeley implemented mmap (the
4.1 manuals said it would be in 4.2...).  Isn't the name for this scheme
"red pages"?  

-- 
Science is all about asking the right questions.  | ok@goanna.cs.rmit.oz.au
I'm afraid you just asked one of the wrong ones.  | (quote from Playfair)