Intel 80386, part 1: Introduction | Hacker News Reader

Intel 80386, part 1: Introduction

blogs.msdn.microsoft.com

141 pointsnikbackm18 comments

Raymond Chen is such a joy to read. I’m old and jaded enough to have very mixed feelings about Microsoft but it’s obvious they’ve had some very talented programmers over the years.

If I didn’t get enough pleasure from using Microsoft software over the years as I did from other OS’s I certainly made up for it reading stories from MS folk like Raymond.

As always a great and informative read!

See also the second and third installment:

https://blogs.msdn.microsoft.com/oldnewthing/20190122-00/?p=...

https://blogs.msdn.microsoft.com/oldnewthing/20190123-00/?p=...

The 80386 is unusual in that it supports multiple calling conventions

It's unusual to speak of a processor as "supporting" any calling convention, given that they are simply a convention compilers may follow. The CPU doesn't care (and in the case of the 386 which has no return address prediction or special stack handling, it really doesn't matter) about such things as functions or procedures either, as you'll quickly realise if you read good optimised handwritten Asm.

Instruction encoding is highly irregular.

It looks very regular in octal:

http://www.dabo.de/ccc99/www.camp.ccc.de/radio/help.txt

For x86 information, I really enjoyed Xeno Kovah's OpenSecurityTraining courses for Intro and Intermediate x86. Recording quality is a bit spotty, but their whole YouTube channel is filled with great content.

Do not see the point of the microsoft one but these video are great!

My first owned PC, a 386SX at 20 MHz, quite a departure from the PCW 1512 at school computer club or the Timex 2068 at home.

However I still kept a bit of envy from my friends having fun with their Amiga 500s.

I'm still envious of my friends with Amiga 500s. The Amiga just kind of does that to people.

Personally I was looking forward to an intro to TSR programs :)

I wonder if when these processors were developed, from a hardware standpoint, did the engineering team contemplate Turing completeness and the theory of computation, or just try to satisfy a set of perceived customer needs.

They got Turing completeness in just the MMU. This was surely unintended, just like Turing completeness in C++ template expansion and Turing completeness in sendmail configuration files.

Here you go, computation via continuous MMU faults without actually completing any instructions:

https://github.com/jbangert/trapcc

https://www.youtube.com/watch?v=eSRcvrVs5ug

> They got Turing completeness in just the MMU.

Since the amount of adressable memory on any CPU is finite, while a Turing machine needs in infinite band of memory, such claims of Turing-completeness of processors or in this case the MMU are clearly fraudulent.

Only an abstract mathematical model can be Turing-complete - there exists no physical realization of a Turing-complete system/Turing machine and there will never be.

This is completely pointless pedantry. Everybody knows that, and nobody bothers to type "Turing-complete (up to memory constraints)" all the time. Real mathematicians do this all the time, taking shortcuts with the understanding that they could phrase it completely rigorously if it were necessary.

Turing completeness is easier to achieve than to avoid. If you have conditional branching and an unbounded store (memory is finite of course, but it's arbitrarily finite) it is Turing complete.

So they may not have cared, but the analysis step would have been really simple. And if you don't want to bother with any formalia you can just implement Brainfuck (or less anachronistically you can go with FRACTAN), if it works you have something Turing complete.

It's difficult (though not quite impossible) to make a non-Turing-complete processor and still have it do useful things. So by making a processor that can do useful things, you have made it Turing complete.

If "tiring completeness" is supposed to read "Turing completeness", then including a conditional jump instruction of any sort completes the hardware requirement. The rest is about the number of conditions upon which that may be based and the access semantics, and that's where the CISC, RISC and hybrid approaches differ.

Agreed. I'm just wondering if they followed some theoretical schema or just responded to evolutionary forces. Most likely the latter.

It’s a direct evolution from 4004, 8008, 8080, to 8086. There was no compatibility but you can see the inspiration. IIRC 8086 was assembly compatible with 8080 but not binary compatible.

At the time superscalar, register-renaming, vector-capable, and out-of-order were distant dreams and RAM was faster than the CPU. Everyone wrote assembly so the CPU designs accumulated instructions to make life easier on assembly programmers.

8086 was actually a stop-gap. The architecture astronauts at Intel that thought real hard about design were working on the iAPX 482, which was a stack machine that supported garbage collection in hardware(!)

432

Reply on news.ycombinator.com