6 ms·

What’s most interesting to me about the i432 is the rich array of object types essentially embedded into its ISA. The JVM “knows” a little bit about virtual dis

What’s most interesting to me about the i432 is the rich array of object types essentially embedded into its ISA. The JVM “knows” a little bit about virtual dispatch tables, monitors, arrays, but even that pales in comparison to the i432’s user-facing model of the CPU state. Is there anything comparable surviving today?

yourapostasy 4y ago
> Is there anything comparable surviving today? I'm not aware of such Super CISC instruction sets in popular use today, but I wonder with VM's and statistically-based AI proliferating now, whether we might revisit such architectures in the future. Could continuous VM-collected statistical data inform compiler and JIT compiler design to collapse expensive, common complex operations we can't identify patterns for with current methods into Super CISC instructions that substantially speed up patterns we didn't know previously existed, or are our current methods to analyze and implement compilers and JIT's good enough and what's mostly holding them back these days are other factors like memory and cache access speed and pipeline stalls?
gumby 4y ago
I don’t think so, except at the margins. I started out as a Lisp hacker on machines designed for it (PDP-10 and CADR, later D-machines) so I was very much in the camp you describe. They had hardware / microcode support for tagging, unboxing, fundamental Lisp opcodes, and for the Lispms specifically, things like a GC barrier and transporter support. When I looked at implementations like VAXLisp, the extra cycles needed to implement these things seemed like a burden to me. Of course those machines did lots of other things as well, and so were subject to a lot of evolutionary pressure the research machines were not subject to. The shocker that changed my mind was the idea of using the TLB to implement the write barrier. Yes, doing all that extra work cost cycles, but you were doing on a machine that had evolved lots of extra capabilities that could ameliorate some of the burden. Plus the underlying hardware just got faster faster (I.e. second derivative was higher). Meanwhile, the more dedicated architectures were burning valuable real estate on these features and couldn’t keep up elsewhere. You saw this in the article when the author wrote about gates that could have been used elsewhere. Finally, some decisions box you in — the 64kb object size limitation being an example in the 432. Sure, you can work around it, but then the support for these objects becomes a deadweight (part of the RISC argument). You see this also in the use of GPUs as huge parallel machines, even though the original programming abstraction was triangles. Going back to my first sentence about “at the margins”: optimize at the end. Apple famously added a “jvm” instruction — must have been the fruit of a lot of metering! Note that they didn’t have to do this for Objective-C: some extremely clever programming made dispatch cheap. Tagging/unboxing can be supported in a variety of (relatively) inexpensive ways by using ALU circuitry otherwise idle during address calculation OR (more likely these days) by implementing a couple of in demand ops, either way pretty cheap. Finally, we do have a return to and flourishing of separate, specialized functional units (image processors, “learning” units and such, like, say, the database hardware of old) but they aren’t generally fully programmable (even if they have processors embedded in them) but they key factor is that they don’t interfere (except via some DMA) with the core processing operations.
- panick21_ 4y ago
  Not adding tagging is basically a negligence crime. That feature isn't that expensive and it could have saved most of the security issues that have happened to last 20+ years.
  - Lammy 4y ago
    NSA et al probably like better it that way so they have easier access to the "'intel' inside" my PC.
    - panick21_ 4y ago
      That's an incredibly bad argument because these are the same computer the NSA and the US govenrment itself uses and they are exposing themselves. Not to mention all the US company who are subject to intellectual property theft and so on.
      - gumby 4y ago
        Unfortunately the Information Assurance part of NSA’s mission seems to have diminished dramatically in the 21st century. But your point still stands about in house use.
  - aardvark179 4y ago
    I think you are talking about different types of tagging. Tagging on Lisps and other language VMs is where some bits in a pointer are reserved to indicate the type. So with a single tag bit integers might be marked as type 0 (so you don’t need to shift things when doing arithmetic) and other objects would be type 1. This provides no real protection against malicious code at all. There are other types of pointer tagging that do provide security, and we are starting to see some support in hardware.
    - panick21_ 4y ago
      Its the same basic concept you can use in multiple ways. But yeah of course security was not what tagging was used.
monocasa 4y ago
If you squint hard enough, the underlying object capability system as privilege boundary concept still does live on. In hardware the 432 went on to inspire 16 and 32 protected modes on x86. There it was inspiration for just about anything involving the GDT and the LDT including fine grained memory segments, hardware task switching of Task State Segments, and virtual dispatch through Task Gates. But a large point of the RISC revolution was that these kinds of abstractions in microcode don't make sense anymore when you have ubiquitous I$s. Rather than a fixed length blob of vendor code that's hard to update, let end users create whatever abstractions they feel make sense in regular (albeit if privileged) code. Towards that end the 90s and 2000s had an explosion of supervisor mode enforced object capability systems. These days the most famous is probably sel4; there are a lot of parallels between sel4's syscall layer and the iAPX432's object capability interface between user code and microcode. In a lot of ways the most charitable way to look at the iAPX432 microcode was as a very early microkernel in ROM.
- markhahn 4y ago
  timing is interesting: ia432 listed as "late 1981" (wikipedia), and 286 (protected mode 16:16 segmentation) in Feb 1982. of course, the 432 had been going on for some time...
userbinator 4y ago
There were some attempts in the Java direction: https://en.wikipedia.org/wiki/Java_processor https://en.wikipedia.org/wiki/Java_processor But ultimately it seems that the idea of language-specific CPUs just didn't survive because people want to be able to use any programming language with them.
- panick21_ 4y ago
  The Java-Everything trip Sun went on was truly horrific. Both in terms of technical and business results.
- lproven 4y ago
  > people want to be able to use any programming language with them. And then, except for a few rounding errors, they actually use C.
rodgerd 4y ago
> Is there anything comparable surviving today? Surviving? No. The most recent is arguably Sun's Rock processor, which was one of the final nails in their coffin, was quite an i432 redux. It promised all sorts of hardware support for transactions and other features that Sun thought would make it a killer chip, was rumoured to tape out requiring 1 kW of power for mediocre performance, and Oracle killed it when they saw how dysfunctional it was.
deleted 4y ago
[deleted]
djmips 4y ago
I feel like the Nvidia chips from NV1-NV3 were doing a take on this idea IIRC. My memory is foggy and would really love to see the documentation again. Possibly it survived on beyond the original chips? I'm not entirely sure if it was just the driver API or the actual hardware that supported objects but definitely they were trying to abstract it that way. I found this through googling "redesigned PGRAPH objects, introducing the concept of object class in hardware" https://media.readthedocs.org/pdf/envytools/latest/envytools.pdf https://media.readthedocs.org/pdf/envytools/latest/envytools... And. https://envytools.readthedocs.io/en/latest/hw/graph/intro.html https://envytools.readthedocs.io/en/latest/hw/graph/intro.ht...

yourapostasy 4y ago

> Is there anything comparable surviving today? I'm not aware of such Super CISC instruction sets in popular use today, but I wonder with VM's and statistically-based AI proliferating now, whether we might revisit such architectures in the future. Could continuous VM-collected statistical data inform compiler and JIT compiler design to collapse expensive, common complex operations we can't identify patterns for with current methods into Super CISC instructions that substantially speed up patterns we didn't know previously existed, or are our current methods to analyze and implement compilers and JIT's good enough and what's mostly holding them back these days are other factors like memory and cache access speed and pipeline stalls?

gumby 4y ago

I don’t think so, except at the margins. I started out as a Lisp hacker on machines designed for it (PDP-10 and CADR, later D-machines) so I was very much in the camp you describe. They had hardware / microcode support for tagging, unboxing, fundamental Lisp opcodes, and for the Lispms specifically, things like a GC barrier and transporter support. When I looked at implementations like VAXLisp, the extra cycles needed to implement these things seemed like a burden to me. Of course those machines did lots of other things as well, and so were subject to a lot of evolutionary pressure the research machines were not subject to. The shocker that changed my mind was the idea of using the TLB to implement the write barrier. Yes, doing all that extra work cost cycles, but you were doing on a machine that had evolved lots of extra capabilities that could ameliorate some of the burden. Plus the underlying hardware just got faster faster (I.e. second derivative was higher). Meanwhile, the more dedicated architectures were burning valuable real estate on these features and couldn’t keep up elsewhere. You saw this in the article when the author wrote about gates that could have been used elsewhere. Finally, some decisions box you in — the 64kb object size limitation being an example in the 432. Sure, you can work around it, but then the support for these objects becomes a deadweight (part of the RISC argument). You see this also in the use of GPUs as huge parallel machines, even though the original programming abstraction was triangles. Going back to my first sentence about “at the margins”: optimize at the end. Apple famously added a “jvm” instruction — must have been the fruit of a lot of metering! Note that they didn’t have to do this for Objective-C: some extremely clever programming made dispatch cheap. Tagging/unboxing can be supported in a variety of (relatively) inexpensive ways by using ALU circuitry otherwise idle during address calculation OR (more likely these days) by implementing a couple of in demand ops, either way pretty cheap. Finally, we do have a return to and flourishing of separate, specialized functional units (image processors, “learning” units and such, like, say, the database hardware of old) but they aren’t generally fully programmable (even if they have processors embedded in them) but they key factor is that they don’t interfere (except via some DMA) with the core processing operations.

panick21_ 4y ago
Not adding tagging is basically a negligence crime. That feature isn't that expensive and it could have saved most of the security issues that have happened to last 20+ years.
- Lammy 4y ago
  NSA et al probably like better it that way so they have easier access to the "'intel' inside" my PC.
  - panick21_ 4y ago
    That's an incredibly bad argument because these are the same computer the NSA and the US govenrment itself uses and they are exposing themselves. Not to mention all the US company who are subject to intellectual property theft and so on.
    - gumby 4y ago
      Unfortunately the Information Assurance part of NSA’s mission seems to have diminished dramatically in the 21st century. But your point still stands about in house use.
- aardvark179 4y ago
  I think you are talking about different types of tagging. Tagging on Lisps and other language VMs is where some bits in a pointer are reserved to indicate the type. So with a single tag bit integers might be marked as type 0 (so you don’t need to shift things when doing arithmetic) and other objects would be type 1. This provides no real protection against malicious code at all. There are other types of pointer tagging that do provide security, and we are starting to see some support in hardware.
  - panick21_ 4y ago
    Its the same basic concept you can use in multiple ways. But yeah of course security was not what tagging was used.

monocasa 4y ago

If you squint hard enough, the underlying object capability system as privilege boundary concept still does live on. In hardware the 432 went on to inspire 16 and 32 protected modes on x86. There it was inspiration for just about anything involving the GDT and the LDT including fine grained memory segments, hardware task switching of Task State Segments, and virtual dispatch through Task Gates. But a large point of the RISC revolution was that these kinds of abstractions in microcode don't make sense anymore when you have ubiquitous I$s. Rather than a fixed length blob of vendor code that's hard to update, let end users create whatever abstractions they feel make sense in regular (albeit if privileged) code. Towards that end the 90s and 2000s had an explosion of supervisor mode enforced object capability systems. These days the most famous is probably sel4; there are a lot of parallels between sel4's syscall layer and the iAPX432's object capability interface between user code and microcode. In a lot of ways the most charitable way to look at the iAPX432 microcode was as a very early microkernel in ROM.

markhahn 4y ago
timing is interesting: ia432 listed as "late 1981" (wikipedia), and 286 (protected mode 16:16 segmentation) in Feb 1982. of course, the 432 had been going on for some time...

userbinator 4y ago

There were some attempts in the Java direction: https://en.wikipedia.org/wiki/Java_processor https://en.wikipedia.org/wiki/Java_processor But ultimately it seems that the idea of language-specific CPUs just didn't survive because people want to be able to use any programming language with them.

panick21_ 4y ago
The Java-Everything trip Sun went on was truly horrific. Both in terms of technical and business results.
lproven 4y ago
> people want to be able to use any programming language with them. And then, except for a few rounding errors, they actually use C.

rodgerd 4y ago

> Is there anything comparable surviving today? Surviving? No. The most recent is arguably Sun's Rock processor, which was one of the final nails in their coffin, was quite an i432 redux. It promised all sorts of hardware support for transactions and other features that Sun thought would make it a killer chip, was rumoured to tape out requiring 1 kW of power for mediocre performance, and Oracle killed it when they saw how dysfunctional it was.

deleted 4y ago

[deleted]

djmips 4y ago

I feel like the Nvidia chips from NV1-NV3 were doing a take on this idea IIRC. My memory is foggy and would really love to see the documentation again. Possibly it survived on beyond the original chips? I'm not entirely sure if it was just the driver API or the actual hardware that supported objects but definitely they were trying to abstract it that way. I found this through googling "redesigned PGRAPH objects, introducing the concept of object class in hardware" https://media.readthedocs.org/pdf/envytools/latest/envytools.pdf https://media.readthedocs.org/pdf/envytools/latest/envytools... And. https://envytools.readthedocs.io/en/latest/hw/graph/intro.html https://envytools.readthedocs.io/en/latest/hw/graph/intro.ht...