Amazing article if you are into building, designing or emulating your own CPU :)
> Another unusual feature was that the 432 was a stack-based machine, pushing and popping values on an in-memory stack, rather than using general-purpose registers.
> Almost every structure in a 432 program and in the system itself is a separate object. The processor provided fine-grain security and access control by checking every object access to ensure that the user had permission and was not exceeding the bounds of the object. This made buffer overruns and related classes of bugs impossible, unlike modern processors.
Back in the late 1990s I worked on firmware for a dual PRI ISDN card that used an i960, and was quite impressed with its performance. Register windows made interrupts surprisingly performant. The hardest part of that project was fixing a stability issue caused by buggy logic in one of the CPLDs for bus arbitration between the i960, HDLC controllers and the PCI bridge. After fixing every firmware bug I could find, the issue simply had to be hardware. Once I had a few stress tests with the same firmware running on the older ISA version of the board and a borrowed logic probe, it was easy to prove the issue and come up with a fix. It was an OEM board that we were thankfully able to do the product stabilization work ourselves once the vendor realized they weren't going to get it done themselves any time soon.
Amazing article if you are into building, designing or emulating your own CPU :)
> Another unusual feature was that the 432 was a stack-based machine, pushing and popping values on an in-memory stack, rather than using general-purpose registers.
> Almost every structure in a 432 program and in the system itself is a separate object. The processor provided fine-grain security and access control by checking every object access to ensure that the user had permission and was not exceeding the bounds of the object. This made buffer overruns and related classes of bugs impossible, unlike modern processors.
Hail to the king baby
Back in the late 1990s I worked on firmware for a dual PRI ISDN card that used an i960, and was quite impressed with its performance. Register windows made interrupts surprisingly performant. The hardest part of that project was fixing a stability issue caused by buggy logic in one of the CPLDs for bus arbitration between the i960, HDLC controllers and the PCI bridge. After fixing every firmware bug I could find, the issue simply had to be hardware. Once I had a few stress tests with the same firmware running on the older ISA version of the board and a borrowed logic probe, it was easy to prove the issue and come up with a fix. It was an OEM board that we were thankfully able to do the product stabilization work ourselves once the vendor realized they weren't going to get it done themselves any time soon.
Previous discussion:
The complex history of the Intel i960 RISC processor (righto.com)
126 points by zdw on July 1, 2023 | past | 68 comments
https://news.ycombinator.com/item?id=36552844