[HN Gopher] Multiple register file for Lisp-oriented VLSI chip (...
___________________________________________________________________
Multiple register file for Lisp-oriented VLSI chip (1988)
Author : kazinator
Score : 14 points
Date : 2021-04-01 18:52 UTC (4 hours ago)
(HTM) web link (www.researchgate.net)
(TXT) w3m dump (www.researchgate.net)
| kazinator wrote:
| This paper assumes a classic Lisp dialect with no lexical scope,
| represented by MuLisp, in which parameters are passed by saving
| and restoring variables.
|
| What is worse is that it doesn't even acknowledge the existence
| of lexical scoping in Lisp. There is no statement about why they
| are optimizing dynamic scope using a hardware register file,
| rather than focusing on state-of-the-art lexical scope. Like,
| maybe it is applicable to lexical scoping too. If it is, which is
| likely the case, what a shame not to have remarks about that.
|
| Optimizing dynamically scoped variables with hardware may have
| some intellectual puzzle-solving tidbits in it, whereby a problem
| is stated and some correct solution is derived, but it has no
| practical value. It's a fools errand, like retrofitting a turbo-
| charger onto a gas powered lawn mower, so that it cuts grass
| faster, instead of making more obviously effective changes, such
| as giving it larger blades and turning it into a miniature car
| that can be driven by the operator.
|
| I now regret linking to this.
| kragen wrote:
| I think it's interesting to see a snapshot of how people were
| thinking in 01988 (or 01968), even if there were important
| things they didn't know about, so they weren't really at the
| forefront of their field. I hadn't realized Berkeley RISC[-I]
| was a register-window design like SPARC, for example, which
| adds new meaning to the fact that [Berkeley] RISC-V, led by
| some of the same people and explicitly named after it, _isn
| 't_.
|
| There are things for which dynamic scope is more suitable--
| that's why Common Lisp has special variables, after all. In TeX
| and PostScript it's common to change the current line width,
| the current font, the current color, the current clipping path,
| etc., and then restore it at the end of a scope with a
| grestore. Dynamic scope is the wrong default for local
| variables, of course.
|
| I normally think of register-window architectures as being a
| specific optimization for _lexical_ scoping--they save you from
| having to index each local variable off a frame pointer, or
| save and restore some register you 've allocated to it--
| although they don't help a lot with closures. So, after reading
| your comment, I thought it would be interesting to see how they
| squared that circle. I was looking forward to the intellectual
| puzzle-solving tidbits!
|
| Imagine my surprise to discover that they don't discuss the
| issues of lexical and dynamic scoping at all! There are
| fascinating and subtle tradeoffs involving both usability and
| performance here, but they simply don't touch on them. As far
| as they're concerned, it seems, Lisp functions have access to
| their parameters and temporaries, nothing else.
| rjsw wrote:
| Berkeley RISC[-I,-II, -III (SOAR), -IV (SPUR)] all used
| register windows, and SPUR was specifically designed to run
| Common Lisp. There is a paper [1] on the design of SPUR
| Common Lisp.
|
| [1] https://www2.eecs.berkeley.edu/Pubs/TechRpts/1987/CSD-87-
| 373...
| admax88q wrote:
| > I now regret linking to this.
|
| Best submission statement I've read haha.
| rjsw wrote:
| The paper references SPUR which ran Common Lisp, so they should
| have known about then current work on optimizing lexically
| scoped Lisp.
|
| They could even have looked at retargeting Franz Lisp at a
| register window machine to get some numbers.
___________________________________________________________________
(page generated 2021-04-01 23:02 UTC)