3 ms·

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 mad

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

by Y_Y 2y ago

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.