I was slightly more getting at it being not a natural fit for a Unix-like OS but I accept your point.
AFAIK, sadly, Intel BiiN is lost to history now. A Register reader wrote in to me to tell me that he was one of the developers.
What I really wanted from a developer was the i960. Specifically, the version with the object protections. That might be worth buying today for secure, embedded work. If I found the right person, I'd ask them to open-source, or at least dual-license, the i960. For embedded systems, leave it as a RISC-V alternative or port it to RISC-V.
It was. (If you ever see this, thank you again, Mr Buchanan.)
> What I really wanted from a developer was the i960.
Interesting choice!
Given that Intel has a number of distinctive architectures in its historical portfolio, and is in trouble these days due to the competition from Arm and perhaps even RISC-V, I would love to see it do either experimental revivals of some of its architectures, or open up the specs for other ones.
(Someone there must bitterly regret selling off its Arm architecture license cheaply to Marvell; now, Marvell is worth more than Intel itself.)
How about modern die-shrinks of i860 and i960, or even just FPGA versions?
After the DEC/Compaq/HP implosion, Intel also ended owning the Alpha. I would not be at all averse to a resurrected Alpha chip, even if a very low-end chip on some old cheaper process tech.
Yes, even shrinks to nodes like 180-350nm would be helpful. The older nodes are still more reliable than modern ones due to the physics involved in deep-sub micron. While not power-efficient, both i960 and Alpha would be fast and reliable.
On FPGA’s, that’s a likely use. Crash-safe.org used Alpha ISA in their early prototype. It’s also just easy for experimentation. In security and accelerators, we’re seeing many companies just throw a fat FPGA. Then layer the improvements on it to avoid the NRE cost.
Btw, Alpha had something worth continuing to talk about in new designs: PALcode. From what Alpha people told me, it is in between microcode and kernel code in nature. They can switch to PAL mode to run a series of instructions as an atomic block with more access to internal parts of the CPU. Projects could essentially extend the CPU to make things like secure, context switching or concurrent GC’s easier. They don’t have to open their internals up as much as custom microcode either.
On that note, what I’d really prefer is custom microcode on an open ISA. There were HLL to microcode compilers, at least in academia, that let you synthesize the microcode from HLL algorithms. That would be super-helpful since one could eliminate problematic instructions or add better ones with no hardware changes. Intel could still differentiate on that, too.