From 61fb4e886a97971a022d0e180a453428a01ee91e Mon Sep 17 00:00:00 2001 From: Simon Brooke Date: Mon, 2 Jan 2017 23:08:20 +0000 Subject: [PATCH] Updated stack (markdown) --- stack.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/stack.md b/stack.md index 000930e..90fd32b 100644 --- a/stack.md +++ b/stack.md @@ -30,5 +30,7 @@ Past Lisps have implemented stack as lists and as vectors. Both work. My own gue Note that every argument to a Lisp function must be a cons space object passed by reference (i.e., a cons pointer). If the actual argument is actually a [[vector space]] object, then what we pass is a reference to the VECP object which references that vector. -I'm not certain we need a prior frame pointer; if we don't, we may not need a VECP pointing to a stack frame, since nothing can point to a stack frame other than the next stack frame(s) up the stack (if we have a *fork* function, or if we parallelise *map*) which to implement a multi-thread system we essentially must have, there may be two or more successor frames to any frame. +I'm not certain we need a prior frame pointer; if we don't, we may not need a VECP pointing to a stack frame, since nothing can point to a stack frame other than the next stack frame(s) up the stack (if we parallelise *map*, *and* and so on) which to implement a multi-thread system we essentially must have, there may be two or more successor frames to any frame. In fact to use a massively multiprocessor machine efficiently we must normally evaluate each parameter in a separate thread, with only special forms such as *cond* which impose explicit control flow evaluating their clauses serially in a single thread. + +However, modern systems with small numbers of processors and expensive thread construction and tear-down would perform **terribly** if all parameter evaluation was parallelised, so for now we can't do that, even though the semantics must be such that later we can. \ No newline at end of file