Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Undocumented 8086 instructions, explained by the microcode

righto.com

Post reply on HN
Print view View original

81–90 of 104 posts

Re: Undocumented 8086 instructions, explained by the microcode

#81

Post by anyfoo »

Someone wrote: post #74
anyfoo wrote: post #34

Earlier quoted context omitted.

In a similar vein, C000 == 49152 has been burned into my brain. I recognize it immediately, because that’s where most C64 assembly programs were loaded, followed by “SYS 49152” for loading them. A000 for example I recognize, but can’t tell you as quickly what it is in decimal as I can with C000.

Weird how the brain works, given that 0xA000 = 0xA × 0x1000 = 10 × 0x1000 and I guess you know 0x1000 = 4096

I just know 49152 on another level, as SYS49152 was part of very early childhood. No thinking at all necessary, even as trivial as 40960=10x4096. 49152 is ingrained.

Re: Undocumented 8086 instructions, explained by the microcode

#82

Post by pwg »

quotemstr wrote: post #52

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 Intel's plan for the 286 was that everyone would also have a 286 protected mode OS to run upon it, and 8086 real mode was included only for the purposes of setting up the minimum necessary protected mode data tables to enable a switch into protected mode. This is one of the reasons why the 286 provided no documented way to leave protected mode once the OS flipped the PE bit in CR0 to 1. And, in 'protected mode' one has to provide protection against executing invalid opcodes for it to be properly a 'protected mode'.

The fact that most 286 system purchasers were running their shiny new 286 as nothing more than a fast 8086 for many years probably caused much more consternation at Intel than the fact that the [12]86's generated exceptions for undocumented 8086 opcodes.

Re: Undocumented 8086 instructions, explained by the microcode

#83

Post by pickledcods »

__s wrote: post #80
pickledcods wrote: post #78

Earlier quoted context omitted.

Yes, like many others. That's why I upped the ante by stating "numeric and lowercase characters only". And with the glyph differences between them also create a "hidden" image. Editted: What you reference to is a compiler and something completely different.

Not completely different, because the output of the compiler is itself ASCII. So it compiles any C program into an ASCII exe

Both projects stem from the same root, TXT=EXE. However, both branch in totally different directions. One says "any printable goes" whereas the other says "only the smallest subset (preferably also for ASCII art) goes", mainly being being “0123456789acemnorsuvwxz”.

These are two different projects with different design goals and challenges. Tom's built a compiler around it, I created a bootloader that consists of only MUL and XOR.

I don't understand why I feel that I have to defend myself, I thought hackers love these kind of projects, yet it seems I got cancelled.

A true innovation would be to combine both projects. One that inputs source code plus an image and outputs ASCII art that runs like a program.

Re: Undocumented 8086 instructions, explained by the microcode

#86

Post by crest »

gnat wrote: post #18
_ugfj wrote: post #15

> The undocumented C9 opcode is identical to the documented CB, far return instruction. I remember this. Once ... gosh, it's hard to believe how long ago that was now, but once I knew the entire Z80 opcode table off head. I could read the Z80 machine code and disassemble it. High school crowded that stuff out of my head, I went to a special math school, it was very very hard. Except... C9 was RET (and the Z80 is an e…

I'm the same with LDA immediate = A9 in 6502 machine code, from my C64 days. It's disturbing how strongly burned-in those neurons are ...

$18, $69, xx

Re: Undocumented 8086 instructions, explained by the microcode

#87

Post by toast0 »

bonzini wrote: post #60
toast0 wrote: post #56

Earlier quoted context omitted.

> It's very weird that the push and pop are in completely different places in the opcode map. Are they? There's a lot of different opcodes for push and pop, but if I'm reading right, for a given address mode, the op code for push and pop always differs by one bit (which bit changes though) https://www.felixcloutier.com/x86/push https://www.felixcloutier.com/x86/pop

He's talking about 8F/0 (pop) and FF/6 (push).

Yep, somehow I missed that. 8 and F are sort of close, but not really.

Re: Undocumented 8086 instructions, explained by the microcode

#88

Post by mrguyorama »

SomeRndName11 wrote: post #64
sedatk wrote: post #57

Earlier quoted context omitted.

Also a fantastic TV series about the personal computing era of the 80's. https://www.imdb.com/title/tt2543312/

The show is mediocre, lots of technical inaccuracies.

It also has a lot of soap opera syndrome, where the characters are all mary sues, and constantly make new problems when there are none to be dramatic about. They are entirely unlikeable and spend all their time not name-dropping nerd bait being assholes and punishing you as a viewer for being invested in anything.

The show feels like if you were supposed to take It's Always Sunny seriously, for drama. Meanwhile there just happens to be 25 years of computer history occasionally shoved into the background, that magically is the fault of the same like four people.

Re: Undocumented 8086 instructions, explained by the microcode

#89

Post by mrguyorama »

pickledcods wrote: post #83
__s wrote: post #80

Earlier quoted context omitted.

Not completely different, because the output of the compiler is itself ASCII. So it compiles any C program into an ASCII exe

Both projects stem from the same root, TXT=EXE. However, both branch in totally different directions. One says "any printable goes" whereas the other says "only the smallest subset (preferably also for ASCII art) goes", mainly being being “0123456789acemnorsuvwxz”. These are two different projects with different design goals and challenges. Tom's built a compiler around it, I created a bootloader that consists of onl…

>yet it seems I got cancelled.

Holy hyperbole captain. Apparently not being heaped in praise and getting the usual amount of hyper cynical HN criticism is "being cancelled" now.

Post reply on HN