8 ms·

Spur – RISC IV: The Lisp Multiprocessor Workstation

135 points by oumua_don17 2y ago

Y_Y 2y ago
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 2y ago
  SPARC felt like it was made for C. x86 feels it was made for punishing developers.
  - smegsicle 2y ago
    and c++ was made for punishing silicon a perfect match
    - rbanffy 2y ago
      Software engineers had their revenge. For now.
  - dfox 2y ago
    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.
    - skissane 2y ago
      > Actually SPARC have four instructions that are directly meant for efficient implementation of Lisp/Smalltalk that came from SOAR and SPUR. You are talking about the tagged add and subtract instructions, TADDcc/TSUBcc, and their trapping versions TADDccTV/TSUBccTV. > 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. I've never tried using it, but why is it "problematic" on Unix? From what I understand, both on Solaris SPARC and Linux SPARC, the kernel translates the tag-overflow exception into a SIGEMT signal with si_code=EMT_TAGOVF, so you can catch the tag-overflow exception by installing a SIGEMT handler. On Linux SPARC, I think SIGEMT is only used for tag-overflow, whereas on Solaris it also is triggered by CPU performance counter overflow (EMT_CPCOVF) I think TADDccTV/TSUBccTV are problematic in the sense that they are officially deprecated, and only supported for 32-bit overflow, not 64-bit overflow. The docs say to use BPVS instead (so branch on overflow flag instead of trapping an overflow exception) All that said, this all has very fading relevance now, given how moribund SPARC is. Oracle has no plans to introduce any further SPARC CPUs, the SPARC CPUs they currently sell were released 7 years ago, and I expect they'll stop selling them sooner or later. Fujitsu has announced they'll end SPARC server sales in 2029, which is only 5 years away now, and although they were at one point talking about one last CPU after the current M12 generation, I doubt that's still happening.
      - dfox 2y ago
        The inefficiency is about going through kernel that will then dispatch some signal and the signal handler has to analyze what exactly happened, that is not a slow path, but ridiculously slow path. OTOH, my view is somewhat LISP-centric and just implementing + by passing the arguments to taddcctv would be problematic, in the Smalltalk world, implementing SmallInteger>>#+ like that makes sense.
- thijson 2y ago
  Back in the 80's Intel tried to make a CPU designed for high level languages. https://en.wikipedia.org/wiki/Intel_iAPX_432 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 2y ago
"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 2y ago
  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 2y ago
  Dynamic typing and garbage collection didn't really catch on
  - mepian 2y ago
    I guess nobody is using Python or Java.
  - cmrdporcupine 2y ago
    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.
aredox 2y ago
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 2y ago
  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 2y ago
  Greenarrays comes to mind, it's a Forth-oriented chip: https://news.ycombinator.com/item?id=23142322 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 2y ago
    Oh, thanks, I had forgotten about those crazy forthers (forthists? forthians?)!
    - aeonik 2y ago
      Goth -> Gothic Therefore Forth -> Forthic
      - Y_Y 2y ago
EncomLab 2y ago
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 2y ago
  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 2y ago
    Did something major break on 2.0?
    - FuriouslyAdrift 2y ago
      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-2-abi-handling https://numpy.org/devdocs/dev/depending_on_numpy.html#numpy-...
      - topspin 2y ago
        > 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.
rjsw 2y ago
I don't think the 'cdr' instruction would have created a new list.
- kagevf 2y ago
  Correct. (let* ((x '(a b c)) (y (cdr x)) (z (copy-list (cdr x)))) (format t "y=~A, z=~A~%" y z) (setf (nth 1 x) 'w) (format t "y=~A, z=~A~%" y z)) => y=(B C), z=(B C) y=(W C), z=(B C)
  - trealira 2y ago
    Just so you know, modifying quoted lists in Lisp is not dissimilar to setting string literals in C: it's undefined behavior, i.e., it's not guaranteed to work, or be portable if it does work, and it may or may not make your program behave strangely if it does work. To make a mutable list, you could write (list a b c).
    - kagevf 2y ago
      Yes, updating literals is asking for trouble, or at least can lead to some confusion. If I replace ‘(a b c) in my example with (list ‘a ‘b ‘c) I got the same results.
      - trealira 2y ago
        > If I replace ‘(a b c) in my example with (list ‘a ‘b ‘c) I got the same results. Yeah, your core point was right, just thought to let you know about that bit of undefined behavior.
        kagevf 2y ago
        I think you made a worthwhile point. I recall seeing either on IRC or reddit someone asking about why their code wasn't working as expected, and it lead back to needing to understand that the string literal in their code was getting updated - so likely similar to the UB in C that you mentioned. Until seeing that post, I wasn't really aware of that potential issue with literals, so I think it's good to point these things out. Recently, I saw it was mentioned in "Successful Lisp"; it might be mentioned in other books I've read, but maybe I just didn't pick up on it.
lispm 2y ago
https://www.softwarepreservation.org/projects/LISP/parallel#SPUR_Lisp_ https://www.softwarepreservation.org/projects/LISP/parallel#...
- mncharity 2y ago
  FWIW, that[0] links via abstracts to tech report pdfs[1][2][3]. Hmm, looks like https://www.softwarepreservation.org/projects 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#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.pdf 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.pdf 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.pdf http://www2.eecs.berkeley.edu/Pubs/TechRpts/1988/CSD-88-459....
  - lispm 2y ago
    Register Allocation in the SPUR Lisp Compiler: https://dl.acm.org/doi/pdf/10.1145/13310.13337 https://dl.acm.org/doi/pdf/10.1145/13310.13337 Design Decisions in SPUR: https://pages.cs.wisc.edu/~markhill/papers/computer86_spur.pdf https://pages.cs.wisc.edu/~markhill/papers/computer86_spur.p... SPUR: A VLSI Multiprocessor Workstation: https://www2.eecs.berkeley.edu/Pubs/TechRpts/1986/CSD-86-273.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/1986/CSD-86-273... Multiprocessing extensions in Spur Lisp: https://ieeexplore.ieee.org/document/31651 https://ieeexplore.ieee.org/document/31651
Someone 2y ago
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 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://dl.acm.org/doi/10.1145/1480083.1480098, https://en.wikipedia.org/wiki/C.mmp 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 2y ago
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 https://www.youtube.com/watch?v=DIccm7H3OA0 I'm so glad we have these sorts of things archived!
deleted 2y ago
[deleted]

135 points by oumua_don17 2y ago

Y_Y 2y ago

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 2y ago
SPARC felt like it was made for C. x86 feels it was made for punishing developers.
- smegsicle 2y ago
  and c++ was made for punishing silicon a perfect match
  - rbanffy 2y ago
    Software engineers had their revenge. For now.
- dfox 2y ago
  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.
  - skissane 2y ago
    > Actually SPARC have four instructions that are directly meant for efficient implementation of Lisp/Smalltalk that came from SOAR and SPUR. You are talking about the tagged add and subtract instructions, TADDcc/TSUBcc, and their trapping versions TADDccTV/TSUBccTV. > 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. I've never tried using it, but why is it "problematic" on Unix? From what I understand, both on Solaris SPARC and Linux SPARC, the kernel translates the tag-overflow exception into a SIGEMT signal with si_code=EMT_TAGOVF, so you can catch the tag-overflow exception by installing a SIGEMT handler. On Linux SPARC, I think SIGEMT is only used for tag-overflow, whereas on Solaris it also is triggered by CPU performance counter overflow (EMT_CPCOVF) I think TADDccTV/TSUBccTV are problematic in the sense that they are officially deprecated, and only supported for 32-bit overflow, not 64-bit overflow. The docs say to use BPVS instead (so branch on overflow flag instead of trapping an overflow exception) All that said, this all has very fading relevance now, given how moribund SPARC is. Oracle has no plans to introduce any further SPARC CPUs, the SPARC CPUs they currently sell were released 7 years ago, and I expect they'll stop selling them sooner or later. Fujitsu has announced they'll end SPARC server sales in 2029, which is only 5 years away now, and although they were at one point talking about one last CPU after the current M12 generation, I doubt that's still happening.
    - dfox 2y ago
      The inefficiency is about going through kernel that will then dispatch some signal and the signal handler has to analyze what exactly happened, that is not a slow path, but ridiculously slow path. OTOH, my view is somewhat LISP-centric and just implementing + by passing the arguments to taddcctv would be problematic, in the Smalltalk world, implementing SmallInteger>>#+ like that makes sense.
thijson 2y ago
Back in the 80's Intel tried to make a CPU designed for high level languages. https://en.wikipedia.org/wiki/Intel_iAPX_432 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 2y ago

"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 2y ago
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 2y ago
Dynamic typing and garbage collection didn't really catch on
- mepian 2y ago
  I guess nobody is using Python or Java.
- cmrdporcupine 2y ago
  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.

aredox 2y ago

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 2y ago
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 2y ago
Greenarrays comes to mind, it's a Forth-oriented chip: https://news.ycombinator.com/item?id=23142322 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 2y ago
  Oh, thanks, I had forgotten about those crazy forthers (forthists? forthians?)!
  - aeonik 2y ago
    Goth -> Gothic Therefore Forth -> Forthic
    - Y_Y 2y ago

EncomLab 2y ago

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 2y ago
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 2y ago
  Did something major break on 2.0?
  - FuriouslyAdrift 2y ago
    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-2-abi-handling https://numpy.org/devdocs/dev/depending_on_numpy.html#numpy-...
    - topspin 2y ago
      > 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.

rjsw 2y ago

I don't think the 'cdr' instruction would have created a new list.

kagevf 2y ago
Correct. (let* ((x '(a b c)) (y (cdr x)) (z (copy-list (cdr x)))) (format t "y=~A, z=~A~%" y z) (setf (nth 1 x) 'w) (format t "y=~A, z=~A~%" y z)) => y=(B C), z=(B C) y=(W C), z=(B C)
- trealira 2y ago
  Just so you know, modifying quoted lists in Lisp is not dissimilar to setting string literals in C: it's undefined behavior, i.e., it's not guaranteed to work, or be portable if it does work, and it may or may not make your program behave strangely if it does work. To make a mutable list, you could write (list a b c).
  - kagevf 2y ago
    Yes, updating literals is asking for trouble, or at least can lead to some confusion. If I replace ‘(a b c) in my example with (list ‘a ‘b ‘c) I got the same results.
    - trealira 2y ago
      > If I replace ‘(a b c) in my example with (list ‘a ‘b ‘c) I got the same results. Yeah, your core point was right, just thought to let you know about that bit of undefined behavior.
      - kagevf 2y ago
        I think you made a worthwhile point. I recall seeing either on IRC or reddit someone asking about why their code wasn't working as expected, and it lead back to needing to understand that the string literal in their code was getting updated - so likely similar to the UB in C that you mentioned. Until seeing that post, I wasn't really aware of that potential issue with literals, so I think it's good to point these things out. Recently, I saw it was mentioned in "Successful Lisp"; it might be mentioned in other books I've read, but maybe I just didn't pick up on it.

lispm 2y ago

https://www.softwarepreservation.org/projects/LISP/parallel#SPUR_Lisp_ https://www.softwarepreservation.org/projects/LISP/parallel#...

mncharity 2y ago
FWIW, that[0] links via abstracts to tech report pdfs[1][2][3]. Hmm, looks like https://www.softwarepreservation.org/projects 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#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.pdf 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.pdf 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.pdf http://www2.eecs.berkeley.edu/Pubs/TechRpts/1988/CSD-88-459....
- lispm 2y ago
  Register Allocation in the SPUR Lisp Compiler: https://dl.acm.org/doi/pdf/10.1145/13310.13337 https://dl.acm.org/doi/pdf/10.1145/13310.13337 Design Decisions in SPUR: https://pages.cs.wisc.edu/~markhill/papers/computer86_spur.pdf https://pages.cs.wisc.edu/~markhill/papers/computer86_spur.p... SPUR: A VLSI Multiprocessor Workstation: https://www2.eecs.berkeley.edu/Pubs/TechRpts/1986/CSD-86-273.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/1986/CSD-86-273... Multiprocessing extensions in Spur Lisp: https://ieeexplore.ieee.org/document/31651 https://ieeexplore.ieee.org/document/31651

Someone 2y ago

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 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://dl.acm.org/doi/10.1145/1480083.1480098, https://en.wikipedia.org/wiki/C.mmp 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 2y ago

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 https://www.youtube.com/watch?v=DIccm7H3OA0 I'm so glad we have these sorts of things archived!

deleted 2y ago

[deleted]