Multiple register file for Lisp-oriented VLSI chip (1988) | Hacker News Reader

Multiple register file for Lisp-oriented VLSI chip (1988)

researchgate.net

17 pointskazinator6 comments

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.

> I now regret linking to this.

Best submission statement I've read haha.

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.

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.

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...

Thank you!

Reply on news.ycombinator.com