Live data from Hacker News

Undocumented 8086 instructions, explained by the microcode

righto.com

101–104 of 104 posts

Re: Undocumented 8086 instructions, explained by the microcode

#101
post #79

Aside: If you are writing stuff this good (and this niche) I would say ditch the ads. They really will turn off the audience you want to attract. Or at least use one of the developer-focused ad networks that just inline ads not pop them up.

> Aside: If you are writing stuff this good (and this niche) I would say ditch the ads. They really will turn off the audience you want to attract. Or at least use one of the developer-focused ad networks that just inline ads not pop them up. Similarly, not having https properly configured is a huge turnoff - it literally takes 5 minutes with LetsEncrypt

Jfc remind me to never write for nerds. You guys are insufferable.

Re: Undocumented 8086 instructions, explained by the microcode

#102

Earlier quoted context omitted.

Was the 186 really different from the 286 in that respect?

Yes, the 186 microcode is remarkably similar to that of the original 8086, except for some encoding differences. Multiply/divide is now assisted by the ALU, so the microcode mainly has to set up the registers and do the check for zero divisor / overflow. There is also a final adjustment to the result, because the hardware uses a non-restoring algorithm that may underflow. And for signed division, the operands are con…

Huh. I thought they were identical except for the 286 having more hardware and more microcode for all the protected mode stuff -- and less for not having timer/interrupt controller/DMA/etc.

Re: Undocumented 8086 instructions, explained by the microcode

#103
post #82

I can only imagine the nail-biting at Intel when repurposing the 8086's undocumented but instruction aliases for new 80[123]86's instructions. Intel had no way of knowing whether someone, somewhere, had written software using these aliases.

It is doubtful they cared one bit. The 186 was really targeted at the embedded market (which is why it integrated so much of the usual support chips roles onboard the CPU). So it did not likely figure much here. For the 286, do keep in mind that prior to IBM releasing the PC-AT, no one at Intel likely considered that anyone would want to use their newfangled 286 as nothing more than a "fast 8086". It appears that Int…

I wonder what happens when a 286 in protected mode flips PE back to 0, assuming sane values in seg regs etc. Do you end up in some kind of unreal mode, does it lock up completely, or what happens?

Re: Undocumented 8086 instructions, explained by the microcode

#104
post #82

Earlier quoted context omitted.

It is doubtful they cared one bit. The 186 was really targeted at the embedded market (which is why it integrated so much of the usual support chips roles onboard the CPU). So it did not likely figure much here. For the 286, do keep in mind that prior to IBM releasing the PC-AT, no one at Intel likely considered that anyone would want to use their newfangled 286 as nothing more than a "fast 8086". It appears that Int…

I wonder what happens when a 286 in protected mode flips PE back to 0, assuming sane values in seg regs etc. Do you end up in some kind of unreal mode, does it lock up completely, or what happens?

According to this post: https://retrocomputing.stackexchange.com/questions/219/80286...

attempting to set the PE bit back to zero has no effect:

> The CPU is put into protected mode by setting the PE bit in MSW using the LMSW or LOADALL instructions. Clearing the PE bit has no effect using either of those instructions, thus it is not possible to switch back to real mode.

Post reply on HN