[HN Gopher] Spur - RISC IV: The Lisp Multiprocessor Workstation
___________________________________________________________________
Spur - RISC IV: The Lisp Multiprocessor Workstation
Author : oumua_don17
Score : 94 points
Date : 2024-06-18 07:15 UTC (15 hours ago)
(HTM) web link (thechipletter.substack.com)
(TXT) w3m dump (thechipletter.substack.com)
| Y_Y wrote:
| Is there any modern CHERI-type approach to this? I don't know if
| the idea is a dead end or not, but I'd be very interested to see
| a modern processor that is made with something more symbolic and
| lispy than current x86/aarch64 designs which still feel to me
| like they're made for C.
| rbanffy wrote:
| SPARC felt like it was made for C. x86 feels it was made for
| punishing developers.
| smegsicle wrote:
| and c++ was made for punishing silicon a perfect match
| rbanffy wrote:
| Software engineers had their revenge. For now.
| dfox wrote:
| Actually SPARC have four instructions that are directly meant
| for efficient implementation of Lisp/Smalltalk that came from
| SOAR and SPUR. Using that on top of some kind of Unix is
| shall we say problematic (in same way that x86 BOUNDS is
| mostly useless), together with few other "fast conditional
| trap" instructions in SPARC ISA, but it is there.
| thijson wrote:
| Back in the 80's Intel tried to make a CPU designed for high
| level languages.
|
| https://en.wikipedia.org/wiki/Intel_iAPX_432
|
| It was a commercial failure.
|
| The iAPX 432 programming model is a stack machine with no
| visible general-purpose registers. It supports object-oriented
| programming, garbage collection and multitasking as well as
| more conventional memory management directly in hardware and
| microcode. Direct support for various data structures is also
| intended to allow modern operating systems to be implemented
| using far less program code than for ordinary processors.
| sourcepluck wrote:
| "From the perspective of 2024 though, I think that the most
| appropriate reaction is to marvel at the ambition of the UC
| Berkeley team, commercially successful or not, and to be equally
| impressed by how relevant (with the possible exception of LISP)
| the ideas in SPUR would become decades later."
|
| I thought it was pretty widely accepted in the programming
| language community that Lisp has had a massive influence on the
| development of programming languages in general. I know it's not
| the only game in town, as it were, and that there's been lots of
| other interesting developments, but still. To imply that it
| hasn't been "relevant" seems like an uninformed comment to me.
| linguae wrote:
| The influence of Lisp is widely known among PL researchers and
| practitioners (such as compiler writers), but there are many
| people in computing who are unaware of PL research and who have
| little exposure to Lisp except for Emacs users and maybe a few
| exercises in Scheme during college. Thus, the contributions of
| Lisp are constantly rediscovered by those who just come across
| it. Over the decades mainstream programming languages have
| incorporated features from Lisp, and there are still Lisp
| features that haven't made its way into mainstream programming
| languages.
|
| Lisp is by no means the final word on programming languages,
| but its flexibility from its S-expression syntax to macros to
| its metaobject protocol makes it easier to bend the language to
| fit the problem rather than the usual approach of making the
| problem fit the implementation language, and this flexibility
| remains an enduring trait that continues to attract people.
| JonChesterfield wrote:
| Dynamic typing and garbage collection didn't really catch on
| mepian wrote:
| I guess nobody is using Python or Java.
| cmrdporcupine wrote:
| Yeah, and REPLs. Totally not a thing :-)
|
| Remember when it was highly controversial for Java (and then
| C++) to get lambda expressions and many treated us as egg-
| headed academic nerds for wanting those things?
|
| I sure do.
| dfox wrote:
| In java lamdas are just a syntactic sugar for anonymous
| inner classes, with the same resulting limitations, so one
| can either argue that java always had lamdas, but with
| weird verbose syntax, or that java does not really have
| lambdas (in which case C++ and Python also do not have
| lambdas, as the semantics are similar).
| cmrdporcupine wrote:
| Yeah, I moved on from Java before lambdas were
| standardized, so can't comment much but what was painful
| was watching just how bloody long it took to get them
| into the language.
| abecedarius wrote:
| Gosh. Emblematic event: the journal _Lisp and Functional
| Programming_ changed its name to drop Lisp, around early 90s
| iirc. So much of Lisp is super mainstream since before some
| programmers were born, now, that those aspects are no longer
| linked with it. And dynamic typing and GC are fucking
| ubiquitous compared to their status in the 80s.
| aredox wrote:
| Opening up the topic: is there any work, nowadays, on making a
| CPU custom-made for one language, implementing in hardware some
| of its mechanisms? Or at least FPGA implementations?
|
| Apart from CHERI extensions, and a few research papers on
| hardware-accelerated garbage collection (which I find super cool,
| and wonder why it isn't getting into actual production, given
| e.g. how stable Java GC is and how many huge companies use Java.
| Or maybe offloading it to an FPGA? The same way we have GPUs and
| TPUs for certain classes of computation?).
| adrianmsmith wrote:
| I heard (but don't know any details) that Apple M series
| processors have special instructions which are useful for
| objc_msgsend and other functions called frequently by
| Objective-C.
| alexisread wrote:
| Greenarrays comes to mind, it's a Forth-oriented chip:
| https://news.ycombinator.com/item?id=23142322
|
| The article doesn't really mention transputers, which were
| existent at the time and were remarkably similar in vision,
| with parallel multiprocessing, hardware network links, the
| Occam language, a ground-up Helios OS, and custom graphics card
| (Blossom, which would lead to the VGA standard).
|
| Having a 3-element hardware stack somewhat restricts the use of
| languages on it - I imagine that Occam is similar to Forth in
| operation?
| aredox wrote:
| Oh, thanks, I had forgotten about those crazy forthers
| (forthists? forthians?)!
| aeonik wrote:
| Goth -> Gothic
|
| Therefore
|
| Forth -> Forthic
| aeonik wrote:
| Also,
|
| Forthsider, from the Firth of Forth?
| ssrc wrote:
| Occam looks like a concurrent Pascal, not like a Forth. The
| transputer had a 3-element hardware stack but it was used
| more like a cache for the workspace (kind of the memory
| stack). You can still find around the manual "Transputer
| Instruction Set - a compiler writer's guide" that explains
| how you would do that (section 5.3 Expression Evaluation).
|
| Apart from Occam, there where C, C++ and Fortran compilers.
| Targeting the transputer is not more difficult than any other
| stack machine (like the JVM, the .Net CLR, CPython or Pascal
| p-code).
|
| The weird/interesting thing about the transputer is that it
| is also an operating system: two task queues (high/low
| priority), preemptive scheduling and communication through
| channels (that can be one of the 4 serial ports or memory
| based).
| mepian wrote:
| Azul was actually selling servers with hardware-accelerated GC
| and other interesting features for Java:
| https://www.azul.com/newsroom/azul-systems-to-unveil-industr...
| dfox wrote:
| Then they found a way how to (ab)use amd64 MMU to do more or
| less the same thing that they had custom CPU architecture for
| (ie. GC barriers in hardware).
| rbanffy wrote:
| A real shame. When they figured that out, their innovative
| hardware was doomed.
| rjsw wrote:
| There is JOP [1] for Java.
|
| [1] https://www.jopdesign.com/
| llm_trw wrote:
| There are projects for this, but right now Moore's law is still
| shuffling along well enough that by the time you'd get to
| market general processors will still be better, remembering
| that you need on the order of $1b to design a modern CPU.
|
| Once it's truly dead pushing more features into silicon will
| the be only way we can get speedups and this will become a
| major research area again.
| aredox wrote:
| We could argue the same about highly parallel computations,
| yet discrete GPU cards exist. I am also old enough to
| remember the same thing attempted for physics in games,
| PhysX, which had its own cards (PPU) built by ASUS and a
| couple others.
|
| There is also hardware acceleration for many audio and video
| codecs. "GC as a codec" doesn't strike me as something crazy:
| both are upgraded from time to time, but both are stable
| enough that hardware implementations are relevant over
| several years. Android phones would certainly benefit from
| it!
| cmrdporcupine wrote:
| I think "do this matrix math and draw these polygons Really
| Really Fast" is specialized enough that GPUs are on the
| whole compelling as specialized hardware. That and this is
| a massive huge market which can benefit from economies of
| scale and Moore's law itself.
|
| Accelerating a particular language runtime is a different
| story.
|
| TBH people don't seem to have a problem generally with
| "throwing cycles away" and adopting languages like Python
| which have a pretty slow execution story. There's clearly
| not much of an economic advantage in optimization for
| processor throughput, otherwise more stuff would be getting
| [re]written in systems languages like C/C++/Rust/Zig etc,
| which would be a lot cheaper than developing custom
| hardware.
|
| And frankly _most_ of the stuff that gets funding and
| people seem to get excited about in our industry right
| now... doesn 't need much CPU. It's mostly just glue
| languages waiting on I/O. Apart from the ML/LLM hype right
| now, which relies heavily on... GPUs.
|
| I have a book here somewhere on the Linn Rekursiv hardware.
| Custom OO system in hardware in the 80s. Up there with Lisp
| machines as exotic and interesting "paths not taken".
| aredox wrote:
| Thanks, Rekursiv is very interesting, and the Wikipedia
| article gave me the keywords to dig further on the topic
| of "high-level language computer architecture"
| rbanffy wrote:
| I remember someone mentioning an attempt to make all message
| passing in Smalltalk asynchronous running on separate threads,
| but I don't think anyone built a massively multithreaded CPU
| for that (besides, not that many messages are in flight at any
| given time, at least not on a desktop).
| sillywalk wrote:
| They're not mainstream, but IBM's mainframes since Z14 have
| something called the Guarded Storage Facility which provides
| hardware assisted Java Garbage Collection[0], and Oracle's M8
| has some hardware acceleration for Java "Streams"[1].
|
| [0] https://www.ibm.com/support/pages/pause-less-garbage-
| collect...
|
| [1] https://www.oracle.com/a/ocom/docs/sparc-t8-m8-server-
| archit...
| EncomLab wrote:
| I miss those days of deep granular CS projects that strove to
| create the most efficient minimalist systems possible - seems the
| opposite of today's prolific jungles of libraries and linkers.
| Then again I consider Jonathan Blow a prophet in the desert of
| the real...
| llm_trw wrote:
| The emperor has no clothes.
|
| Numpy 2.0 came out two days ago and it's chaos in the whole AI
| ecosystem. I'm not sure how much money we're wasting on that
| but I wouldn't be surprised if it's on the order of a billion
| dollars - suppose there are 50,000 people getting paid on the
| order of $1,000 per day each spending the two week dealing with
| fires over the next year: $500,000,000
| rbanffy wrote:
| Did something major break on 2.0?
| FuriouslyAdrift wrote:
| The made breaking changes in the ABI... not like there
| weren't warnings. "Breaking changes to the NumPy ABI. As a
| result, binaries of packages that use the NumPy C API and
| were built against a NumPy 1.xx release will not work with
| NumPy 2.0. On import, such packages will see an ImportError
| with a message about binary incompatibility.
|
| It is possible to build binaries against NumPy 2.0 that
| will work at runtime with both NumPy 2.0 and 1.x. See NumPy
| 2.0-specific advice for more details."
|
| https://numpy.org/devdocs/dev/depending_on_numpy.html#numpy
| -...
| topspin wrote:
| > The made breaking changes in the ABI...
|
| They bumped the major number. That's fair play. There has
| always been a lot of slouching wrt versions in python.
| That's not numpy's fault. Too bad they're getting the
| black eye for it. They could have avoided it by making a
| new dependency name ("numpy2"), but that sets a shameful
| precedent, so I give them credit for not copping out.
| rikthevik wrote:
| It's a tough situation. Once you have an installed base,
| your hands get tied. I miss the early days when I could
| rework the UI and UX of the product regularly. Now there
| is a lot of legwork to make sure we're not changing
| existing workflows (documented or undocumented). That
| said, I like that we're making money, so I can't complain
| too much.
|
| I viscerally understand how companies can get stuck and
| unable to change their products significantly because
| their installed base will revolt. It's a tough situation.
| topspin wrote:
| It's a self inflicted situation by dependees. Tools in
| widespread use, JupyterLab for instance, has users
| tossing dependencies onto the pile, offering next to no
| guidance on dependency version control, as if expecting
| them to have to ponder such issues is unreasonable.
|
| Well, if that's how you're going to behave, foregoing
| entirely obvious and solved engineering problems, you get
| to glue all the pieces back together when reality asserts
| itself. I don't imagine for one minute numpy folks didn't
| know what this would look like, and they did it anyway.
| Good on them. Breaking changes are necessary. That's
| unqualified. _Necessary._ If you can 't afford a big
| blowup in your work then manage your work.
| rbanffy wrote:
| One of the reasons I made pip-chill was to have a tool to
| make it easy to me to have a minimal set of non-versioned
| requirements for canary builds on the latest-and-greatest
| versions. When the canary breaks, you realise you have
| work to do.
| rbanffy wrote:
| This is a symptom of cruft. Clean breaks are needed to
| keep software fresh.
|
| The Tree of Elegance needs to be refreshed with the blood
| of both users and programers. Or something like that.
| llm_trw wrote:
| Cruft is also known as stability.
|
| We'd not get very far is the Linux Kernel made breaking
| ABI changes every year.
| rjsw wrote:
| I don't think the 'cdr' instruction would have created a new
| list.
| lispm wrote:
| https://www.softwarepreservation.org/projects/LISP/parallel#...
| mncharity wrote:
| FWIW, that[0] links via abstracts to tech report pdfs[1][2][3].
|
| Hmm, looks like https://www.softwarepreservation.org/projects
| hasn't been submitted to HN in some years.
|
| [0] Parallel Lisps / SPUR Lisp
| https://www.softwarepreservation.org/projects/LISP/parallel#...
| [1] SPUR Lisp: Design and Implementation
| https://www2.eecs.berkeley.edu/Pubs/TechRpts/1987/CSD-87-373...
| [2] Features for Multiprocessing in SPUR Lisp
| http://www2.eecs.berkeley.edu/Pubs/TechRpts/1988/CSD-88-406....
| [3] Implementation of Multiprocessing SPUR Lisp
| http://www2.eecs.berkeley.edu/Pubs/TechRpts/1988/CSD-88-459....
| lispm wrote:
| Register Allocation in the SPUR Lisp Compiler:
| https://dl.acm.org/doi/pdf/10.1145/13310.13337
|
| Design Decisions in SPUR: https://pages.cs.wisc.edu/~markhill
| /papers/computer86_spur.p...
|
| SPUR: A VLSI Multiprocessor Workstation: https://www2.eecs.be
| rkeley.edu/Pubs/TechRpts/1986/CSD-86-273...
|
| Multiprocessing extensions in Spur Lisp:
| https://ieeexplore.ieee.org/document/31651
| Someone wrote:
| FTA: _"SPUR was ahead of its time in building a multiprocessor
| system in the mid-1980s. IBM's POWER4 processor from 2001 was the
| first multicore microprocessor, with Intel and AMD each following
| four years later."_
|
| That's comparing apples with oranges. The POWER4 had two cores on
| a single die (https://en.wikipedia.org/wiki/POWER4) while in this
| system (FTA) "a processor would consist of three custom VLSI
| designs and around two hundred other chips"
|
| Multiprocessing systems are much older, for example C.mmp
| (https://dl.acm.org/doi/10.1145/1480083.1480098,
| https://en.wikipedia.org/wiki/C.mmp) from 1971 (possibly also a
| bit of apples and oranges, but if so, IMO less so than in this
| article)
| wiremine wrote:
| I fell through the rabbit hole on this one, and found this post
| with a delightful video from the The Computer Chronicles about
| RISC, circa 1986:
|
| https://www.youtube.com/watch?v=DIccm7H3OA0
|
| I'm so glad we have these sorts of things archived!
___________________________________________________________________
(page generated 2024-06-18 23:01 UTC)