Welcome, Guest. Please login or register.

Author Topic: What's so bad about Intel 8086 in technical terms?  (Read 21061 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline NorthWay

  • Full Member
  • ***
  • Join Date: Jun 2003
  • Posts: 209
    • Show all replies
Re: What's so bad about Intel 8086 in technical terms?
« on: June 10, 2014, 11:15:40 PM »
In an era when people still hand-coded in asm, the 68K had room to breathe and express ideas, while the x86 was so cramped it gave you headaches.

Use a high-level language and it doesn't matter really.
A good architecture will probably go faster than a worse one. Throw billions of transistors at it and architecture disappears in the tech fog.
When your transistor budget was limited it was hard and expensive to transform something bad to something good. Nowadays you don't see the stuff that makes it go fast.
You don't want to try to write optimal assembler code these days, that is better left to the compiler.

How times have changed.
There is however someone trying to do both architecture and technology at the same time to go faster - search for "The Mill". Or just go to their site at http://millcomputing.com/
 

Offline NorthWay

  • Full Member
  • ***
  • Join Date: Jun 2003
  • Posts: 209
    • Show all replies
Re: What's so bad about Intel 8086 in technical terms?
« Reply #1 on: June 18, 2014, 10:54:23 PM »
Quote from: psxphill;767025
The only RISC processor that I like is 32 bit MIPS as all the others are horribly complex.

Didn't that one have the delay-slot after branch instruction that was later considered a dead-end?
(I.e. the instruction following a branch was always executed.)
 

Offline NorthWay

  • Full Member
  • ***
  • Join Date: Jun 2003
  • Posts: 209
    • Show all replies
Re: What's so bad about Intel 8086 in technical terms?
« Reply #2 on: June 18, 2014, 11:15:04 PM »
Much of the original thinking behind RISC designs was that compilers had a hard time using all the fancy CISC instructions.

It is not exactly rocket science to speed up those things it uses then.
Compilers only use simple instructions -> make a cpu with simple instructions and speed those up.

"The perfect number of registers in a CPU are 0, 1, or infinite" - quote from a class I took sometime.
Compilers have no trouble juggling lots of registers and figuring out when to keep values in registers and when to purge them. Many registers was an answer for having to go to memory for immediates and to lower memory pressure in general. With code going in loops it works.

RISC was a lot of good ideas that has had its advantages reduced by advances in manufacturing. RISC and CISC today are both struggling with instruction dependency and the IPC limits you get from that. EPIC and Mill have tried to break through that barrier. EPIC seems to be compiler limited and possibly with too much junk in the trunk, and Mill is so far mostly an idea. I don't know if there are other designs working on this.