logoalt Hacker News

kenstoday at 5:50 PM4 repliesview on HN

Author here if anyone has questions about the 8087's microcode...


Replies

ChuckMcMtoday at 6:33 PM

I worked in Systems Validation at Intel when the 8087 was current. Intel had an engineer dedicated to validating customer bug reports and reproducing them. Day in, day out, that's pretty much all he did. Sooooo many corner cases, and so many opinions on what the 'right' thing to do was when you lost precision[1].

[1] I'd say that over half of the bug reports were people who were annoyed that doing fp instructions in one order got them the right answer but in another order got them the wrong answer.

show 1 reply
mysterydiptoday at 6:08 PM

80 bits always seemed a strange choice for floating point, but as soon as you said there’s a 16-bit exponent and a 64-bit fraction part, it made sense.

I assume microcode was a choice for both ease of development/testing/changes and saving die space. Would there come a point later on where performance could be gained by converting the microcode into a full set of discrete logic, or is that not worth the effort?

show 1 reply
monocasatoday at 8:11 PM

I found it interesting that this uinstr format doesn't include omnipresent control flow bits like I see in most uinstr archs. I was going to ask about RNI being it's own instruction, but looked at the microcode dump you linked to, and it's clear that you'd need a nop in almost all of those slots anyway because of the delay apparently needed after register transfers.

So I guess my question is: what do you see as the reasons why you'd pick a particular school of micro control flow as a microcode engine implementer? ie. along the spectrum of 'no increment on upc, every uinstr explicitly encodes jump, maybe oring bits into the address for conditional control flow', to 'looks like a relatively normal assembly, assumed incrementing program counter, specialized control flow uinstrs otherwise'.

mysterion1today at 6:26 PM

Wouldn't it be simpler for Intel to have designed a chip, with those 8 identical instructions (xfer, shift, add, arith, far jmp, far call, local jmp, misc), but read/executed from normal RAM accessible by the user, perhaps with a tiny cache, instead all these ROM/microcode special compression/hidden architecture shenanigans?

show 3 replies