3 ms·

I'm working on the instruction decoding and the microcode. (The microcode ROM takes up a large part of the chip.) The 8086 patent and some articles discuss the

by kens 6y ago

I'm working on the instruction decoding and the microcode. (The microcode ROM takes up a large part of the chip.) The 8086 patent and some articles discuss the microcode in some detail, but not enough to understand it. So I'm figuring out the microcode encoding. As for the 8086 instruction set, it's kind of a jumble due to the need for backwards compatibility (of a sort) with the 8080. The 8086 instruction set doesn't make things easy for the chip implementation. Intel tried to make a nicer instruction set (with the i432 and then Itanium) but it didn't work out.

PhantomGremlin 6y ago
The 8086 instruction set doesn't make things easy for the chip implementation. Intel tried to make a nicer instruction set (with the i432 and then Itanium) but it didn't work out. The i432 instruction set was, most emphatically, not nicer for implementation. E.g. it had bit-aligned variable-length instructions. Let me repeat that, because it's totally insane: bit-aligned variable-length instructions[1] I knew quite a few people who worked on the i432 implementation, and architectural decisions like that nearly drove them insane. Intel top management at the time didn't have people who understood what was happening, and consequently let the i432 architects "play in the sand". I always enjoyed that witty pun: "play in the sand" is what young children do in sandboxes; "sand" is mostly silicon dioxide and is often slang for what silicon chips are made of. [1] https://en.wikipedia.org/wiki/IAPX432#The_project's_failures https://en.wikipedia.org/wiki/IAPX432#The_project's_failures
- kens 6y ago
  You are definitely correct. I meant that the instruction was nicer in a holistic sense, not better for implementation. (RISC is the way to go if you want to make the implementation easy. It's remarkable how straightforward the ARM1 chip is, for instance.) I encourage people to read about the i432 processor, to get an idea of how wildly different a processor design can be. Among other things, objects are built into the processor. Object pointers are created by the processor, so you can't make an out-of-bounds pointer. (In other words, many current security issues don't exist.) The processor includes garbage collection, in hardware.
  - nullc 6y ago
    You should checkout S390x-- I've been chasing an issue with crypto code being non-constant time because the instruction set includes the functional equivalent of memcmp and gcc emits it liberally e.g. for integer comparisons. ... and it's probably one of the least weird ultra-ciscy instructions that architecture has.
kps 6y ago
Itanium seems to me a demonstration that Intel learned absolutely nothing from the i860: high theoretical peak performance, but absolutely useless in practice. (I still think BiiN / i960MX was relatively nice, and the i960CA showed that a modern implementation would work.)

by kens 6y ago

PhantomGremlin 6y ago

The 8086 instruction set doesn't make things easy for the chip implementation. Intel tried to make a nicer instruction set (with the i432 and then Itanium) but it didn't work out. The i432 instruction set was, most emphatically, not nicer for implementation. E.g. it had bit-aligned variable-length instructions. Let me repeat that, because it's totally insane: bit-aligned variable-length instructions[1] I knew quite a few people who worked on the i432 implementation, and architectural decisions like that nearly drove them insane. Intel top management at the time didn't have people who understood what was happening, and consequently let the i432 architects "play in the sand". I always enjoyed that witty pun: "play in the sand" is what young children do in sandboxes; "sand" is mostly silicon dioxide and is often slang for what silicon chips are made of. [1] https://en.wikipedia.org/wiki/IAPX432#The_project's_failures https://en.wikipedia.org/wiki/IAPX432#The_project's_failures

kens 6y ago
You are definitely correct. I meant that the instruction was nicer in a holistic sense, not better for implementation. (RISC is the way to go if you want to make the implementation easy. It's remarkable how straightforward the ARM1 chip is, for instance.) I encourage people to read about the i432 processor, to get an idea of how wildly different a processor design can be. Among other things, objects are built into the processor. Object pointers are created by the processor, so you can't make an out-of-bounds pointer. (In other words, many current security issues don't exist.) The processor includes garbage collection, in hardware.
- nullc 6y ago
  You should checkout S390x-- I've been chasing an issue with crypto code being non-constant time because the instruction set includes the functional equivalent of memcmp and gcc emits it liberally e.g. for integer comparisons. ... and it's probably one of the least weird ultra-ciscy instructions that architecture has.

kps 6y ago

Itanium seems to me a demonstration that Intel learned absolutely nothing from the i860: high theoretical peak performance, but absolutely useless in practice. (I still think BiiN / i960MX was relatively nice, and the i960CA showed that a modern implementation would work.)