Happy Birthday! X86 Turns 30 Years Old

javipas writes "On June 8th, 1978 Intel introduced its first 16-bit microprocessor, the 8086. Intel used then "the dawn of a new era" slogan, and they probably didn't know how certain they were. Thirty years later we've seen the evolution of PC architectures based on the x86 instruction set that has been the core of Intel, AMD or VIA processors. Legendary chips such as Intel 80386, 80486, Pentium and AMD Athlon have a great debt to that original processor, and as recently was pointed out on Slashdot, x86 evolution still leads the revolution. Happy birthday and long live x86."

Comments

Intel's anniversary too

[suso]

Intel's own 40th anniversary is coming up on July 18th. I guess the microcomputer industry is officially over the hill.

Nice self-reference double entendre Taco!

Re:Intel's anniversary too

[aproposofwhat]

Oh, thankyou, and get off my lawn!

Re:Intel's anniversary too

[Akita24]

Fifty is the new forty, so no it isn't.

Re:Intel's anniversary too

[canuck57]

Intel's own 40th anniversary is coming up on July 18th. I guess the microcomputer industry is officially over the hill.

Sure beats being under the hill.

Re:Intel's anniversary too

[Zaatxe]

But in Soviet Russia, the hill is over you, you insensitive clod!

Re:Intel's anniversary too

[kauttapiste]

Sure beats being under the hill.

Frodo, is that you?

Might want to check your FPU

[Anonymous Coward]

The story is a few days early. I think you may have a rounding bug somewhere.

Re:Might want to check your FPU

[somersault]

I did wonder how they weren't sure how certain they were. Perhaps they weren't certain how certain they were but were certain how right they were. These guys should be building quantum CPUs by now with such confuddling principles of certainty.

Re:Might want to check your FPU

[Anonymous Coward]

Happy Birthday! X86 Turns 29.991803 Years Old.

Re:Might want to check your FPU

[everphilski]

Slashdot's got to be early on a few news articles to make up for being behind on so many.

Oh wait, did I say a few? ;)

Re:Might want to check your FPU

[jpcloninger]

It appears that you have a Pentium rounding error, sir!

Re:Might want to check your FPU

[MiniMike]

I thought it was early so they could dup it in time for the real anniversary.

Re:Might want to check your FPU

[aproposofwhat]

confuddling - hehe - must add to 'words to challenge coworkers to use in official emails' list.

Brilliant neologism - I salute you :P

Re:Might want to check your FPU

[somersault]

There's a jahookin' load more where that came from!

Although I don't think I invented confuddling (confuzzling is another good variation), and it was my sister who invented jahookin' :P Everyone should embiggen their vocabulary from time to time, though unfortunately a lot of people will just question the cromulence of any new words :/

Re:Might want to check your FPU

[Kazymyr]

No, you may want to check your FPU, because in fact it's 29.99178607283015423929907821484 years.

Re:Might want to check your FPU

[Thumper_SVX]

I did wonder how they weren't sure how certain they were The figured out when to publish the article using a first gen Pentium.

Re:Might want to check your FPU

[treeves]

It can't be over 29.9792458 because that would violate the laws of physics!

Re:Might want to check your FPU

[Anonymous Coward]

Yes. In fact, time travel - if it ever happens - will have mostly negative dupotonic effects on slashdot.

Re:Might want to check your FPU

[spandex_panda]

I think you meant "confuddling puddles of certainty."

Oh you're welcome!

Re:Might want to check your FPU

[DeathElk]

Everyone should embiggen their vocabulary from time to time, though unfortunately a lot of people will just question the cromulence of any new words :/ I agree, albeit with some thrnoilghlefgn.

Re:Might want to check your FPU

[Anonymous Coward]

I think that Slashdot since a long time ago have forseen and mimicked the Intel multicore manufacturing process ie. slap two cores together.
Although Slashdot do separate them again, kind of like when twins get separated at birth, but with posts of course.

How Long?

[dintech]

I'm pretty sure x86 processors will still be in use for another 15 years at least. But, how much further will this architecture evolve? When will we see the demise of x86?

Re:How Long?

[flnca]

The demise of the x86 general architecture will not begin until Windows goes out of fashion. It's the only major platform strongly tied to that CPU architecture. x86 CPUs have been emulating the x86 instruction set in hardware for many years now. I guess, if they could, Intel / AMD / VIA and others would happily abandon the concept, because it leads to all sorts of complexities.

Re:How Long?

[peragrin]

Actually Intel keeps trying(Itanium?) and AMD uses a compatibility mode.

The problem is as usual MSFT. which only runs on windows. yes I know a decade ago NT 4.0 did run on PowerPC, and even a couple of alpha chips.

Apple with a fraction a of the software guys can keep their OS on two major different style of chips PowerPC, and Intel x86, along with 32bit and 64 bit versions of both. Sun keeps how many versions of Solaris?

Nope but Vista only runs on x86. So X86 will remain around as long as it does.

Re:How Long?

[B3ryllium]

Hrm, I wonder what this HAL thing is ... must be a virus! I'd better remove it.

Re:How Long?

[Hal_Porter]

The demise of the x86 general architecture will not begin until Windows goes out of fashion. It's the only major platform strongly tied to that CPU architecture. x86 CPUs have been emulating the x86 instruction set in hardware for many years now. I guess, if they could, Intel / AMD / VIA and others would happily abandon the concept, because it leads to all sorts of complexities. Yeah, they could move to an architecture with a simple, compact instruction set encoding which makes efficient use of the instruction cache and can be translated to something easier to implement on the fly with extra pipeline stages.

But wait, that's exactly what x86 is. In terms of code density it does pretty well compared to Risc. Modern x86s don't implement it internally, they translate it to Riscy uops on the fly and execute those. And over the years compilers have learned to prefer the x86 instructions that are fast in this sort of implementation. And, thanks to AMD it now supports 64 bit natively in its x64 variant. This is important. 64 bit maybe overkill today, but most architectures die because of a lack of address space (see Computer Architecture by Hennessy and Patterson). But 64 bit address spaces will keep x86/x64 going for at least a while.

http://cache-www.intel.com/cd/00/00/01/79/17969_codeclean_r02.pdf
If you know that the variable does not need to be pointer polymorphic (scale with the architecture), use the following guideline to see if it can be typed as 32-bit instead of 64-bit. (This guideline is based on a data expansion model of 1.5 bits per year over 10 years.)

IIRC 1.5 bits per year address space bloat is from Hennessy and Patterson.

At this point we have 30 unused bits of address space, assuming current apps need 32GB tops. That gives 64 bit x64 another 20 years lifetime!

Re:How Long?

[bsDaemon]

I think if Intel were really interested, they could force MS to follow suit. The problem, so long as AMD is willing to run the compatibility mode, Microsoft doesn't have to change -- and that means that Intel would have to lose out, at least in the home market.

I have little doubt that Intel could force a change on servers and corporate desktops, and Linux, BSD and Solaris, as well as Apple, would be able to adjust within a very short period of time to run on it.

Re:How Long?

[xgr3gx]

Once again - Microsoft and Windows stifle technological advancement.
Like the anology if Microsoft made cars
-they would all have coal fired steam engines that would require a 4000 gallon watertank and 12 tons of coal on hand.
(8000 gallons and 24 tons if you want the "Areo" experience)

Re:How Long?

[meadowsoft]

I wouldn't do that, Dave...

Re:How Long?

[Hatta]

That translation of x86 instructions must have some performance cost to it. What Intel should do is expose both sets of instructions, act like an x86 if the OS expects it, or act RISC-like if the OS expects that. Then everyone can have their Windows installed, and it creates an opening for other operating systems. An OS that uses the native instruction set should be a little faster, giving people a reason to use it over windows. That will encourage MS to port windows the the new instruction set, and voila we are free of x86.

Re:How Long?

[TheRaven64]

Many of the shortest opcodes on modern Intel CPUs are for instructions that are never used. Compare this with ARM, where the 16-bit thumb code is used in a lot of small programs and libraries and there are well-defined calling conventions for interfacing 32-bit and 16-bit code in the same program.

Modern (Core 2 and later) Intel chips do not just split the ops into simpler ones, they also combine the simpler ones into more complex ones. This was what killed a lot of the original RISC archs - that CISC multi-cycle ops became CISC single-cycle ops while compilers for RISC instructions were still generating multiple instructions. On ARM, this isn't needed because the instruction set isn't quite so brain-dead. ARM also has much better handling of conditionals (try benchmarking the cost of a branch on x86 - you'll be surprised at how expensive it is), since conditionals are handled by select-style operations (every instruction is conditional) and which reduces branch penalties and scales much better to superscalar architectures without the cost of huge register files.

Re:How Long?

[Anonymous Coward]

Wow, I can't imagine what we'll be doing with 18 billion billion bytes of *RAM*. That's what 64 bits of address space gives you.

Note: I've done supercomputing programming professionally, and I *still* think that's a whole lotta address space... not that I couldn't fill it up with data :-) but I just don't see even micros~1 making their apps so bloated as to require that much space.

Re:How Long?

[haystor]

Apple, with a fraction of the software guys, customizes BSD to multiple limited-hardware platforms.

Re:How Long?

[compro01]

Wow, I can't imagine what we'll be doing with 18 billion billion bytes of *RAM*. That's what 64 bits of address space gives you. [bashing joke]
maybe that will finally be enough to run vista at a decent speed.
[/bashing joke]

Re:How Long?

[bcrowell]

IIRC 1.5 bits per year address space bloat is from Hennessy and Patterson. [...] At this point we have 30 unused bits of address space, assuming current apps need 32GB tops. That gives 64 bit x64 another 20 years lifetime!
Empirically, it hasn't been growing at anywhere near that rate. Ca. 1980 my TRS-80 had a 16-bit address space, and had enough memory to exhaust all of the addresses. Today, I'm using computers that have 1 Gb of memory, which is 30 bits worth of address space. That's less than 0.5 bits per year.

Also, in order to keep the actual used address space growing at a constant number of bits per year, Moore's law would have to continue indefinitely. But most experts are saying it will probably stop in 10 to 30 years. If we keep growing at 0.5 bits per year, starting now at 30 bits, and stop growing at the Moore's law rate in 2038, then we'll only be using 45 bits worth of actual address space.

It's hard to grok how big a 64-bit address space would really be. As a reality check, let's say that I want to own every movie that's ever been listed on IMDB, and store every single one of those in my computer's RAM simultaneously. If each one takes as much storage as a 5 Gb DVD, and IMDB has 400,000 movies listed, then that's a total of 2x10^15 bytes, which is 50 bits. That's 16,000 times smaller than a 64-bit address space.

As another example, the human brain has about 10^11 neurons. Each of those may be connected to 10^4 other neurons, so the total number of connections is about 10^15. That suggests that the total amount of RAM needed for direct, brute-force modeling of a human brain (assuming we knew enough to program such a model, which we don't, and had parallel processors that could run such a simulation, which we don't) might be about 10^15 bytes, which is a 50-bit address space. A 64-bit address space is 16,000 times bigger than that.

I think we're likely to see flying cars, Turing-level AI, and vacations on the moon before we need 128-bit pointers.

Re:How Long?

[aproposofwhat]

damn - already commented on this thread, or you'd get a +1 - Asimov mod.

Re:How Long?

[aproposofwhat]

With that much RAM, you might even be able to fit an image of your mental state into it.

I'd have to defrag mine first, though :P

Re:How Long?

[SendBot]

y'know, in the future we'll look back on this time and laugh at how silly it was to say "16 exabytes should be enough for anyone"

Re:How Long?

[aproposofwhat]

You're talking about desktop computers - the serious applications out there (OLAP, scientific apps) are already a few bits ahead of you.

I'd also suggest that the state variables to describe each neuron and synaptic connection would be fairly complex, so the 16,000 times bigger probably shrinks quite a bit (hint - 1,000 separate connections per neuron can't be efficiently represented in less than 1,000 bits - and if we need FP accuracy, we're talking 32Kb / neuron).

Give me 128 bit pointers, or give me death!

Re:How Long?

[afidel]

Do you mean a +1 - Clark mod?

Re:How Long?

[erikdalen]

The biggest problem is probably like with 64-bit Windows: drivers.

Linux can just recompile them and Apple only supports hardware they distribute, so that makes it easier.

Re:How Long?

[Jor-Al]

I think you mean +1 - Clarke mod.

Re:How Long?

[aproposofwhat]

Too right - finished work and hit the brandy too soon :o)

(wish there was a way to do a red nose on a smiley...)

Re:How Long?

[scipiodog]

Apple with a fraction a of the software guys can keep their OS on two major different style of chips PowerPC, and Intel x86, along with 32bit and 64 bit versions of both.

Not for their next version.

Re:How Long?

[Hal_Porter]

That translation of x86 instructions must have some performance cost to it. What Intel should do is expose both sets of instructions, act like an x86 if the OS expects it, or act RISC-like if the OS expects that. Then everyone can have their Windows installed, and it creates an opening for other operating systems. An OS that uses the native instruction set should be a little faster, giving people a reason to use it over windows. That will encourage MS to port windows the the new instruction set, and voila we are free of x86. Actually Windows NT and its descendents are very portable - they were designed to run on i860, Mips, x86, Alpha and PPC. Even now they run on x86, x64, Itanium and PowerPC (in the XBox 360). All those ports probably made the code quite easy to port to new architectures. It's all the binary application software that isn't. Or rather it probably could be done if you had the source and time to do it, but lots of people have some very old applications that they don't want to buy again. E.g. Photoshop may be portable, but the copy of Photshop CSx I have on my desk isn't. And I don't to use the latest Photoshop version because it's slower and costs a lot of money. It's even worse if the company that made the app is out of business. But I buy a new copy of Windows every couple of years. So your hypothetical dual mode CPU could run Windows 7 natively. Some new apps would be native and some old ones x86. Actually x64 is already like this on Vista on x64 - the kernel is 64 bit and most applications will stay 32 bit, but x64 is no more native to the processor than x86.

The question is whether a processor running its native instruction set would be faster. From what I can tell the native instruction format of a modern x86 is wider than the x86 equivalent. Suppose the uops in the pipeline are 48 bit - a 32 bit constant and a 16 bit instruction. That is quite a bit larger than a typical x86 instruction. Wider instructions take more space in Ram and cache. You don't need to decode them, but the extra time fetching them kills the advantage.

And what is native is very implementation dependent. An AMD chip will have a very different uop format from an Intel one. Actually even between chip generations the uop format might change. Essentially Risc chips tried to make the internal pipeline format the ISA. But in the long run that wasn't good. Original Risc had branch delay slots and later superscalar implementations where branch delays work very differently had to emulate the old behaviour because it was no longer at all native. So if you did this you'd get an advantage for one generation but later generations would be progressively disadvantaged. Or you could keep switching instruction sets. But if most software is distributed as binaries that is impossible.

Re:How Long?

[bcrowell]

I'd also suggest that the state variables to describe each neuron and synaptic connection would be fairly complex, so the 16,000 times bigger probably shrinks quite a bit (hint - 1,000 separate connections per neuron can't be efficiently represented in less than 1,000 bits - and if we need FP accuracy, we're talking 32Kb / neuron).
Sure, let's go with your assumption of 32 kb/neuron rather than 10 kb/neuron. That means you add 2 bits on, and now the estimate is that you need 52 bits. It doesn't affect the result in any significant way. The whole thing is just an order-of-magnitude estimate, and I think you're sort of missing the point. If you could directly simulate a human brain on a computer, it would mean immortality, the end of history, the transformation of the human race into something completely different. The fact that you can do that in a 50- or 52-bit address space means IMO that it's kind of silly even to talk about 128-bit pointers.

For perspective, let's imagine what it would take to fill up a 256-bit address space. The number of atoms in the observable universe is estimated to be about 10^80. A 256-bit address space would have 10^77 addresses. In other words, if you wanted to manufacture 1000 computers, each of which had enough memory to exhaust a 256-bit address space, you would need to use up all the matter in the observable universe, assuming you could manufacture one bit of memory out of one hydrogen atom. The point here is that if the nth generation of computer chips uses pointers with 8x2^n bits (where n=1 for 16-bit machines in 1980, n=2 for 32-bit machines today, etc.), then the size of the address space varies like O(2^(2^n)), which just gets big ridiculously fast.

Re:How Long?

[Hatta]

All those ports probably made the code quite easy to port to new architectures. It's all the binary application software that isn't. Or rather it probably could be done if you had the source and time to do it, but lots of people have some very old applications that they don't want to buy again.

If a CPU can translate those instructions on the fly to another instruction set, couldn't the same be done in software? Instead of doing it on the fly, run it through a converter once and be done.

Your point that the "native" underlying instruction set may be highly variable is well taken though.

Re:How Long?

[menace3society]

One of the most successful computers in history, the VAX, died out long before it's address space got full.

I think what will kill x86 is a combination of rising energy costs and the growth of platform and architecture agnostic open source apps.

Re:How Long?

[Tarlus]

Nope but Vista only runs on x86. And x64.

* spine shivers *

Re:How Long?

[AmiMoJo]

MS have said that Windows Server 2008 will be the last 32 bit OS they put out, so Windows 7 will presumably be 64 bit only: http://arstechnica.com/news.ars/post/20070517-windows-vista-declared-32-bits-last-hurrah.html

Of course, you will still want to run 32 bit apps but I guess some kind of emulation, like Mac OS, would be fine. The incentive would be cost and silicone savings on new 64 bit only CPUs. Then we can retire x86.

Re:How Long?

[Directrix1]

Or they might be a Ford. Since Ford now uses Microsoft software in its nav/stereo/whatever computer.

Re:How Long?

[TwistedSpring]

You're a computer science undergrad, right?

Re:How Long?

[link5280]

On superscalar pipelined architectures there is no tangible performance hit when converting instructions. Even if the pipeline is flushed the performance hit only lasts for the next few instructions, until the pipeline is full again. Intel has done some remarkable engineering on the Core 2 processors that minimizes flushes and cache misses. Anyway, all modern processor that I know of convert their instructions to the CPUs corresponding microcode instructions (or microops in Intelâ(TM)s case). So whether its x86 instructions or some other type of instruction a conversion will occur.

Re:How Long?

[link5280]

A compiler could do the same thing as the CPU, convert x86 instructions to the native CPU microcode. However, you would lose backwards compatibility. Microcode is architecture dependent, so a higher level instruction set (i.e. x86) provides a level of abstraction for programmers and compilers. So itâ(TM)s actually a good thing.

Re:How Long?

[xgr3gx]

HaHa! Nice. :)
That is a pretty cool system though - I'll give them that. I wonder how long it'll take the other car co's to get a similar product.
Ford partner w/ Microsoft, does that mean they're exclusive?
Maybe linux car pc's will show up in GM. ahha.

Re:How Long?

[vux984]

The problem is as usual MSFT

The problem is NOT Microsft.

The problem is end users. They want to use their existing x86 hardware and software. They aren't really interested in not having drivers for anything more than 3 months old, and running all their existing software at 30-70% its current speed.

Look at the x64 versions of Windows. It highlights exactly the problem. XP x64 was crippled by lack of drivers, and Microsoft HAD to force the issue with Vista because the x86 ram limit was starting to hold things back. But even today most customers don't WANT the x64 edition. This issue isn't really MS. If they could abandon x86 and keep their customer base, they would, in a heartbeat.

Linux also supports other architectures, but the G5 as a linux platform is a pretty niche thing to do, since you have to compile a lot more stuff from source and not all of it is cpu agnostic, plus no proprietary linux software will run and you can't stick Windows into a VMware VM, etc.

yes I know a decade ago NT 4.0 did run on PowerPC, and even a couple of alpha chips.

And MS could release a version for another CPU within a couple months if they really wanted to, if not faster. But who is going to step up and rewrite all the drivers? Who is going to step up and rewrite all the applications? Leaving that to the 3rd party vendors? They aren't interested in anything but their current project... they aren't going to go back and recompile squat. Hell, most STILL aren't releasing x64 native code.

Apple with a fraction a of the software guys can keep their OS on two major different style of chips PowerPC, and Intel x86, along with 32bit and 64 bit versions of both.

1) Apple controls the drivers so that part of the issue is largely solved. Of course your 3rd party hardware might not work after they switch, but at least all the apple hardware works.

2) Apple didn't want to switch. They had to. Intel was kicking butt in performance, while IBM couldn't even deliver a mobile G5. Consumers were starting to get twitchy about the fact that Windows PCs were getting markedly faster, while mac laptops were still stuck on G4s.

3) The performance gap from the G4/G5 to the intel stuff had gotten so bad, that by the time Apple switched, running PPC code in emulation on intel was actually an improvement in some cases, and in most cases at least comparable to running on the (slower) native hardware.

4) Apple is killing off the PPC. Much new software is already intel only, and the next release of OSX is rumoured to be intel only.

Apple is really a whole other ball game. As for solaris... that's the same as linux... but even more niche. How many people do you know running solaris on ppc?

Re:How Long?

[drsmithy]

It's the only major platform strongly tied to that CPU architecture.

Given that Windows NT (and variants) is currently available on 3-4 different hardware platforms (depending on how you're counting), has in the past been available on 3 more and has been internally ported to at least 2 more, I'm interested in why you think it is "strongly tied" to x86.

Re:How Long?

[drsmithy]

The biggest problem is probably like with 64-bit Windows: drivers.

No, the biggest problem is applications . Same "problem" that stops people switching from Windows to $OS_DU_JOUR.

The second biggest problem, of course, is basic economics. What other hardware platform offers even the slightest amount of ROI for Microsoft to expend the effort on porting Windows to ? Where's the business case ?

Re:How Long?

[edalytical]

Apple has the OS running on ARM too. That makes three major ISAs.

Re:How Long?

[CompMD]

Solaris 10 will run on sparcv9 (64-bit) processors, AMD64 processors, and x86 processors.

Also, NT4 could run on MIPS RISC R4400 processors. I still have an original installation pack for NT4 workstation.

Re:How Long?

[drsmithy]

Apple with a fraction a of the software guys can keep their OS on two major different style of chips PowerPC, and Intel x86, along with 32bit and 64 bit versions of both. Sun keeps how many versions of Solaris?

Because they have to (and it's a toss-up whether the next major release of OSX will be available for PPC). Where's the business case for Microsoft to expend money supporting releases of Windows NT for any more than the 3-4 platforms it already does ?

Re:How Long?

[alan_dershowitz]

I don't know about MIPS or PowerPC, but the Alpha port of Windows NT could run X86 binaries.

Incidentally, I've heard that the HAL started losing compatibility after Windows NT4, and was pretty much tied to little-endian even so. At least, this is what a prior, highly-rated Slashdot post that I can't find right now claimed.

Re:How Long?

[hr raattgift]

I think we're likely to see flying cars, Turing-level AI, and vacations on the moon before we need 128-bit pointers.

128-bit linear addressing is not so useful, but you can introduce structure into the address so that (for example) the first 64 bits is a network address and the second 64 bits is the address of storage at that network address. This requires distributing the functionality of the MMU across various network elements, but is not especially novel, and from a software perspective is a special case of NUMA. (The special case lends itself to some clever scheduling based on the delay hints available in a further structured network address, especially if you generally organize things such that the XOR of two network addresses is a useful (if not perfect) delay metric from the perspective of an accessor).

This can even be done "in the small" on a non-networked host by allocating "network addresses" in the top 64 bits to local random access storage. You could look at this as a form of segmented memory (MULTICS style) or as an automatic handling of open(2)+mmap(2) based on (for example) a 64 bit encoding of a path name in the MSBs of the addresses. That is, dereferencing computer memory address 0xDEADBEEF00000001 automatically opens and mmaps a file corresponding to 0xDEADBEEF.

The opportunities to abstract away networked file systems without losing (or even while gaining) useful information about objects' characteristics (proximity, responsiveness, staleness) suggests that the address size used at the level of a primitive ISA that uses pseudo-flat addressing is mainly limited by the overhead of hauling around extra bytes per memory access. Pseudo-flat addressing can also in principle steal ideas from X86's various addressing models for dealing with addresses of different lengths.

Ultimately, the difficulty is in the directory problem. That does not go away even if you use radically different "addresses" for objects -- directories are already a pain if you use URLs/URIs for example, or if you use POSIX style filenames, or whatever, and the problem worsens when you have different "addresses" for the same logical object.

(Fun is when you have to figure out race conditions involving a structured set of bytes that is in a file shared out by AFP, SMB, NFS, and WebDAV, as well as being in use locally, with client software responsible for choosing the most appropriate available access method since there is no guarantee that any one of these methods will work for all clients at all times).

One possible approach to this is to insist that any reachable object is a persistent object, with a permanent universal name. If you have the permanent universal name, the object is either available to you or errors out. If you do not have the permanent universal name, you are out of luck unless you have a "locator" that points to it (or points to something that points to something that ... points to it). This is in some ways much easier if what is pointed to by a permanent universal name is immutable, and if most such objects are compositions of primitive PUNs, the most primitive and common of which ("well known PUNs") can be cached or recalculated locally.

[cf Church encoding, Morgensen-Scott encoding and normalization in the computer science sense]

Re:How Long?

[Anonymous Coward]

Hrm, I wonder what this HAL thing is ... must be a virus! I'd better remove it.

From NT4.0 onwards, the Hardware Abstraction Layer effectively became deprecated. MS started bypassing it for better performance. It was at that time that they decided NT didn't need to be portable, since x86 processors hadn't hit the performance dead-end that was predicted, no portability was no longer required.

Re:How Long?

[Anonymous Coward]

Apple with a fraction a of the software guys can keep their OS on two major different style of chips PowerPC, and Intel x86, along with 32bit and 64 bit versions of both Apple didn't decide - oh lets support 2x style of chips. They made a business decision for x86, because PowerPC wasn't suitable for their requirements. So stop trying to hail Apple as being clever & all that. Fanboi...

Re:How Long?

[turgid]

I have little doubt that Intel could force a change on servers and corporate desktops, and Linux, BSD and Solaris, as well as Apple, would be able to adjust within a very short period of time to run on it.

intel tried that with the over-hyped, over-engineered, over-priced and under-performing itanium.

The problem with changing architectures (as far as businesses are concerned) is backwards compatibility.

There is a lot of money invested in software. Even if the software can be recompiled on the new architecture, with little to no porting effort, it still has to be qualified. That means a lot of testing, which takes time and money.

x86 has been about for 30 years, and SPARC for 20, so they are likely to be about for a long time to come. Solaris/SPARC applications (binaries) from 15 years ago will still run on modern hardware on Solaris. I'm not sure that there are any current x86 platforms that can do that without some kind of emulation layer.

Re:How Long?

[negRo_slim]

and AMD uses a compatibility mode. I keep seeing refrences to this 'compatibility mode' me thinks you misunderstand what it does. http://findarticles.com/p/articles/mi_m0BRZ/is_6_23/ai_105884194/pg_2

Re:How Long?

[flnca]

It's the only major platform strongly tied to that CPU architecture.

Given that Windows NT (and variants) is currently available on 3-4 different hardware platforms (depending on how you're counting), has in the past been available on 3 more and has been internally ported to at least 2 more, I'm interested in why you think it is "strongly tied" to x86.

Windows NT 3.x and 4.x are not of common interest anymore; NT 5.0 (W2K), 5.1 (XP) and 6.0 (Vista) are tied IMO to the x86 platform, because 99.999999% of worldwide Windows sales are for that platform. With x86, I mean IA-32 (descendants of the 80286 processor, and compatibles), and I64 (which refers to the 64-bit extensions in IA-32), as well as AMD64 (which is also a 64-bit extension of IA-32). That the X-Box 360 runs on a PowerPC CPU is irrelevant, because it doesn't have a mainstream Windows kernel. Windows Component Edition (CE) is highly portable, but supports only a very small subset of the Windows API.

No, unless Microsoft sells Windows Vista for PowerPC processors and other mainstream CPUs that are widely used in the industry, I won't believe they're capable of writing a portable operating system.

Re:How Long?

[OrangeTide]

Microsoft has already shown that they can port Windows to non-x86, Alpha and IA64 were official releases but there has been some unreleased ports too.

Xbox360 is basically Windows (sort of) running on PowerPC.

Re:How Long?

[flnca]

Well then, where's Vista for PowerPC?

And have you ever looked into the manuals of I64 and AMD64 CPUs? What's the difference to IA-32?

Re:How Long?

[flnca]

Then we can retire x86. Surrree, your 64-bit CPUs are something different, not just a simple extension of the 32-bit model.

Re:How Long?

[anss123]

The internal instruction sets of x86 CPUs are likely to be very ugly with plenty of warts. This since Intel has full control over it, meaning they can work it exactly to their needs to get around odd scheduling constraints and special cases that may vary from CPU core revision to CPU core revision. The instructions are probably also horizontal (making them big and inefficient), since they'll never travel outside the CPU, with no support for trapping illegal instructions, privileged instructions and other iffities world exposed instruction sets need. Bottom line, real world exposure it a bad idea since the internal instruction set was never designed for it.

Re:How Long?

[drsmithy]

Windows NT 3.x and 4.x are not of common interest anymore; NT 5.0 (W2K), 5.1 (XP) and 6.0 (Vista) are tied IMO to the x86 platform, because 99.999999% of worldwide Windows sales are for that platform.

Your benchmarks for portability are both stupid and meaningless.

With x86, I mean IA-32 (descendants of the 80286 processor, and compatibles), and I64 (which refers to the 64-bit extensions in IA-32), as well as AMD64 (which is also a 64-bit extension of IA-32).

You forgot Itanium.

That the X-Box 360 runs on a PowerPC CPU is irrelevant, because it doesn't have a mainstream Windows kernel.

The XBox 360 runs a derivative of the NT kernel.

No, unless Microsoft sells Windows Vista for PowerPC processors and other mainstream CPUs that are widely used in the industry, I won't believe they're capable of writing a portable operating system.

They're already selling a portable OS right now. Windows NT is publicly available, at retail, for x86, x86-64 and ia64. An embedded derivative is running on a mass-market PPC-based games console.

The reason you can only buy NT for x86, x86-64, and ia64 is because there aren't any other mainstream hardware platforms it makes economic sense to release it on.

Re:How Long?

[DragonWriter]

As another example, the human brain has about 10^11 neurons. Each of those may be connected to 10^4 other neurons, so the total number of connections is about 10^15. That suggests that the total amount of RAM needed for direct, brute-force modeling of a human brain (assuming we knew enough to program such a model, which we don't, and had parallel processors that could run such a simulation, which we don't) might be about 10^15 bytes, which is a 50-bit address space.

Assuming, of course, that the brain could be adequately modelled as a network with a 1-byte weights for each connection as the only relevant state. Which seems rather unlikely.

Re:How Long?

[kestasjk]

The demise of the x86 general architecture will not begin until Windows goes out of fashion. It's the only major platform strongly tied to that CPU architecture. Windows isn't as tied to x86 as you might think, when Intel was getting behind it's Itanium processors they managed to get Microsoft to port Windows and most of their server software (ie SQL Server) across. Either they really thought Itanium would be huge, or it wasn't that much effort to port.

The main thing tying Windows to x86 are the applications for it, and games etc wouldn't do so well with a Rosetta-like layer to convert instruction set.

.NET's processor independent code may (and was probably intended to) decrease the reliance on x86 and allow future instruction set changes, but I don't think there's any rush to move from x86. It gets a lot of slack on /. but phenomenal success and unprecedented backwards compatibility trump arguments over elegance any day.

Re:How Long?

[kestasjk]

Actually Intel keeps trying(Itanium?) and AMD uses a compatibility mode.

The problem is as usual MSFT. which only runs on windows. yes I know a decade ago NT 4.0 did run on PowerPC, and even a couple of alpha chips. You realize Windows runs on Itanium, right? The reason no-one is moving across is because x86 is fine; it was 30 years ago and is now (which Intel deserve a lot of kudos for). It's just not worth the application incompatibility, this has nothing to do with Microsoft who will happily go to whatever hardware the consumers and developers are using.

Re:How Long?

[kestasjk]

(And yes I know there's a chicken and egg problem there, but Microsoft is ready to take the first step when Intel thinks it's justified, as with Itanium)

Re:How Long?

[Kjella]

y'know, in the future we'll look back on this time and laugh at how silly it was to say "16 exabytes should be enough for anyone" You know, I sort of doubt that... even with several monstrosities running at once, I haven't felt the urge to upgrade my RAM since I got 2GB. I did stick 4GB in there when I built a new machine, but it was just because it was cheap. A quick check shows that even with KDE + XP in VMware + browser + java apps +++ less then half is used for applications so it'd probably run just fine on 2GB as well and already 8GB (4x2GB) is cheap if you ask me. Hell, if I really wanted to splurge 16GB (4x4GB) is pricy but not entirely outragous. Sure there's some nice-to-haves but unless there's something revolutionary coming I don't see any large push for memory size at all.

It's not because of computer limits, but because of human limits - we don't hear much better than mp3, we don't see much better than digicams and HDTV, we don't multitask better than that it'll just end up in clutter if we try doing as much at once as the computer lets us. Sure there's things in science and such that'll never get enough, but if I was asked what I'd possibly need that for the closest I can think of would be NLE editing of (Ultra)HDTV, but even that doesn't come close to requiring even a TB. I think that's fairly close to the largest amount of information I could possibly manage to process at once.

Re:How Long?

[x2A]

"Well then, where's Vista for PowerPC?"

There's a difference between can-be-ported and has-been-ported. How many people would buy vista to install on a ppc? MS obviously don't believe it's enough to be worth creating a release for it.

Re:How Long?

[OrangeTide]

IA64 is not x86, it's Itanium, which is more like PA-RISC than x86. x86-64 != IA64

NT3.5 exists for MIPS officially. And NT3.5 for exists for PowerPC(devel-only) and Sparc(experimental)
NT4.0 exists for Alpha, which is not much like x86 (if you ever looked into the manuals).

Re:How Long?

[Anonymous Coward]

uh, there is Vista x86 and Vista x64, while yes, Vista x64 will run x86 programs, I think it emulates it or something. Similar to how XP x64 does.

Re:How Long?

[toddestan]

Apple has the OS running on ARM too. That makes three major ISAs.

If you want to count mobile versions, Windows runs on ARM too.

Re:How Long?

[edalytical]

I didn't know this was a pissing contest. However, Windows Mobile is a different OS than Windows proper. Apple's OS is the same OS that runs on all three.

Re:How Long?

[Directrix1]

I think we'll probably end up seeing a derivative of Android on there. Similar requirements and solution.

Re:How Long?

[flnca]

Your benchmarks for portability are both stupid and meaningless. They aren't meaningless because most companies developing software for Windows assume it's an x86-only platform. So far, Microsoft has not endorsed writing portable software for Windows. Most companies don't even know what's involved in developing portable software.

You forgot Itanium. Yes, that's news to me that there's Windows running on Itanium. I always thought Itanium was used only in UNIX servers.

The XBox 360 runs a derivative of the NT kernel. How derivative is it? Can I run MS Office on it?

They're already selling a portable OS right now. Windows NT is publicly available, at retail, for x86, x86-64 and ia64. You mean Windows Vista runs on Itanium CPUs? If that's true, that would be interesting.

The reason you can only buy NT for x86, x86-64, and ia64 is because there aren't any other mainstream hardware platforms it makes economic sense to release it on. People from the industry sector would strongly disagree. Millions of computers can't run Windows because their CPU isn't supported. Microsoft has been missing plenty of business opportunity right there. And of course leaves plenty of market to other OS vendors! :-)

Re:How Long?

[flnca]

Well, that's millions of Windows licenses wasted. For instance, in the so-called embedded market (where CPUs often have power near or equal to desktop machines), there's a need to run Win32 applications unmodified (with Windows CE costing too much in regard of development time etc.). And Microsoft is simply neglecting that market.

Re:How Long?

[flnca]

That's why I wrote "I64" (x86-64) not "IA-64". I wasn't sure if Windows exists for Itanium. If it does, then good.

NT 3.5 and 4.0 aren't sold anymore, so it doesn't matter for users of PowerPC hardware if there was a PPC version millenia ago.

Re:How Long?

[flnca]

That's all true, I guess. The CLR should produce faster code, however, they need to work on its performance.

Re:How Long?

[spandex_panda]

wine 1.0 is (almost) here! (well I guess so is DNF, but wtf is GNU Hurd?)

Re:How Long?

[Anonymous Coward]

maybe I am mistaken but I am quite sure Macs are tied to the x86 as much as windows is now...

Re:How Long?

[Johnno74]

I wouldn't bet MS is irrevocably tied to x86. The xbox 360 OS is based on the original xbox OS, which is a cut-down version of windows 2000.

So MS ported this to a completely new architecture (Xenon, which is PowerPc based) without too much trouble. .Net also runs on the 360 (xna) and the graphics API is based on DirectX.

If market forces indicated to MS that windows should run on other hardware, then they would make it so.

Re:How Long?

[Hal_Porter]

I don't know about MIPS or PowerPC, but the Alpha port of Windows NT could run X86 binaries. It used FX!32, a Dec written JIT translator.

Incidentally, I've heard that the HAL started losing compatibility after Windows NT4, and was pretty much tied to little-endian even so. At least, this is what a prior, highly-rated Slashdot post that I can't find right now claimed. Well, if he worked for Microsoft and thus actually knew he wouldn't be posting about it on slashdot.

Re:How Long?

[Hal_Porter]

Umm, no. Is that supposed to be some sort of insult?

Re:How Long?

[cmacb]

Nope but Vista only runs on x86. So X86 will remain around as long as it does.

A large part of the explanation for why I detest both companies. Entrenched in the past, they can only pretend to be advancing technology while in reality holding it back as much as they can get away with (similar phenomenon went on in Detroit).

Someone invent MoveOnFromIntelandMicrosoft.org and strip these companies of any respectability they have left please.

Re:How Long?

[Hal_Porter]

That's what Transmeta did, right? And FX!32 Dec's x86 to Alpha translator was trying to do the same thing. People have tried it, and the results aren't too impressive.

I think the real problem is that there isn't currently a non x86 server class chip which has superior performance even running native code. I guess if some sort of VLIW architecture managed that then we'd see people experiment with JITing x86 to it. But there's always the code size issue - x86 code is compact and you can fit more of it into the same size cache. Translating it in hardware doesn't really have much of a cost in terms of die size. And from a user perspective it's very convenient that you can run old binaries in all processor modes. FX!32 could only do 32 bit user mode stuff from what I can tell. NTVDM had a Insignia derived emulator for Dos and Win16 stuff. But emulating device drivers is probably impossible to do without massive stability issues.

A JITter is bad for caches too. Since you have to JIT basic blocks of code the JIT compiler keeps getting called so it 'pollutes' the cache. In a processor with native x86 support you can spend all your cache on x86 code, but in a Risc chip with a JITer you spend some on native code, which is bigger than the x86 equivalent and some on the JIT compiler itself. Which is not good for performance.

Re:How Long?

[OrangeTide]

Fair enough. although Intel likes to call it EM64T, not I64.

Vista is still a lot like NT4 internally, just like Linux 2.6 is like Linux 2.0 (and 1.2). I am assuming it would be relatively easy for Microsoft to release a version for a new architecture if they saw value in that. And a new architecture would have fewer variants and vendors, so it would really cut their testing time possibly resulting in a not unreasonable schedule to release a new port.

Of course a new fancy architecture that is worth porting to doesn't exist today.

Re:How Long?

[SendBot]

well, it was more my intent to be funny in reference to the "640k should be enough for anybody" quote.

But to be serious, that was 20 years ago and think of how much change will occur 20 years from now.

20 years ago: wow - 4 megs of ram is so much! I already have enough to have all my finances in spreadsheets and the text of so many books!

Let your imagination rub wild for a moment: What level of detail is hd video compared to an entire 3d environment with video textures? Consider data for tactile feedback and environmental effects like smell and climate. What if instead of an mp3 you have a music track with each instrument and effect independent so that you can emphasize what you want to hear, or even multiple vocal and instrument tracks so you don't get tired of hearing the same recording over and over?

Why have dumb AI, when you can have an aquarium program with realistic brain functions? Tap on the monitor and go "fishee fishee!" without the aquarium staff glaring at you.

Or y'know, do nuclear detonation experiments for the science fair.

What if instead of photos of your departed loved ones you have a holodeck experience you can cherish?

I could go on like this, but perhaps you get the idea by now.

Re:How Long?

[flnca]

Have you recently taken a look at the Windows SDK documentation? Since NT 4.0, the Windows API has gotten a couple thousand new API functions. (no joke! to say it with Luke Skywalker: "Look at the size of that thing!" ;-) )

That's perhaps why Windows versions for other platforms are so stripped down. It's simply not humanly possible to port all that platform dependent code. There are probably thousands of bugs related to portability issues in Windows. The problem would not exist, well, if they'd rewrite it to run on their CLR. Also, Microsoft loves to come up with new driver models in every Windows release that forces hardware vendors to rewrite their drivers for every Windows release. I've read a comment recently that said that the issue would be solved in Vista and forthcoming versions, but I'm not so sure about that, since they reputedly can't even stick to their own OOXML standard.

Re:How Long?

[drsmithy]

They aren't meaningless because most companies developing software for Windows assume it's an x86-only platform.

They're meaningless because they assess economic viability, not OS portability. That is to say, you're measuring the market, not the code.

Most people developing _anything_ assume it's an x86-only world because, practically speaking, it is. This is hardly a phenomenon unique to Windows, either. There are multitudes of "open source" applications that only work on x86 Linux.

So far, Microsoft has not endorsed writing portable software for Windows.

Nor does it need to. The onus for writing portable third-party applications is on the third parties, not Microsoft.

Most companies don't even know what's involved in developing portable software.

Which is, again, nothing to do with Microsoft. Most developers - regardless of platform - "don't even know what's involved in developing portable software." Why would they ?

Yes, that's news to me that there's Windows running on Itanium. I always thought Itanium was used only in UNIX servers.

While it's hardly surprising that it's "news" to you, Windows NT has been available on Itanium since 2001.

How derivative is it? Can I run MS Office on it?

No. No more than I can fire up OpenOffice on my Linux-running Fibre Channel switches.

You mean Windows Vista runs on Itanium CPUs? If that's true, that would be interesting.

Windows 2008 (which is little different from Vista, especially in the ways that matter here) is available for Itanium. You can even download an evaluation copy for free if you want.

People from the industry sector would strongly disagree. Millions of computers can't run Windows because their CPU isn't supported. Microsoft has been missing plenty of business opportunity right there. And of course leaves plenty of market to other OS vendors! :-)

Which hardware platforms do you think represent an untapped market for Windows ?

Re:How Long?

[Anonymous Coward]

Nice fork bomb.

Re:How Long?

[Urkki]

If you could directly simulate a human brain on a computer, it would mean immortality, the end of history, the transformation of the human race into something completely different. Nope. Well, not necessarily anyway. I could definitely be considered the next step in human evolution, but it's the classic "if apes evoleved into humans, why are there still apes" case. Even with computerized trans-human-AI minds, there would still be regular, biological humans. Billions and billions of them.

Unless, of course, the human-AI overlords would decide to get rid of the biological humans...

Re:How Long?

[peragrin]

your quite right, but the fact that apple pulled the switch off while keeping their customers happy and had in place a platform agnostic system(cocoa) that was easy to port quickly helped.

Apple switched processors and other than a new logo for universal binaries the end users couldn't tell the difference.

MSFT is having problems upgrade to EFI(only supported by 64 bit vista) from BIOS.

Re:How Long?

[kitgerrits]

*unzips*, Pees the following in the snow:
NetBSD even runs on toasters: http://www.netbsd.org/gallery/in-Action/

*zips up*

Any questions?

Re:How Long?

[kitgerrits]

It's wonderful that Windows will run on Itanium, Several Linuxes run on PPC (PS3!), and that NetBSD will run on anything that can count.

There's two other factors: Cost and availability.
Have you seen the price of an Itanium station? Those things were never meant to be used by consumers. Just like SPARC and PA-RISC.
Linux will run on a PS3, but it's embarrassingly slow, compared to a PC half the price.

For x86 you can not only find every conceivable type of gadget, but usually several, competing for lower price and higher quality. Practically all of them provide Windows drivers and some even provide Linux drivers.

Re:How Long?

[alan_dershowitz]

He claimed he did. Btw, the Xbox/Xbox360 doesn't use the Windows kernel HAL.

Re:How Long?

[Hal_Porter]

He claimed he did. Btw, the Xbox/Xbox360 doesn't use the Windows kernel HAL. The XBox used a "modified Windows 2000 kernel" according to Wikipedia.

Re:How Long?

[TwistedSpring]

I meant no offense by it. The books you cite are common degree texts.

I can't say I agree with your suggestion that the x86 ISA is simple. I would say that it's an extremely complex ISA that takes a lot of unnecessary pre-decode logic to hack it up into micro ops. If the ISA was simpler that pre-decode logic would not need to be so hefty (or could be scrapped entirely) and more of the transistor budget could be spent on L1 and register file size, as happens in better designed, modern ISAs.

Re:How Long?

[alan_dershowitz]

It uses a Windows 2000 kernel, but it doesn't use any of the rest of the Windows 2000 operating system. They implemented an Xbox OS on top of the Win2k kernel that has almost no hardware abstraction because they know what the hardware is going to be and they need the performance. This OS re-implements many Windows APIs so from a programming standpoint they are functionally similar, but it doesn't use the same HAL architecture/code that the desktop and server Windows uses. It mostly doesn't use one at all.

http://blogs.msdn.com/xboxteam/archive/2006/02/17/534421.aspx

Re:How Long?

[Hal_Porter]

That sounds like marketing fluff "we built it from the ground up with less layers of abstraction for gaming".

The kernel comes from Windows 2000.

http://www.windowsfordevices.com/news/NS3988467635.html

Since that kernel sits on the HAL I'd bet that is still there, especially as they probably had plans to move from x86 early on. You could compile the HAL into the kernel image though, and make the DirectX a very thin layer over the graphics driver.

But a games console could obviously lose most of the code in a desktop OS.

Re:How Long?

[OrangeTide]

Most of them aren't system calls though. Plus the volume of api is not as important as how porting-friendly the software architecture is. Did they use bus abstractions for the driver DDK? (yes), Are tasks, threads, processes and locking done through high-level abstractions? (yes). I think you get the picture.

Very little of it is platform dependent. And it's humanly possible to port even a very large amount of code to another architecture because if you consider that all these modern CPUs are 32-bit or 64-bit (not 16-bit, not 36-bit, etc) and have a lot of the same basic interfaces (PCI, USB, etc).

The core bit of NT VM is the hairy part. which can be done from scratch by 2-3 clever people in 3 months or so. (in my experience). There is little doubt in my mind, that Microsoft could support another platform in less than a year (ignoring cool features like "universal binaries" and emulation for legacy applications). Getting all the apps to work in the new environment, having them be endian agnostic, etc would take a whole lot of work though. But the base kernel and a couple core components (explorer) is likely still very portable.

Linux wasn't designed to be all that portable, a lot of the guts of it was very x86 centric (and still is somewhat). But it runs on plenty of things other than x86.

Re:How Long?

[toddestan]

Actually, the discussion was about how Windows was stuck on x86, hence the comment.

Also, just because Apple says it is doesn't make it so. OSX on the iPhone is not the same as OSX on their desktops, unless you want to use a broad enough definition that would also include Windows/Windows Mobile.

Re:How Long?

[edalytical]

Actually, the discussion was about how Windows was stuck on x86, hence the comment.

Fair enough.

Also, just because Apple says it is doesn't make it so. OSX on the iPhone is not the same as OSX on their desktops, unless you want to use a broad enough definition that would also include Windows/Windows Mobile.

But I can say with pretty decent confidence that "OS X" on the iPhone is running xnu with BSD userland stuff. Hence it's the same as "OS X" on the Mac.

Windows Mobile runs the WinCE kernel not WinNT. Those are distinctly different kernels AKAIK.

Given that information I don't understand your point. iPhone "OS X" vs Mac "OS X" is basically apples to apples, but Windows vs Windows Mobile is apples to oranges (forgive the pun).

Re:How Long?

[toddestan]

I guess the iPhone's OS is closer to OSX than the Windows Mobile to Windows. The iPhone is built upon Darwin and uses the Mach kernel, same as OSX, though you can download the Darwin for free, but most people don't consider that "OSX", so I what exactly constitutes OSX is a bit of a question here as the propriety stuff (the overlying user interface) is quite different from OSX on a Mac. Nevertheless, they do have a foundation for running things on ARM.

Windows Mobile, as you say, runs CE, which is a distant relative of Windows 9x which makes it different from the NT line of kernels. They both use the Win32 API, so in theory should be very similar in terms of developing on, in practice maybe not so much. Even so, it's enough to call it "Windows" in my book, though it would be wrong to say that some random smartphone "Runs Vista".

Interestingly, it seems that Apple has stopped saying that the "iPhone runs OSX" since the SDK came out and now just calls it "iPhone OS".

Please

[oldhack]

Kudos to Intel for their bus/marketing/eng savvy, but the x86 instruction set? Please.

Re:Please

[Deagol]

I'm troubled by your statement. I need to take a moment.

Backward integers forever!

[Anonymous Coward]

Buggy processors, flawed floating point, and backward integers. Better solutions have come and gone, always squashed by the INTEL 800 pound gorilla.

Yep, lots to be happy about. Long live mediocrity.

Re:Backward integers forever!

[Ant P.]

You can complain all you want about endianness, but unless you can convince people that the base-10 system they've been reading for centuries is written back to front that's the way it'll stay.

Its hard to believe ...

[veektor]

... that we've been using the same architecture for almost 60% of my life. More than 60% if you count the 8080. -K1LT

Re:Its hard to believe ...

[mrbluze]

... that we've been using the same architecture for almost 60% of my life. More than 60% if you count the 8080. -K1LT I agree. What impresses me is how, what I thought at the time were much better processor architectures, died a death, whereas clunky ol' x86 kept on going, warts and all.

Re:Its hard to believe ...

[Rhapsody Scarlet]

We've been using it for 100% of mine. The 80386 was still shiny and new when I was born.

See, this is one the reasons I come to Slashdot. Other discussion boards make me feel so old because I remember using my old 486DX2/66.

Re:Its hard to believe ...

[Simon Brooke]

We've been using it for 100% of mine. The 80386 was still shiny and new when I was born.

See, this is one the reasons I come to Slashdot. Other discussion boards make me feel so old because I remember using my old 486DX2/66.

Hah! The first machines I used professionally didn't even have a microprocessor... Have used 6502, 8080, Z80, H800, M68000, ARM, PowerPC, MIPS. Oh, and the odd x86.

Re:Its hard to believe ...

[jgarra23]

... that we've been using the same architecture for almost 60% of my life. More than 60% if you count the 8080. -K1LT I'm 29 so all of mine.

Re:Its hard to believe ...

[rubycodez]

you feel bad, we've been using extensions to the IBM System 360 architecture in mainframes all my life, it's as old as I am

Re:Its hard to believe ...

[ubrgeek]

Yeah, yeah. And you had to walk uphill in the snow both ways to load your punch cards... ;)

Re:Its hard to believe ...

[beowulf]

Amen to that. I remember in the long ago days of my undergrad CS assembler class (mid '80s) spending the first half of the semester working with the M68000 and thinking, huh, assembly isn't so bad. Then we switched to the 80286. Cue multiple brain explosions around the lab...

Re:Its hard to believe ...

[afidel]

No Alpha or SPARC?

Re:Its hard to believe ...

[Crazy Taco]

... that we've been using the same architecture for almost 60% of my life. More than 60% if you count the 8080. -K1LT

I can top that... we've been using it for about 125% of my lifetime :D.

Re:Its hard to believe ...

[Simon Brooke]

No Alpha or SPARC?

No Alpha. I'd forgotten the SPARC. I've got a scrap Alpha in the car just now, and I'm going to have a try at resurrecting it.

Re:Its hard to believe ...

[Anonymous Coward]

The thing that makes this statement funny to me is that my dad lived on a farm and there was a sizeable hill between his house and the school about a mile away, and was something like a hundred feet. So when it did snow, he literally had to walk uphill both ways... in the snow :P

Re:Its hard to believe ...

[PitaBred]

If you write ASM, things like ARM and Sparc and MIPS are great. It's easier and more efficient to use an expanded instruction set like x86 when making a compiler, though. I'm not saying x86 is perfect by any means. Dearth of registers, etc. But the "small, fast, simple" approach of other CPU's just doesn't scale except past mostly very specific algorithms.

Re:Its hard to believe ...

[x2A]

Really? I learnt it at a rather young age, and yes I guess it is said that we can learn languages better at earlier ages, but even so... what's really that complicated about it? I managed to hand code a preemptive multitasking protected mode kernel in x86 assembly, all self taught... so I'm at a bit of a loss understanding your post (and the others of that variant).

Happy Birthday

[Daver297]

Happy Birthday Big Guy

Re:Happy Birthday

[sconeu]

Ah, nostalgia.

I still have on my bookshelf, my "iAPX 86/88 User's Manual", dated August 1981, printed on onionskin.

Re:Happy Birthday

[Gundamdriver]

After learning Java and C, I want to learn some programming with assembly... :P

Re:Happy Birthday

[Anonymous Coward]

Anyone care to translate to English?

Re:Happy Birthday

[x2A]

Off the top of my head, the english language doesn't have instructions for getting the operating system to output a line of text to the console and then terminate execution.

Re:Happy Birthday

[mgblst]

push cs
pop ds
lea dx, message
int 21h
mov ax,4c00h
int 21h

much better!

I wish it would just die.

[Hankapobe]

Move on to something better. Backwards compatibility can too far some times.

Re:I wish it would just die.

[Anonymous Coward]

I wish for the same. X86 wasn't even an efficient ISA at its introduction. Today it's just sad in comparison to modern ISA's. Hell, it's even sad (and, actually, in several ways very inefficient) compared to other 25 year old ISA's like 680x0.

But, sure, happy birthday, you clumsy, inoptimal ISA you.

Re:I wish it would just die.

[quanticle]

But you see, the thing with standards is that the longer they live, the harder they are to kill. At 30 years old, the x86 ISA is damn near invincible now.

Re:I wish it would just die.

[Nullav]

So what better birthday present than a new friend (that will later kill and supplant it)?

Re:I wish it would just die.

[Anonymous Coward]

When the processor first came out I seem to remember writing an article criticising it for an arcane architecture and instruction set that would make it difficult to extend in a straightforward manner as technology developed.

Having set out to make backwards compatibility such a nightmare, it's a tribute to *something* that x86 is still around 30 years later and that it's delivering high performance in a consumer-oriented component. Probably the fact that to "move on" is harder than it seems - vested interests, established market relationships, additional engineering costs, existing knowledge base...

Re:I wish it would just die.

[Provocateur]

Would the CPUs/GPUs/whatever coming from nVidia be considered 'new' or merely more 'same old, same old'? extensions of the x86?

Re:I wish it would just die.

[Anonymous Coward]

+5: Troll
I can no longer participate in this forum. I have seen everything that it has to offer.

x86 did not succeed for technical reasons

[Anonymous Coward]

What a mishmash of zany grafted-on non-orthogonal instructions and registers the x86 is. For years its technology lagged Motorola's 68x00. x86 succeeded due to IBM and Microsoft selecting it. Anything will fly given enough propulsion. We can only imagine how much further ahead CPUs would be if not for the x86 monopoly.

Doing it right -- mostly

[HW_Hack]

I spent over 16 yrs with Intel as a HW engineer. I saw many good decisions and a lot of bad ones too. Same goes for opportunities taken and missed. But their focus on cpu development cannot be faulted - they stumbled a few times but always found their focus again.

The other big success is their constant work on making the entire system architecture better, and basically giving that work to the industry for free. PCI - USB - AGP - all directly driven by Intel.

Its a bizarro place to work but my time their was not wasted

Re:Doing it right -- mostly

[oblivionboy]

The other big success is their constant work on making the entire system architecture better, and basically giving that work to the industry for free.

While I'm sure thats how the script was repeated in Intel, suggesting great generosity ("And we give it away for free!"), what choice did they really have? IBM's whole Micro Channel Architecture fiasco showed what licensing did to adoption of new advances in system architecture and integration.

Re:Doing it right -- mostly

[Simonetta]

Hello,
    Congrats on working at Intel for 16 years. Might I suggest that you document this period of activity into a small book? It would be great for the historical record.

    Typing is a real pain. I suggest using the speech-to-text feature found buried in newer versions of MS Word or the IBM or Dragon speech programs. Train the system by reading a few chapters off the screen. Then sit back and talk about the Intel years, the projects, the personalities, the cubicals, the picnics, the parking lot, the haircuts, the water cooler stories, anything and everything. Don't worry about punctuation and paragraphing, which can be awkward when using speech-to-text systems. It's important to get a text file of recollections from the people who were there. Intel was 'ground zero' for the digital revolution that transformed the world in the last quarter of the 20th century. In fifty to a hundred years from now, people will want to know what it was really like.

Thank you.

Re:Doing it right -- mostly

[hvm2hvm]

What?

Re:Doing it right -- mostly

[owlstead]

The other advantage of speech recognition software is that it might notice the difference between "there" and "their". On the other hand, it might not recognize the word "bizarro".

In many ways it would make an interesting read.

Re:Doing it right -- mostly

[Christian Smith]

The other big success is their constant work on making the entire system architecture better, and basically giving that work to the industry for free. PCI - USB - AGP - all directly driven by Intel. Driven by Intel to match the other architectures out there. Ie. catchup.

Remember, around the time of PCI, SUN had already designed, implemented and released SBUS to standards committees. It was simpler than PCI, though not as fast in burst mode (that could have been revved), and not crippled with legacy crap like PCI was.

And as for their processors, they were mostly crap until they got proper competition in the form of AMD, Cyrix et. al. The i486 and Pentium were hopelessly outclassed by their contemporary RISC competitors. P6 (from which Core was derived) is the only decent CPU architecture they've done.

Re:Doing it right -- mostly

[Lost Race]

They had the choice not to bother with system architecture at all.

Re:Doing it right -- mostly

[Anonymous Coward]

Opera and Open Office also have this functionality.

Re:Doing it right -- mostly

[turgid]

P6 (from which Core was derived) is the only decent CPU architecture they've done.

i960 was pretty good, and they almost had a winner (but not quite) with the i860 (it was useless at context switches but great for maths).

Re:Doing it right -- mostly

[Anonymous Coward]

"Intel was 'ground zero' for the digital revolution that transformed the world in the last quarter of the 20th century."

  Intel got the technology from CTC (later known as DataPoint). Basically, CTC hired Intel to manufacture the processor for them, but Intel couldn't meet the deadline, so CTC kept their money. However Intel kept working on the chip and eventually finished it, releasing it as the Intel 8008.

A few tweaks, and...

[kabdib]

This is a case where just a couple of tweaks to the original x86 architecture might have had a dramatic impact on the industry.

The paragraph size of the 8086 was 16 bytes; that is, the segment registers were essentially multiplied by 16, giving an address range of 1MB, which resulted in extreme memory pressure (that 640K limit) starting in the mid 80s.

If the paragraph size had been 256 bytes, that would have resulted in a 24MB address space. We probably wouldn't have hit the wall for another several years. Companies such as VisiCorp might have succeeded at products like VisiOn, which were bending heaven and earth to cram their products into 640K, it would have been much easier to do graphics-oriented processing (death of Microsoft and Apple, anyone?). And so on.

Things might look profoundly different now, if only the 8086 had had four more address pins, and someone at Intel hadn't thought, "Well, 1MB is enough for anyone..."

Re:A few tweaks, and...

[fremen]

What you're really saying is that "if only the chip had been a little more expensive to produce things might have been different." Adding a few little tweaks to devices was a heck of a lot more expensive in the 80s than it is today. The reality is that had Intel done what you asked, the x86 might not have succeeded this long at all.

Re:A few tweaks, and...

[Gnavpot]

If the paragraph size had been 256 bytes, that would have resulted in a 24MB address space. We probably wouldn't have hit the wall for another several years. Companies such as VisiCorp might have succeeded at products like VisiOn, which were bending heaven and earth to cram their products into 640K, it would have been much easier to do graphics-oriented processing (death of Microsoft and Apple, anyone?). And so on.

But would the extra RAM have been affordable to typical users of these programs at that time?

I remember fighting for expensive upgrades from 4 to 8 MB RAM at my workplace back in the early 90's. At that time PCs had already been able to use more than 1 MB for some years. So the problem you are referring to must have been years earlier where an upgrade from 1 to 2MB might probably have been equally expensive.

Re:A few tweaks, and...

[deniable]

You've got that the wrong way around. The paragraph size was a result of register and address bus size. I doubt anyone would go out and say "Lets make assembly programmers use segments, they'll appreciate it." It was a way to make 16 bit registers handle a 20 bit address bus.

Anyway, you're giving me bad flash-backs to EMS and XMS and himem and other things best forgotten.

Re:A few tweaks, and...

[Paul Rose]

EXACTLY!

Registers were going to be 16 bit, period.

A 20 bit address was a result of pin count (and cost of extra transistors).

16 bit registers and 20 bit address yields a 16 byte paragraph. 2^(20-16)

The cost 4 more address pins and associated circuitry could have been a show stopper.

However, I suppose they could have used a 256 byte paragraph and shifted the segment registers by 8 bits and just discarded the upper 4 bits to get yield a 20 bit address. This would just mean that the 8086 would have had many segment aliases. They could then add more address pins on the next version. Some lazy programs would have exploited the aliases and have broken code (similar to what happened when early MAC programmers used high address bits for their own uses and were hurt by the updgrade to 68020).

As it was the 80286 was 16 bit, but added a protected mode where the 16 bit segment register acted like an index into a table of segment descriptors. Fairly decent upgrade path for 8086 code (but MSDOS compatible), but only 16 bit MS OS/2 (which never caught on) a few versions of Windows ever exploited it.

Re:A few tweaks, and...

[Alwin Henseler]

Adding a few little tweaks to devices was a heck of a lot more expensive in the 80s than it is today. The reality is that had Intel done what you asked, the x86 might not have succeeded this long at all. You mean those tweaks would have been succesful, then?

Re:A few tweaks, and...

[Shuh]

If the paragraph size had been 256 bytes, that would have resulted in a 24MB address space. We probably wouldn't have hit the wall for another several years. Companies such as VisiCorp might have succeeded at products like VisiOn, which were bending heaven and earth to cram their products into 640K, it would have been much easier to do graphics-oriented processing (death of Microsoft and Apple, anyone?).

This is one of the primary reasons Apple passed up x86 to go with Motorola's 68000-series processors. They had enough foresight to keep that 640K limit from applying to them. Additionally, there was no "real" or "extended" chunks of memory to twiddle.

Re:A few tweaks, and...

[Anonymous Coward]

Things might look profoundly different now if someone at IBM hadn't thought, "These Intel chips are way better than Moterola's"

Re:A few tweaks, and...

[PitaBred]

And that's why Apple is still running on Motorola chips, and is faster than any of the competing systems...

Re:A few tweaks, and...

[Anonymous Coward]

> (that 640K limit)

While the 8086 and 8088 had a 1 Mbyte limit of addressability the 640 Kb limit was in the IBM PC's use of that 1Mbyte. Other 8086 machines could use the full 1 Mbyte.

When the IBM PC was released it could be bought with 16Kb and was limited in the Model A to 256Kb maximum by the mother board. Typically it was competing with Apple ][ and CP/M machines that were limited to 64Kb or less.

Intel brought out the 80286 in 1982 that could access 16MByte. Many systems, such as Unix and Xenix, could move from 8086 and run quite happily on 80286. MS planned to use 80286 with later versions of MS-DOS 4.0 (the multitasking one based on 3.1 and not to be confused with the much later 4.01) and published guidelines that specified how compatible programs could be written. But it was too late, unlike Unix and others most MS-DOS programs abused the 8086 memory model and also bypassed the DOS and BIOS to bit-bang the hardware making the 80286 mode a no-go except as a faster 8086.

While Windows 2 (and 3) and OS/2 could run on 80286 and access 16 MByte these could only run a single 'DOS box' and it was too difficult to rewrite the DOS programs to bother with these, especially as RAM was so expensive that most machines still used 256 or 512 Kb.

Re:A few tweaks, and...

[steveha]

The paragraph size of the 8086 was 16 bytes; that is, the segment registers were essentially multiplied by 16, giving an address range of 1MB, which resulted in extreme memory pressure (that 640K limit) starting in the mid 80s.

0) 64KB was a lot of RAM back in those days. The 8086 could address an entire MB of RAM, which was huge back in those days. Don't forget that the original IBM PC was sold with 16KB of RAM as the lowest-cost option, and IIRC 64KB of RAM was the top option at launch. Years later, in 1984, Apple introduced the Mac with 128K, and later sold it with an amazing 512K (the "Fat Mac"). There is no way that, in 1980, 1MB of address space seemed small.

1) The real reason for the 640KB limit in DOS was that the IBM PC had a poorly designed BIOS. See, you were supposed to use BIOS services for things like writing to the screen, but the original BIOS made you write one character at a time, issuing one interrupt per character, which was just insane. So everyone started just writing strings to the display buffer directly; so there were a bunch of programs that would break if the display buffer was moved away from the 640K address. Had the BIOS offered a service you could call that would return the address of the display buffer, people could have written portable yet fast DOS programs, and people could have had something like 800K or more of contiguous address space.

If the paragraph size had been 256 bytes, that would have resulted in a 24MB address space.

And that would mean four extra pins on the address bus, a larger (more pins) Dual Inline Package for the chip, extra support hardware, extra address lines on the motherboards... everything more expensive, at a time when everything was really expensive anyway.

Had Intel made the x86 a 20-bit address space part, the extra cost might have made the x86 lose out to the Motorola 68000, which had 32-bit address registers and 20 address lines to the chip. I've always preferred the 68K to the x86 anyway (so I would regard that as a win for the world) but my point is that Intel wasn't wrong to ship the x86 as they did.

Things might look profoundly different now, if only the 8086 had had four more address pins, and someone at Intel hadn't thought, "Well, 1MB is enough for anyone..."

No one imagined the long run the 8086 would have. They were more likely thinking "1MB is more than enough for this product", not "1MB is enough for everyone forever."

steveha

Re:A few tweaks, and...

[Stephen Ma]

I don't understand. Why would a 256-byte per paragraph chip have been any more expensive to produce than a 16-byte per paragraph chip?

The first few generations of the slightly bigger architecture could simply drop the upper 4 bits of the linear address, so you would only have 20 bits of address to handle, just as with the actual 8086. You would be feeding the segment number to different bits of the address adder, but that would not cost anything.

Later generations of the chip could handle the full 24-bit address space, and we would not have needed to go through all that expanded/extended memory pain.

If I were the x86 designer, I would not have used paragraphs in the first place. But if I were forced to use paragraphs, I would have gone with kabdib's suggestion: a 256-byte paragraph would have been vastly better.

Re:A few tweaks, and...

[x2A]

"Some lazy programs would have exploited the aliases and have broken code"

Which is why we still need to enable the A20 line on x86 processors when using >1MB RAM, as the very high end of the 1MB address space did(/does) alias the bottom end.

Re:A few tweaks, and...

[toddestan]

Actually, it wasn't really a lack of foresight on IBM's part. IBM wanted to use the 68000 for the IBM PC too, except that at the time the 68000 was new and Motorola couldn't promise the quantities needed. Since IBM wanted to get something out to the market as quickly as possible, they went with x86 instead, and the rest is history.

Re:A few tweaks, and...

[Anonymous Coward]

Memory was EXTREMELY expensive back then (well, compared to today...).

I remember buying 18 DIP memory chips to take a 80286 system from 512KB to 1MB of RAM. The cost per chip was $12.50 back in ~1988. Which put the price per MB of RAM back then at around $450.

A few years later (about the time that the 80386 hit production), I took an old 80286 system, dug up enough ISA add-in memory cards from the office boneyard to get up to around 2-3MB and installed OS/2 1.3 on it. Which was an interesting exercise in patience.

Re:A few tweaks, and...

[Shuh]

Add to that the fact that IBM didn't mind hobbling their microcomputer with the x86 architecture. It was in their best interest at that time because they were still making lots of money on minicomputers and mainframes. A clean microcomputer architecture that was both efficient and easy-to-extend would only grow faster and eat their main business-sales that much quicker.

In any event, they lost control of the PC platform when the clones entered the market. And ironically, cloning is what helped pump enough money into the market to encourage Intel to patch up the x86's deficiencies.

Re:A few tweaks, and...

[QuietObserver]

Actually, the 68000 had 23 address lines, not 20, and they were numbered A1-A23, since all memory calls had to be 16 bit. This allowed for a 16 MB address limit instead of only 1 MB. Just wanted to clarify that point.

Re:A few tweaks, and...

[steveha]

Er, yes. My mistake.

I also messed up: the 8086 was made with a 20-pin address bus. I meant to say "If the 8086 had been made with a 24-pin address bus..."

The 8086 could address 1MB, and you need 20 address lines to do that.

Sorry for the mixup. The main points of what I was saying stand unchanged, though.

I just double-checked with a Google search, and the 68000 did indeed have 23 address lines: it used 24-bit addresses, but it only fetched word data (two bytes at a time) so there was no need for an address line to specify the least significant bit (because it was always 0).

steveha

Re:A few tweaks, and...

[QuietObserver]

Always happy to help people discover and correct their factual mistakes (which I think helps everyone).

Itanium sank

[gilesjuk]

Lets not forget the wonderful Itanium processor which was supposed to replace X86 and be the next gen 64-bit king.

How could Intel have got it so wrong? as Linus said "they threw out all of the good bits of X86".

It's good to see however that Intel have now managed to product decent processors now the GHz wars are over. In fact it's been as much about who can produce the lowest power CPU. AMD seem to just have the edge.

Re:Itanium sank

[Anonymous Coward]

Itaniums were great processors. I have a bank of surplus ones installed in my oven as a replacement heating element.

Re:Itanium sank

[WMD_88]

My theory is that Itanium was secretly never created to replace x86; rather, it was designed to kill of all competitors to x86. Think about it: Intel managed to convince the vendors of several architectures (PA-RISC, Alpha come to mind) that IA-64 was the future. They proceeded to jump on Itanium and abandon the others. When Itanium failed, those companies (along with the hope of reviving the other arch's) went with it, or jumped to x86 to stay in business. Ta-da! x86 is alone and dominant in the very places IA-64 was designed for. Intel 1, CPU tech 0.

Re:Itanium sank

[argent]

How could Intel have got it so wrong?

That's what they do best. Getting it wrong.

x86 segments (we'll make it work like Pascal). Until they gave up on the 64k segments it was excruciating.
iApx432 ... the ultimate CISC (the terminal CISC)
i860 ... The compilers will make it work (they didn't)
IA64 ... It's not really VLIW! We'll call it EPIC! The compiler's will make it work! Honest!

Re:Itanium sank

[Hal_Porter]

Lets not forget the wonderful Itanium processor which was supposed to replace X86 and be the next gen 64-bit king.

How could Intel have got it so wrong? as Linus said "they threw out all of the good bits of X86".

It's good to see however that Intel have now managed to product decent processors now the GHz wars are over. In fact it's been as much about who can produce the lowest power CPU. AMD seem to just have the edge. Not just Itanium. All the x86 alternatives have sunk over the years. Mips, Alpha, PPC. x86 was originally a hack on 8080, designed to last for a few years. All the others had visions of 25 year lifetimes. But the odd thing is that a hack will be cheaper and reach the market faster. An architecture designed to last for 25 years by definition must include features which are baggage when it is released. x86, USB, Dos and Windows show that it's better to optimize something for when it is released. Sure doing this will leave a few holes. But if it succeeds you have the money to fix them. As limited human engineers this seems inelegant. But that's how evolution works.

Maybe having vision is overrated. Evolution has no vision it just hacks stuff blindly. But it designed your brain. Conscious engineers planning for the long term can't do that.

Re:Itanium sank

[putaro]

x86 succeeded for exactly one reason - volume. If IBM had chosen the 68K over the x86 we'd be using that today.

Back in the 80's it was a lot cheaper to develop a processor. They were considerably simpler and slower. The reason there were so many processor architectures around back them was that it was feasible for a small team to develop a processor from scratch. It was even possible for a small team to build, out of discrete components, a processor that was (significantly) faster than a fully integrated microprocessor, e.g. the Cray-1.

As the semiconductor processes improved and more, faster, transistors could get squeezed onto a chip, the complexity and the speed of microprocessors increased. Where you're at today is that it takes a billion dollar fab and a huge design team to create a competitive microprocessor. x86 has succeeded because there is such a torrent of money flowing into Intel from x86 sales that it is able to build those fabs and fund those design teams.

PowerPC, for example, was a much smaller effort than Intel back in the mid-90's. PowerPC was able, for a short time, to significantly outperform Intel and remained fairly competitive for quite a while even though the design team was much smaller and the semiconductor process was not as sophisticated as Intel's. The reason for that was that the architecture was much better designed than Intel, making it easier to get more performance for fewer $$. Eventually, however, the huge amount of $$ going into x86 allowed Intel to pull ahead.

Re:Itanium sank

[Anonymous Coward]

Actually, Itanium was more of a bid to remove AMD from the playing field than anything. The only reason that AMD can still (somewhat) compete with Intel is because they were awarded free licensing of the x86 architecture from Intel in a lawsuit. This means that AMD has access to ALL Intel patents that are related to x86 - Itanium would completely negate that, effectively shutting AMD out completely (they don't have the money or legal ability to reverse engineer the EPIC architecture).
Intel probably knew that the move to 64-bit computing was needed, so they had their chance to completely negate the x86 patent deal they are legally bound to. What a perfect legal way to destroy a competitor?
Unfortunately for Intel, EPIC turned out to be way expensive and no one ever really jumped on board with it. The main reasons EPIC died was really because it wasn't x86. There just wasn't incentive to swtich to a completely new architecture, especially given the paltry performance gains achieved with Itanium - Itanium processors didn't deliver the performance increase Intel was hoping for until it was already dead (and even then they were modest). This had nothing to do with Microsoft, however, as Windows Server (can't remember exactly which versions) had Itanium support.

As a side note, I want to remind people that Windows is not the anchor to x86. Microsoft HAS been willing to create Windows with support for other architectures (like EPIC and x86-64, Windows CE has ARM support I think), the problem is cost. There is a lot of risk in developing a non-x86 variant of Windows and costs a lot of man-hours when there is no guarantee of any payoff. If Microsoft wanted to run themselves into the ground, going and making Windows for every architecture that sold itself on being "the next best thing" (example: EPIC) would probably be a pretty good way.

Re:Itanium sank

[geekoid]

Yes, that's much better then being the processor everybody needs to upgrade top~

Stop looking for patterns in noise.

Re:Itanium sank

[afidel]

No, Itanium was HP's way of getting Intel to absorb a large part of the cost of their Compaq/DEC acquisition. They needed a processor to move all of the legacy codebases to and x86 chips just wouldn't cut it for something like the NonStop line and maintaining their own chip division was a losing proposition so they convinced Intel to make them their next great CPU. Of course along came AMD with x64 and filled the 64 bit niche at a lower cost and better legacy code performance so the market for IA-64 went away other than HP and some supercomputer vendors.

Re:Itanium sank

[afidel]

The reason PPC was able to beat x86 for a time was that around that time the x86 architecture was moving to being an ISA with the actual code done by a RISCy back end. The decode logic at that time was a significant percentage of the die space available, as process improvements came along that logic remained fairly static as far as total resource usage but that quickly became a smaller and smaller percentage of the available resources and so relative performance went up as the amount of the chip available for useful work rose. Today the more compact instruction density of a CISC front end helps increase cache utilization and thus better hide the huge penalty for accessing main RAM.

Re:Itanium sank

[ichigo 2.0]

Man, it's really confusing to see that tilde after things you write, it always makes me think you are singing.

Doesn't sarcasm lose its meaning when it has to be explained?

Re:Itanium sank

[anss123]

The PPC CPUs did a bit better in the 94-96 area but even back then the PPC benchmarks wasn't all that impressive (comparing fastest to fastest, not fastest to mid range like many comparisons did).

During the same period we got the Nx586 ('94), Cyrix ('95), and K5 ('96); all by design teams that made PPC's look big. (Useless trivia: The Cyrix is now found in the OLPC by the name 'geode' and the Nx586 was bought and reworked into the AMD K6.)

I think Motorola would have been better served by staying with the 68K arch instead of messing with 88K and, later, PPC. They would have been almost as fast, and exactly what their customers wanted instead of a promise they never managed to deliver (being a huge performance delta on x86).

Re:Itanium sank

[x2A]

iow, "I'm gonna go make my own processor! With blackjack, and hookers!"

Overcoming Limitations

[steve_thatguy]

Kinda makes you wonder how different things might be or how much farther things might've come had a better architecture become the de facto standard of commodity hardware. I've heard it said that most of the processing of x86 architectures goes to breaking down complex instructions to two or three smaller instructions. That's a lot of overhead over time. Even if programmers broke down the instructions themselves so that they were only using basically a RISC-subset of the x86 instructions, there's all that hardware that still has to be there for legacy and to preserve compatibility with the standard. But I'm not a chip engineer, so my understanding may be fundamentally flawed somehow.

Re:Overcoming Limitations

[Urkki]

What may have been a limitation some time ago might start to be an advantage. I'm under the impression that there's already more than enough transistors to go around per processor, and there's nothing *special* that can be done with them, so it's just cramming more cores and more cache into a single chip. So parsing, splitting and parallelizing complex instructions at the processor may not be very costly after all. OTOH I bet it does reduce the memory bandwidth needed, which definitely is an advantage.

Re:Overcoming Limitations

[Hal_Porter]

Kinda makes you wonder how different things might be or how much farther things might've come had a better architecture become the de facto standard of commodity hardware.

I've heard it said that most of the processing of x86 architectures goes to breaking down complex instructions to two or three smaller instructions. That's a lot of overhead over time. Even if programmers broke down the instructions themselves so that they were only using basically a RISC-subset of the x86 instructions, there's all that hardware that still has to be there for legacy and to preserve compatibility with the standard.

But I'm not a chip engineer, so my understanding may be fundamentally flawed somehow. I think the important thing to remember is that total chip transistor counts - mostly used for caches - have inflated very rapidly due to Moores Law. And legacy baggage has grown more slowly. So the x86 compatibility overhead in a modern x86 compatible chip is lower than it was in a 486 for example. Meanwhile the cost of not being x86 compatible has stayed the same. Arm cores are much smaller than x86 for example but most PC like devices still use x86 because most applications and OSs are distributed as x86 code.

Re:Overcoming Limitations

[FromellaSlob]

I've heard it said that most of the processing of x86 architectures goes to breaking down complex instructions to two or three smaller instructions. That's a lot of overhead over time. You heard wrong, basically.

Re:Overcoming Limitations

[Chaset]

I second the sentiment. Although in modern desktop proc. implementations, the decode overhead is smaller and smaller portion of the overall die size, it still took time for some engineers to work on those pieces that would not have otherwise been necessary. That, along with all of the funny games to have more than 4 registers (but still trick the software into thinking there's only 4), the anachronistic x87 floating point stack, etc. all require effort from some portion of Intel engineers to drag along in each generation of the design.

As pointed out elsewhere, it's quite telling that the PowerPC alliance, whose desktop processor design effort in terms of people and $$ were dwarfed by Intel's, kept up a pretty good game for a decade or so of being competitive (and being better in some cases.)

Re:Overcoming Limitations

[noidentity]

OTOH I bet it does reduce the memory bandwidth needed, which definitely is an advantage.

I've compared some machine code sizes for some of my code and the x86 never comes out noticeably smaller (it's sometimes biggger). RISC architectures have more registers, and usually have three-operand instructions (a = b op c) rather than two-operand instructions like the x86 (a = a op b). Often a calculation using some values needs to preserve the original values, so the three-operand instruction does the "copy" for free, while x86 needs an extra move instruction. X86's LEA instruction is an exception, and compilers often use this as a generalized three-operand a = (b shift) + c instruction to avoid modifying b and c. The style the code is written can have an effect. Often I see CPU emulators (what I write a lot of) written in a way that prevents a compiler from caching values in registers; this style tends to do better on x86 where one doesn't need explicit loads and stores, like on RISC. If one codes in a way that the compiler can prove that no aliasing occurs (mostly by having the programmer use local variables liberally), then it can easily keep most things in registers, even across large loops.

Re:Overcoming Limitations

[afidel]

The legacy baggage wasn't there for the 486, there wasn't a decode to micro-op stage until the Pentium.

Re:Overcoming Limitations

[Hal_Porter]

Compared to a Risc chip an x86 compatible always has some overhead. On the 486 there was a big microcode Rom. On modern chips there is the "decode to uops" logic in the pipeline.

My point is that back in the 486 days the microcode Rom took up significant die area. But in a modern chip the whole core takes up a tiny percentage of the die - if you look at a picture it is mostly cache. So you can see that the price for being x86 compatible has dropped to the point where it is negligable.

Re:Overcoming Limitations

[Urkki]

Looking into the future, I see a time for x86, where there will be no practical performance difference between some memory accesses (most importantly local variables in the stack) and accessing registers. At that point, stack will essentially become a huge register bank, and any register disadvantage of x86 should be mostly history.

Perhaps that time is already here? I don't know the current state of the art.

And yeah, LEA was a cool instruction, I still remember learning it's existence, and how it was so nice for optimizing multiplicatons compactly (IIRC, this was in 386, which still had rather slow MUL instruction).

Re:Overcoming Limitations

[Christian Smith]

OTOH I bet it does reduce the memory bandwidth needed, which definitely is an advantage. Until the lack of registers causes spills to/from memory. Whoops.

Plucking figures form memory, x86 has an average instruction length of ~3.1 bytes for running code, whereas as RISC is generally 4 bytes. So, for a function that is 24 instructions long:
- x86 = ~71 bytes
- RISC = 96 bytes

Assuming the data IO overhead is the same, the x86 processor will be better off until it spills 3 registers to/from memory (3 out and 3 in), at which point it is losing out due to increased registermemory bandwidth. RISC does a much better job of keeping variables in registers.

This is for a short subroutine, which may be a simple "if this condition return this", but may also be a more complex iterative loop, which are common.

As the functions get bigger, more complex and/or loop more, so the gains from having register variables increase.

Not to mention that RISC can often perform the same functions in less instructions, as less register housekeeping is required. For the same reasons, Thumb and MIPS16 don't double code density of their respective architectures. There is just more overhead when working with limited registers.

1978??

[Adeptus_Luminati]

I don't recall 8086's hitting computer stores until like 1988 or so. What was Intel doing with these things for 10 years?

Re:1978??

[Ctrl-Z]

Are you kidding? The 8086 was the processor used in the IBM 5150, also known as the IBM PC, introduced in 1981.

Re:1978??

[Rhapsody Scarlet]

1988? Where the hell do you live? In 1988, the 8086/8088, 80186, and 80286 had already been on the market for years. The 80386 was the CPU to have and the 80486 was only a year away.

Re:1978??

[kabdib]

8088 (an 8086 with an 8-bit bus) at 8Mhz, and a graphics card architecture that was absolutely miserable, like stuffing pixels through a straw.

Oh, we suffered back then, believe me... :-)

Re:1978??

[Cro Magnon]

Interesting. I got my first PC, an 8088, in 1986. And I'm pretty sure the 286 was out by then.

Re:1978??

[Vectronic]

My first assumption, was tha it was too expensive for average use... but, after some investigating, I foudn that wrong (In my opinion)

June 1979, Intel introduces the 4.77-MHz 8086 microprocessor. It uses 16-bit registers, a 16-bit data bus, and 29,000 transistors, using 3-micron technology. Price is US$360. It can access 1 MB of memory. Speed is 0.33 MIPS. Not from '78, but the first price I could find... so maybe you are thinking of the 80386, released in '87, not just the 8086...

Re:1978??

[squiggleslash]

The 8086 predates the 8088, which was more popular and eclipsed it largely because IBM picked the latter for the original IBM PC. The 8088 is a modified 8086 that talks to the outside world using bytes rather than 16 bit words. It's otherwise completely identical.

PC manufacturers started switching over to the 8086 from around 1986 onwards (the Amstrad PC1512 was one example, dating to 1986) because of the slight performance improvement it offered without being as expensive as the 80286. For real-mode applications, and 8086s running at the same speed as the 80286, there was barely any performance difference between the two chips.

The old joke at the time was that the 8088 was being phased out in 1986-1988 because the '88 in 8088 was the expiry date...

Re:1978??

[jnik]

4.77 MHz, actually. Why, I have no idea...maybe they had a bunch of crystals at that frequency lying around?

Re:1978??

[Anonymous Coward]

I don't have the exact numbers. But it was so they could use a single crystal to generate the CPU clock and the "colorburst" frequency needed to the CGA card by using 2 different dividers.

Re:1978??

[Anonymous Coward]

"inconvenienced"

Re:1978??

[pezezin]

14.31818 MHz was used as the master frequency of NTSC sets, so those crystals were fairly common and cheap. Dividing it by 3 gives 4.77 MHz; other common dividers were 2, giving 7.15 MHz (as used in the Amiga and Atari ST), and 4, giving 3.58 MHz (used in lots of 8 bits computers).

Happy 29.9999999876547542

[Shadow Wrought]

Signed,
your great-great-great grandson,
Pentium

Happy Birthday to ya

[mgblst]

happy birthday, Happy birthday to ya.

(You can thank TimeWarnerAol for the fact that we can't sing the usual happy Birthday song, without paying $30,000 is fees).

Happy Birthday

[marto]

.model small .stack .data
message db "Happy Birthday!", "$" .code
main proc
      mov ax,seg message
      mov ds,ax
      mov ah,09
      lea dx,message
      int 21h
      mov ax,4c00h
      int 21h
main endp
end main

Legendary?

[Anonymous Coward]

Everything the x86 series did, someone else did first on some other processor (68k, Sparc, MIPS, and PPC, to name a few), and usually better, because they didn't have the handicap of backward compatibility.

But I guess we have the Pentium 4 to thank for conditioning the masses to think that clock speed equals performance to the exclusion of all else, and that it's okay for a CPU to burn 100-150 watts all by itself.

Re:Legendary?

[bhtooefr]

What about CISC-to-RISC translation?

I do believe that was first done by an x86 CPU, the NexGen Nx586 (the predecessor to the AMD K6...)

Re:Legendary?

[Waffle Iron]

Everything the x86 series did, someone else did first on some other processor (68k, Sparc, MIPS, and PPC, to name a few), and usually better, because they didn't have the handicap of backward compatibility.

Nevertheless, ever since the Alpha started faltering in the late 1990s, x86 processors have usually been the fastest or almost the fastest microprocessors available on the market at any given time, while being the most cost effective by a wide margin. At the end of the day, that's all that matters. (That, plus the fact that the backward compatibility "baggage" enables people to actually run the software they have.)

Re:Legendary?

[TheRaven64]

IBM's POWER series have been faster than x86 for much of that period but, like Alpha, they've lacked a lot in terms of performance per dollar due to their much smaller volumes. ARM chips have lead in terms of performance per Watt and performance per dollar, but have lacked in terms of raw performance.

Re:Legendary?

[PitaBred]

The thing is, with Alpha and POWER, they're very tuned to only certain jobs. They're very dependent on a very good compiler. An x86 CPU is much more forgiving about compiler architecture, which makes it much more widely acceptable because it's more tolerant of imperfect/inelegant software.

Re:Legendary?

[luzr]

CISC-to-RISC translation is mostly PR term. uops executed by OOO x86 cores are quite unsimilar to RISC opcodes - unless you have RISC consuming 100+ bits per single intruction..

Ah, fresh air!

[Icarium]

Someone advocating better hardware over more efficient code? Heresy I say!

Re:Ah, fresh air!

[Bryansix]

No you have it all wrong. He is advocating both better hardware and better code. The point is Windows is bloated especially Vista. If the hardware had been capable earlier then a GUI based OS could have been born sooner and maybe from a real innovator instead of MS.

Intel has always been a P.O.S.

[waldo2020]

Motorola always had better product, just worse marketing.. If IBM had chosen the 68K in their instruments machine, instead of the 8086/8085 from the Displaywriters, we would have saved ourselves from 3 decades of segmented address space, half a dozen memory models and non-orthogonal cpu architecture.

Re:Intel has always been a P.O.S.

[divided421]

You are absolutely correct. It amazes me how large of a market x86 commands with the undisputed worst instruction set design. Even x86 processors know their limitations and merely translate the instructions into more RISC-like 'micro-ops' (as intel calls them) for quick and efficient execution. Lucky for us, this translation 'baggage' only occupies, what, 10% of total chip design now? Had several industry giants competed on perfecting a PowerPC-based design with the same amount of funding as x86 has received, we would be years ahead of where we are now.

Re:Intel has always been a P.O.S.

[jalet]

You expressed politely and in a few words what I'm thinking for twenty years and didn't dare to write for fear of being REALLY FUCKING IMPOLITE ABOUT THE x86 !!!

Thanks a lot.

Re: Intel has always been a P.O.S.

[FurtiveGlancer]

You forgot the unintuitive (until made standard through pervasiveness), inverted reference scheme. Should one have LSB or MSB first? IMHO, Motorola got that one right as well.

Re:Intel has always been a P.O.S.

[vivin]

Very true. I started learning assembly on the Motorola 6811, then the 6800. My final semester at college, I took a graduate course where we wrote a small OS for the Motorola 68k. The 68k was a delight to code for. Beautifully orthogonal and intuitive. The Motorola instruction set was what really got me into assembly. I tried many times to write assembly for the x86, but I simply couldn't get around the ugliness, the endianness (backwards for me), and the reversed format for source and destination... and don't even talk about those ugly segmented registers. Ugh.

Re:Intel has always been a P.O.S.

[Anonymous Coward]

Motorola always had better product, just worse marketing.. If IBM had chosen the 68K in their instruments machine, instead of the 8086/8085 from the Displaywriters, we would have saved ourselves from 3 decades of segmented address space, half a dozen memory models and non-orthogonal cpu architecture.

Hear hear!

The x86 is a kludge on top of a hack on top of a kruft on top of a design that was cool in 1971. The only reason it's popular, is because it's popular.

Feh.

Re:Intel has always been a P.O.S.

[the_humeister]

You forgot more expensive. IBM chose the Intel chip precisely because it was less expensive for what they were trying to make.

Re:Intel has always been a P.O.S.

[waldo2020]

Indeed a kludge! The 8086 was touted as a CPU that would let you recycle your vast amounts of 8080 code - which never really happened. The 8080 of course was a hack on the 8008, and Intel claimed you could easily cross assemble 8008 code to 8080. Well, push it back to 4040, 4004 and thus we have ...ahem code compatibility in Pentium4 with 4004?

Re:Intel has always been a P.O.S.

[Pope]

But would the push for Power/PPC have happened, and would the G4/AltiVec debacle still have happened? Makes one wonder.

Re:Intel has always been a P.O.S.

[cleatsupkeep]

You have to be nice to it, it's its birthday :-).

Re:Intel has always been a P.O.S.

[jalet]

Where are mod points when you need them ???

You're right, I'm sorry.

Re:Intel has always been a P.O.S.

[MtViewGuy]

But yet, we overcame those limitations and today's x86-compatible CPU's easily support many gigabytes of RAM in true flat memory mode, with the only limitation being the motherboard itself. Indeed, Windows 2000, XP and Vista, the current MacOS X version, and even the latest distributions of Linux all take advantage of the flat memory mode that has been available since the advent of the 80386 CPU in 1986 (now in 64-bit flat memory mode).

Happy Happy Birthday

[triffid_98]

Happy birthday my Intel overlords, and a pox on whomever designed that ugly memory map.

Intel made some horrible design decisions.

[Futurepower(R)]

Before the 8086 was released, I knew a V.P. of Technology who was extremely excited about it. Every time I saw him, he would tell me the date of release, and how much he was waiting for that date.

On that day, he was very sad. Intel made some horrible design decisions. We've had to live with them every since. Starting with the fact that assembly language programming for the X86 architecture is really annoying.

makes you wonder ..

[rs232]

Makes you wonder why they didn't fix the MMU issues while they went about evoluting .. :)

What other discussion boards?

[Futurepower(R)]

What other discussion boards?

Re:What other discussion boards?

[conureman]

Yeah, I keep hearing about those, but I haven't got time to google EVERYTHING.

Re:What other discussion boards?

[Anonymous Coward]

google returns 885,000,000 hits for EVERYTHING. Good luck and hope you have a lot of time on your hands.

Fond memories of working with the 8086

[pw1972]

Back in college we learned Assembly on the VAX which was a dream to program Assembly on with it's 16 registers. Then we moved on to a microprocessor class where we had to program the 8086 and to our frustration were limited to it's 4 registers. I think we also came to the conclusion that those chips ran on smoke. Whenever you let the smoke out of them, they stopped working.

The scary thing is

[wiredog]

I was able to follow that, and it's been decades since I had to use x86 assembler.

Re:The scary thing is

[root_42]

Yeah, but can you do without the syntactic sugar? :) E.g. without the proc etc. I remember writing small assembler programs under DOS using the debug command, that could produce .com files.

Die already !

[DarkDust]

Happy birthday and long live, x86.

Oh my god, no ! Die already ! The design is bad, the instruction set is dumb, too much legacy stuff from 1978 still around and making CPUs costly, too complex and slow. Anyone who's written assembler code for x86 and other 32-bit CPUs will surely agree that the x86 is just ugly.

Even Intel didn't want it to live that long. The 8086 was hack, a beefed up 8085 (8-bit, a better 8080) and they wanted to replace it with a better design, but iAPX 432 turned out to be a desaster.

The attempts to improve the design with 80286 and 80386 were not very successful... they merely did the same shit to the 8086 that the 8086 already did to the 8085: double the register size, this time adding a prefix "E" instead of the suffix "X". Oh, and they added the protected mode... which is nice, but looks like a hack compared to other processors, IMHO.

And here we are: we still have to live with some of the limitations and ugly things from the hastily hacked together CPU that was the 8086, for example no real general purpose registers: all the "normal" registers (E)AX, (E)BX, etc. pp. are bound to certain jobs at least for some opcodes. No neat stuff like register windows and shit. Oh, I hate the 8086 and that it became successful. The world could be much more beautiful (and faster) without it. But I rant that for over ten years now and I guess I will rant about it on my deathbead.

Re:Die already !

[Anonymous Coward]

The problem is that, like English, even though x86 sucks in so many ways it just happens to be very successful for those same reasons. Like for instance using xor on a register to zero itself is both disgusting and efficient... kind of like "yall" instead of "all of you".

Re:Die already !

[timster]

Nonsense -- it's the LACK of a plural second-person pronoun in "proper" English that is disgusting (and inefficient). "Y'all" is the best hope we have for fixing this bug, and y'all should start using it as much as possible.

Re:Die already !

[eswierk]

Does anyone besides compiler developers really care that the x86 instruction set is ugly and full of legacy stuff from 1978?

Most software developers care more about things like good development tools and the convenience of binary compatibility across a range of devices from supercomputers to laptops to cell phones.

Cross-compiling will always suck and emulators will always be slow. As lower-power, more highly integrated x86 chipsets become more widespread I expect to see the market for PowerPC, ARM and other embedded architectures shrink rather than grow.

Re:Die already !

[Wrath0fb0b]

Even Intel didn't want it to live that long. The 8086 was hack, a beefed up 8085 (8-bit, a better 8080) and they wanted to replace it with a better design, but iAPX 432 turned out to be a desaster.

The attempts to improve the design with 80286 and 80386 were not very successful... they merely did the same shit to the 8086 that the 8086 already did to the 8085: double the register size, this time adding a prefix "E" instead of the suffix "X". Oh, and they added the protected mode... which is nice, but looks like a hack compared to other processors, IMHO. Perhaps this can be taken as a lesson that it is more fruitful to evolve the same design for the sake of continuity than to start fresh with a new design. The only really successful example I can think of a revolutionary design was OS-X, and even that took two major revisions (10.2) to be fully usable. Meanwhile, Linux still operates based on APIs and other conventions from the 70s, the internet has all this web 2.0 stuff running over HTTP 1.1, which itself runs on TCP -- old, old technology.

The first instinct of the engineer is always to tear it down and build it again, it is a useful function of the PHB (gasp!) that he prevents this from happening all the time.

Re:Die already !

[gardyloo]

Ha. That's what "you" is for. We just need to bring back "thou" for the singular.

Re:Die already !

[dwye]

> Ha. That's what "you" is for. We just need to bring back "thou" for the singular.

Thou was only used within the family, to someone you wanted to treat like family (ie, a close friend), or an inferior. God, being the Father, was addressed as thou, and since most people only know their thee's and thou's from Shakespeare or the King James Version of the Bible, they think that thou was used far more than it was. It was already on its way out by the start of the KJV project, but the scholars used slightly antique language, rather than risk using what could turn out to be slang, and wrong in a generation or two.

Re:Die already !

[Anonymous Coward]

No neat stuff like register windows and shit. Register windows? Are you serious?

It's widely assumed that SPARC's support for register windows is the main reason the architecture could never keep pace with competition from PowerPC and the like (let alone x86).

Register windows, while seeming like an elegant idea, are a nightmare from an optimization standpoint. A lot like a number of hardware architecture "innovations" over the years...

Re:Die already !

[gardyloo]

That's only true after Middle English arose with the Norman Conquest. This particular point was much easier in Old English!

Re:Die already !

[Anonymous Coward]

But I rant that for over ten years now and I guess I will rant about it on my deathbead.

What a life!

Re:Die already !

[DarkDust]

The first instinct of the engineer is always to tear it down and build it again, it is a useful function of the PHB (gasp!) that he prevents this from happening all the time. Yes, you are completely right with that. Doesn't change the fact that I hate x86, though ;-)

Re:Die already !

[Anonymous Coward]

OS X wasn't even revolutionary, it was an evolution and combination of the Nextstop OS.

Re:Die already !

[rrohbeck]

You forgot the segment adder bug in the 286 that gave us the beauty of GateA20.

Yes, it's a POC. I coded 8086 through 386 assembler for years. Ugh.

Re:Die already !

[the_humeister]

Why did parent get modded up? x86 may be ugly, but it gets the job done fast at a much lower price point than other architectures. Besides, who actually writes pure assembly nowadays? Almost all programming is done in higher level languages anyway.

Re:Die already !

[renoX]

Not so widely apparently because the Itanium also has a register window..

Of course, I don't think that VLIW are a good idea (compilers aren't good enough for those), but this show that Intel&HP engineers thought that register window is a good idea..

Re:Die already !

[x2A]

I believe "you" is actually the plural (from 'thou', but something about the german printing press not having the character that represented the 'th' sound, and the nearest looking character it did have was a 'y', leading to 'thou' being typed 'you'). The singular would be ye (from 'thee'). From what I've heard, the plural form was used also to address people who were higher up, or "more than" you, as a sort of show of respect (which is where the "royal we" comes from; basically the queen saying "i'm so important I use the plural to refer to myself because I'm equivelant to lots of you"). This meant that 'thee' dropped down to being more derogatory, and its use was depreciated, leaving only the second-person-plural thou/you.

Re:Die already !

[Anonymous Coward]

True, it's the VHS of CPU's

June 8th

[coren2000]

Why couldn't the poster wait for June 8th to post this story... its *MY* birthday today dang it... x86 is totally stealing my day....

Jerk.

Re:June 8th

[tlacuache]

My birthday is June 8th (although my age was still a negative number in 1978). I guess if I pretend really hard, I can sort of imagine that you're all saying Happy Birthday to me instead. Ah, it's so good to be loved.

And so did IBM with the PC

[IvyKing]

The docs for the 8086 stated that the interrupts below 20H were reserved, so guess what IBM used for the BIOS. The 8086 documentation was emphatic about not using the non-maskable interrupt for the 8087, and guess what IBM used. OTOH, Tim Paterson did pay attention to the docs and started the interrupt usage at 20H, but he wasn't working for either IBM or Microsoft at the time.

TFA doesn't get into the real reason that the x86 took off, that the BIOS for the IBM PC was cloned at least two or three times which allowed for much cheaper hardware (the original Compaq and IBM 486 machines were going for close to 10K$, where 486 whiteboxes were available a few months late for 2K$).

alt.x86.die.die.die

[AceJohnny]

and long live x86 Are you out of your mind!? OK OK, I'll admit that commercially, Intel was genius in making backward-compatibility king.

But on a technical side, the world would be such a better place if we could just switch to more modern architectures / instruction set. The chips would be smaller and more power efficient, not having to waste space on a front-end decoding those legacy instructions for the core, for example.

I know, Intel tried to break with the past with the Itanium. They were wrong in betting that the compilers would be good enough, sadly. Damn you, real world, damn you!

Re:alt.x86.die.die.die

[RiotingPacifist]

Turns out end users like sucky products and backwards compatibility, it means they dont need to worry about stuff as it just works.

see also windows.

NEC V20?

[Anonymous Coward]

Alright - who remembers replacing the original 8086/8088 with an NEC V20 for the extra 2mhz?

-- kickin it old school IBM PCjr style.

Re:NEC V20?

[Anonymous Coward]

The V20 was for the 8088, you used a V30 for the 8086.

And yes, I upgraded an ICL M30 computer from the original 8086 to a faster V30 (about 10%, IIRC).

I also added a co-processor made by someone other than Intel (whose name I forget).

The only part of that computer still in use is the keyboard, which is built like a tank.

Re:NEC V20?

[Pope]

Dude! I did that in my PCjr! Had that thing maxed out to 640k (used to run Infocom games by copying the whole floppy info to a RAM disk, then using the floppy only for the save games; ran hell of a lot faster, let me tell you), added the NEC chip after a few years. Had that thing as my main computer for 7 years, at which point I got a used 20MHz 386SX.

8086 computers?

[Futurepower(R)]

You said, "... Compaq and IBM 486 machines ...".

I think you mean 8086 computers, or even 8008 computers.

Re:8086 computers?

[IvyKing]

"or even 8008 computers"

Perhaps you meant 8088?

I mentioned the 486 specifically because low cost 486 machines were available only a few months after the expensive models from the big boys - the first low cost clone of the 8088 came out several years after the PC.

Certain?

[camperdave]

Intel used then "the dawn of a new era" slogan, and they probably didn't know how certain they were.

How "certain" they were? "Certain"?? Surely you mean "correct", "right", or perhaps "prophetic".

I For One Welcome...

[Anonymous Coward]

...just kidding...

Intel, 1978

[conureman]

Rejected my application for employment.

Happy birthday!

[Nullav]

Now die, you sputtering son of a whore. :D

Re:Happy Birthday!

[Anonymous Coward]

Argh!

Out of interest...

[samael]

I know that modern x86 chips convert into RISC-like instructions and then execute _them_ - if the chip only dealt with those instructions, how much more efficient would it be?

Anyone have any ideas?

Re:Out of interest...

[imgod2u]

Well, in order to be fast in executing, the code density can't be all that high for the internal u-ops. I don't have a rough estimate but if the trace cache in Netburst is any indication, it's a 30% or more increase in code size for the same operations vs x86. We're talking 30% increase of simple instructions too. I would imagine it's pretty bloated and not suitable to be used external to the processor.

On top of that, it's probably subject to change with each micro-architecture.

Re:Out of interest...

[slittle]

Does it really matter? Once you expose the instruction set, it's set in stone. That'll lead us back to exactly where we are in another 30 years. As these instructions are internal, they're free to change to suit the technology of the execution units in each processor generation. And presumably because CISC instructions are bigger, they're more descriptive and the decoder can optimise them better. Intel already tried making the compiler do the optimisation - didn't work out so well.

Re:Out of interest...

[Anonymous Coward]

It would be less efficient because of increased code cache pressure.

ARM architecture is 25 years old

[cyfer2000]

The ubiquitous ARM architecture is 25 years old this year and still rising.

Re:ARM architecture is 25 years old

[mustrum_ridcully]

Yes but not quite...

Development of the ARM architecture began in 1983, but the first prototype ARM 1 processors weren't completed until 1985, with the ready for market ARM 2 being available in 1986 when the Acorn Archimedes computers were released.

Report to Carousel

[xPsi]

X86 Turns 30 Years Old Happy Birthday! But do not be alarmed. That flashing red light on your palm is a natural part of our social order. On Lastday, please report to Carousel for termination at your earliest convenience. The computer is your friend. Oh, wait, you ARE the computer...

Re:Report to Carousel

[vdgmr1213]

If all else fails, we have Runners to make sure it all goes smoothly. Just don't send Logan.

And Have We Learned Our Lesson?

[FurtiveGlancer]

About the tyranny of backward compatibility? Think how much further we might be in capability without that albatross slowing innovation.

No "it was necessary" arguments please. I'm not panning reverse compatibility, merely lamenting the unfortunate stagnating side effect it has had.

Re:And Have We Learned Our Lesson?

[conureman]

Dammit, you made me cry. Thanks.
  Thirty years wasted.

Re:And Have We Learned Our Lesson?

[IamTheRealMike]

If that were true we'd see amazingly innovative ISAs that everybody lusts after but can't use. We don't. There's been very little change in ISA design over the years, and when it's happened it's as often as not been driven by Intel themselves (look at their research into having tons of cores on the same chip with a super-fast grid bus between them).

Re:And Have We Learned Our Lesson?

[Anonymous Coward]

As innovations intertwine, the benefits of backward compatibility multiply. Obviously, computers can be thought of as a mesh of interconnected technologies (processors, memory, drives, operating systems, applications, etc.). Changes to a single strand/node in the mesh can ripple outward, forcing rework in other technologies for years and stalling innovation in those other areas while they adjust to the change.

Increasingly, no single person understands the way everything interconnects - they just understand how the thing they built works with the things that attach directly to it. In that kind of environment, you pray that the guy who built the system connected to yours doesn't change the way his stuff works at the connection point, forcing you to figure out how to keep your stuff working well.

That's not to say that it isn't sometimes a good idea to break with the past - just that the decision should probably take into account dependent things.

Re:And Have We Learned Our Lesson?

[Anonymous Coward]

There have been amazingly innovative ISAs, and unusability is usually tied up in the toolchain targeting those ISAs rather than hardware, since the ISAs themselves are often readily implemented as byte code interpreters (and to some extent outright virtual machines) that can run reasonably quickly on many computer systems.

Another option which is useful for usability is the ability to translate from the innovative ISA into e.g. IA-32 or x86-64 for packaging up for delivery into a popular OS environment (Mac OS X or Windows, for example). That way you can build a variety of languages -- assembly, C, Java, Lisp, you name it -- targetting the innovative ISA, and actually run the result reasonably well on widely available computer systems. (Or, even, on not widely available computer systems that actually implement the innovative ISA).

The Big Three that are both bytecode-interpreted and translated-to-widely-deployed-ISAs the Java bytecodes, CIL/MSIL and the LLVM IR.

While not "everybody" lusts after them, there are significant communities targetting these ISAs specifically because some aspect of them is lustworthy (even if that reason is often easy hardware or OS portability). On the other hand, "but can't use" doesn't apply to these either. Finally, Intel does not seem deeply involved in any of these three projects, let alone acting as "driver".

That said, Intel does do interesting compiler and language research. That makes enormous sense, since two of their largest advanced projects (iAXP 432 (which was actually pretty cool) and Itanium) died in part because early compilers for both platforms generated abysmally slow native code.

[Although, in the pre-2006 Itanium case, it was more that the *Itanium-specific* C compiler did an OK job generating IA-32 code to be run on the Itanium's internal x86 circuitry, but the standard Intel compilers (and MS C and gcc) produced code that ran very slowly on it, *and* the Itanium-specific compiler didn't generate code that ran as quickly on actual IA-32 processors as gcc/icc/MS C. Intel could not manage to sell "fat binaries" to the market, where a given delivered program would have compiled code targetting standard IA-32, Itanium's IA-32, and IA-64, especially since two (or three!) often $$$ expensive compilers needed be involved in generating the binaries.]

And me!

[Anonymous Coward]

That means I'm 2 years older than x86.

You should change the front page to " Happy Birthday! X86 and Anonymous Coward"

"Dawn of a New Era"

[kylben]

This is probably the first time in the history of advertising that a slogan of such over the top hyperbole turned out to be understated.

INTEL

[Anonymous Coward]

I sex it? No!

Intel introduced non-x86 three times ...

[peter303]

Even Intel early on recognized the limitations of its very early architecture and introduced replacements. But all were commmercial failures. Customers were too attached to legacy binary software. And this left openings for companies like AMD who "did Intel better than Intel".

So what happened then is that Intel emulates itself using more modern architectures. The underlying engine changesd to RISC around 486(?), wide-words, and more recently cells. All emulate the ancient x86 instruction set. Each generation needs proportionately less real estate to do this. Last time I looked it was 5%, but might be under 1% now.

Re:Intel introduced non-x86 three times ...

[Anonymous Coward]

I always wonder why they don't expose the "real" instructions. Have some bit in the bios you set that makes it an "Intel CISC-less x86 processor". Probably the CISC translation layer is so effective it would be pointless, but might shut up the "waaaaa, x86 sucks, waaaaa" crowd.

not fair, this is too Do$$y

[CDMA_Demo]

09 and 21h are MS-DOS interrupts. I bet that wasn't around when the first x86 appeared on the planet....try again mr. jedi

Re:not fair, this is too Do$$y

[TheRaven64]

A lot of the DOS interrupts were copied from CP/M to make porting easier, so they might have been the same.

Re:not fair, this is too Do$$y

[CDMA_Demo]

model small/tiny stack etc. are keywords from MS Assembler (MASM).... So you're saying that this code would've run on CP/M?

Re:not fair, this is too Do$$y

[Two9A]

It would run fine. As GP says, CP/M had many of the same interrupts, so the assembled binary would have worked without a problem.

Whether it'd assemble under a CP/M system, is another matter. I can't remember seeing a version of Macro Assembler for CP/M, but I'm sure someone will be along to correct me.

Re:not fair, this is too Do$$y

[Anonymous Coward]

Exactly! You need to use 10h for BIOS display, AFAIK, or similar BIOS only interrupts. That will add some code for the loop to display the line.

Re:not fair, this is too Do$$y

[x2A]

...or could load up pointers into SI/DI, string length into CX and REP MOVSB?

(for 32bitters who don't understand what I'm saying allow me to rephrase: or could load up pointers into ESI/EDI, string length into ECX and REP MOVSB?)

Re:not fair, this is too Do$$y

[IvyKing]

Using INT 21H for making an OS call started with QDOS, which was written in early 1980. While that postdates the appearance of the 8086, I doubt if there were more than a few hundred 8086 systems in the wild at that time.

In the near future

[mmxsaro]

A Slashdot story for the near future.

The title: x86 Finally Retired by Intel
The tags: intel, x86, goodriddance

correction

[Paul Rose]

(but *NOT* MSDOS compatible)

8086 phooey!

[Anonymous Coward]

When it first came out and I learned about it, I was shocked at how stupid and kludgy it was compared to the far more elegant Z8000 and 68000. Just another example of how market manipulation trumps technical superiority. May Intel rot.

How sad.

[Anonymous Coward]

An architecture that was junk when it was created and remains junk now is still, nevertheless, dominant. How much further ahead would computing be if we weren't chained to x86?

my favorite

[bornyesterday]

When I was an undergrad 4 years ago, I took an assembly class as part of my comp sci minor. The class was based around the 8086 architecture, and it was my single favorite comp sci class. I learned more about how computers and software work in that one class than in all the other class I took, combined (though I'm looking forward to hearing someone say that I must not have learned much in my other classes.)

Not to start the argument over what should be taught first to students, but I sometimes think that comp sci degrees should start by teaching the 8086 assembler language just because it provides a very clear picture of what higher level languages are actually doing once they are compiled.

Re:my favorite

[Clueless Moron]

I agree with your sentiment, but NOT 8086, please. It's a bloody mess.

When I was in University they taught PDP11 instead. That's an amazingly clean architecture. Shades of it appeared in 6809 and 68k, but PDP11 was the original.

Re:my favorite

[cptnapalm]

Here and there, I've seen a number of people gush over the PDP 11's assembly stuff. Not knowing assembly, I of course, cannot judge, but seeing as no one fawns over other architectures like that, I'll assume they know what they are talking about.

Re:my favorite

[ibsteve2u]

Hmmm...believe my first opcode chip was the Z-80, but I agree with your sentiments regarding ASM should be taught.

However, my experience with academia and decisions by committee tell me that stuff like C++ and .NET will prevent ASM from being a core requirement. ASM is simply not obfuscated enough, while on paper JMP doesn't look nearly as important as polymorphism.

To the subject at hand, Michael Abrash's Zen of Assembly Language is a good read...

Re:my favorite

[Anonymous Coward]

I've heard C described as "Portable PDP-11 assembler", so make of that what you will.

Old man

[Dramacrat]

This is no longer relevant, n00b.

Re: Dual instruction sets?

[Alwin Henseler]

What Intel should do is expose both sets of instructions, act like an x86 if the OS expects it, or act RISC-like if the OS expects that. Not that there's any point. From what I understand, many common compilers only use a limited subset of the x86 instruction set anyway. To take advantage of that fact, you'd have to create a new CPU with just the set of instructions that are used, or modify compilers to use a specific subset, and create an optimized CPU for that. The most important thing: ditch the unneeded extra ballast of the x86 instruction set, and perhaps re-arrange the remainder.

Oh wait, that's been done. It's called porting to a different, more elegant and/or power efficient architecture (like ARM, Mips or other). What you need for that is source code for the software. If you have source code for all the software you need, nothing keeps you from moving to a better CPU architecture. If you don't (like with closed-source apps on Windows), then you can't.

If manufacturers of those mini-PC's like the Asus EeePC can take a hint, they'd do the smart thing and move the Linux-based versions onto a more power-efficient architecture. You'd lose the binary compatibility, but that would be a small loss if you're running Linux and not do serious PC gaming anyway. In return you could have vastly improved battery life for the Linux-based versions.

So?

[Bluesman]

What's so special about this?

Wake me up when it turns 32.

math fail

[SendBot]

pardon me for being such a math nerd, but I enjoy it so:

Each of those may be connected to 10^4 other neurons, so the total number of connections is about 10^15.

You're counting a lot of connections more than once (see permutations), not to mention your perilous assumption that a neural connection would only consume one byte in the hypothetical model.

If each one takes as much storage as a 5 Gb DVD, and IMDB has 400,000 movies listed [imdb.com], then that's a total of 2x10^15 bytes, which is 50 bits. That's 16,000 times smaller than a 64-bit address space.

Firstly, what you mean is GB(bytes) not Gb(bits). 2e15 bytes would need a 51-bit address space, and 16 exabytes is a little over 9223 times 2e15 bytes.

I like the direction of your ideas though.

Happy Birthday!

[ucblockhead]

I will declare a far pointer in its honor.

Certainly

[Anonymous Coward]

On June 8th, 1978 Intel introduced its first 16-bit microprocessor, the 8086. Intel used then "the dawn of a new era" slogan, and they probably didn't know how certain they were.

You mean they were uncertain about how certain they were?

Oh, really?

[mangu]

Everything the x86 series did, someone else did first on some other processor (68k, Sparc, MIPS, and PPC, to name a few)

Bullshit, the 8086 predates all those processors you mention.

Re:Oh, really?

[the_humeister]

He's talking about things that happened in the x86 line of processors, not the 8086. for example, superscalar and out-of-order execution did not originate in the x86 processors before another architecture had it.

amen!

[Anonymous Coward]

x86 is indeed ugly compared to the beautiful ARM instruction set.

I choose you

[Anonymous Coward]

so now that x86 reached it's level 30 mark, can it finally evolve to 64 bit status yet? Because we all know that charmander is fun but charizard can be so much better.

Darn Decoders

[Bengie]

What if Intel dropped the decoder down to like 1 unit and let program pass micro-ops directly in? Reduce some die space and give the option of chopping out the middle man(decoder)

Re:Darn Decoders

[x2A]

What if we got rid of libc and get software to communicate directly with the kernel? Reduce the libraries that need to be loaded+linked into the system, and removes an abstraction layer that adds overhead?
Quite simply, you'd have to rewrite code whenever you want to swap the kernel, or when the kernel internals chance sufficiently. Abstraction layers mean you can change part of the system without having to change the rest. I can swap out my linux kernel for the solaris kernel to take advantage of ZFS and escape the locking delays I've been finding in recent linux kernels without having to rewrite my software I'd originally written on linux. Just as I can swap between AMD and Intel processors without having to recompile for different micro-op vocabularies.

Abstraction layers might slow things down today, but they save a lot of time and development in the long run.

Looser architecture

[older coder]

What amazes me is how successful this architecture has been when it is such a looser design.
Certainly, a lot of good stuff has been thrown in over the decades, and on the balance, the Pentium architecture - all in all - is pretty good. But the 8086 was a bad attempt at compatibility with the 808 and those compatibility compromises have led to problems then and now.
Motorola's 68000 architecture was much more efficient and easy to design for, but 1) they didn't do marketing as well as Intel has, and 2) they didn't win the competition for the IBM PC - a competition no one could have known would be as significant as it was.
I have seen so many examples of this where the better technical solution lost out to the one that was better marketed.

Re:Looser architecture

[Anonymous Coward]

What I'm about to say should be obvious, but it seems to be a point that is often missed on Slashdot - the technical considerations are not the only ones, or even the most important. The fact that only zealots and people who are under the influence/control of zealots use free software should be a big clue, for example.

Of course none are so blind to the workings of people as nerds, so it's not a surprise no one here seems to get this.

Re:Looser architecture

[Anonymous Coward]

One of the things forgotten about why people chose the 8086 over the 68000 was that Motorola had made a bad design decision with the 6800. The original 6800 required a horrible two-phase non-overlapping non-TTL compatible clock, and it took a year or two for Motorola to make a clock chip available.

Meanwhile the 8085 had a much simpler TTL-compatible clock requirement (as did many of the alternative mpus of the time - this was the most notable improvement over the 8080).

In turn this meant that many early home computers used the 8085 (or the better Z80), and not the 6800.

The only 1970s era computer I can think of that used the 6800 was from SWTPC - all the rest used the 8085, Z80 or 6502. Only in the early 80s did Epson use a 6801 derivative (the 6301) in the HX-20 portable.

I suspect that at least in part this led to the decision to use the 8086 in the PC as this processor was software compatible with 8085 code (Intel had a converter program available).

Segmented architectures needed to die

[Bananenrepublik]

If there had been 256byte paragraphs, we would have had to live with segmented memory much longer. Thank god it died soon! Nothing is more annoying than pointers that consist of two parts. Well, being chased by Steve Ballmer in a room filled with chairs probably is, but you get the point.

Another 30 years of x86 ...

[bestinshow]

Happy birthday and long live x86. Oh dear God, dog, spaghetti monster, allah, etc, NO, please.

For at least 25 of those years it's been kept alive because there was an existing library of software for it. I'm sure there were 68k vs x86 wars back in 1985 which were pretty one-sided because of the cruft of x86 even then.

At least AMD64 has cleaned it up a lot since. And due to the massive investment it has been incredibly powerful for quite a long time now. :(

Re: Dual instruction sets?

[drsmithy]

If you have source code for all the software you need, nothing keeps you from moving to a better CPU architecture.

Uh, what ? Two of the most important things in the world keep from doing that: time and money.

Um, yeah. Actually

[BattyMan]

Like the poster above, there was a hill between my dorm and the computer center, and when there was snow, I'd wind up carrying my punch cards through the snow, uphill _both_ ways!

Now get off my lawn!

PDP-11 still lives!

[Joutsa]

The company where I used to work still has legacy binaries for VAX, which is an extension to PDP-11. The actual machines are finally starting to break, but the software runs now on emulators. The VMS operating system is a big awful mess, but it was also the reason BSD was created. Guess which one our machines run...

Bah!

[CrazyTalk]

I prefer the 8088.

PPC vs. Itanium

[DrYak]

But would the push for Power/PPC have happened {...} ? Makes one wonder. If 68k was the architecture that everyone was holding onto, the push to an incompatible and completely different PPC architecture would probably be recieved with as much success as the push Intel tried recently toward the Itanium :

Wherever the new architecture is better or worse wouldn't matter, only the fact that it wouldn't run the tons of legacy software lying around.
A PPC would have been rejected to a niche usage because of the legacy DOS/68k.

8086 UNIX system

[cptnapalm]

Bell Labs ported UNIX to run on the 8086. An overview of the porting was given in the Lab's October 1984 Technical Journal.

So Happy Birthday to the first x86 processor to run UNIX!

It's not the tearing, it's the popularity

[DrYak]

Perhaps this can be taken as a lesson that it is more fruitful to evolve the same design for the sake of continuity than to start fresh with a new design. Nope. The best strategy is to push whatever product you have on something that will be sold on a massive amount of machine and become so much pervasive that it will become standard. Then everyone will stick to it because of compatibility to legacy code.

8086/8088 didn't succeed *because* it was a 16bit hack of the 8008/8080/8085. It succeed because it was sold on the IBM PC (lots of sales) which in turn got cloned (even more sales of 8088s). By the time you sit back and try thinking about it, there are 8088s almost every where.

As counter example :
- Motorola 68k : wasn't a hack of the 6800, was instead a completely new and better architecture. Never the less, it managed to get really popular on 16bits arcade machine and home consoles. (To the point that it's really hard hard to find something else inside those - the SNES' 65c816 comes to mind as an exception). It was the standard everyone was used to, thus it made sense to keep the same chip into the consoles to help porting arcade titles.

- ARM. Wasn't a hack, wasn't a successor which tore older design neither. Just a new chip. Attracted initially some designers because of efficiency low power and low cost. Got success in embed applications. Grew fast. Now engineer are so much used to it, that this architecture simply can't get replaced. At least, unlike the x86 it's a very nice one and nobody is complaining about its dominance.
You can find in almost anything that is microprocessor controlled, but isn't a desktop.
To the point that Intel has a hard time pushing it's Atom chip in the PDA world.

The first instinct of the engineer is always to tear it down and build it again, it is a useful function of the PHB (gasp!) that he prevents this from happening all the time. No. He must not avoid tearing at all cost. He must avoid tearing something that is very popular and pervasive. He can safely tear appart and rebuilt better something that nobody cares about.

The web is a nice example : when HTTP was invented, there were already other transfer protocols existing. Nevertheless it turned out being very popular. Because, well, the whole web thingy didn't exist before it. HTTP was new *in its own niche* and didn't try to replace something popular before it. On the contrary, it became itself very widespread (thanks to the popularity of the Web which used it), and thus became a standard that every body is using today for completely unrelated stuff (HTTP used as transfer protocol for Jabber, Bittorent, some RPC, etc.)

Unix was popular when Linux arrived thus, Linux' compatibility to the "widely used standard" did matter.

The Mac OS X success is simply explained by the same mechanism : the Macs are a controlled platform - no 3rd party hardware maker which could be pissed of by an incompatible switch in software or hardware.
Being more in control of whatever runs in a Mac, enable Apple to "abstract" each successive upgrade (68k -> PPC, Classic -> OS X, PPC -> Intel) by putting the former in an emulator running on the later.
Thus, for Apple user, whatever is being used underneath doesn't matter, the application are still running the same - except with more stability.
And thus, Apple engineer can safely tear apart and rebuilt it.

OFFTOPIC tagline rant

[ShagratTheTitleless]

Patriotism is akin to racism only if love is akin to hate!

Credit where credit is due...

[anss123]

Imagine that you where designing a computer for the future back in the eighties. What chip to choose:
  1. The segmented 8085 work alike 16-bit CPU
  2. A 16-bit CPU with 32-bit registers and address space
  3. Another 16-bit CPU with 32-bit registers and address space, this one cheaper that (2)
  4. Another segmented 16-bit CPU, but works more like an 6502

I'd probably go for number 3, Apple went for 2 and 4 (in the Apple II). Who could have guessed we'd be posting over a world spanning nettwork using supered up 8-bit CPUs 30 year later? Number 2 lasted some 13-14 years, so Apple probably made the best choice they could have made - after all back then number 1 and 4 was clearly dead ends.

Long live x86?

[Anonymous Coward]

Dear lord no. Kill it with fire already. This horrible architecture had outlived it's usefulness by the end of the 80's and wouldn't be here today without billions spent on life-support.

CP/M-80 didn't use software interrupts

[IvyKing]

CP/M used a jump instruction to handle OS calls, QDOS/86-DOS/MS-DOS had the target of that jump be the INT 21H instruction. So the code would NOT work on CP/M.

There was a version of Macro assembler available for CP/M - which pre-dated the MS-DOS version.

Re:Give me my Amiga back !!!

[Anonymous Coward]

We could have been using Motorola powered Amigas
ten years ahead of what we have now if only Motorola and Commodore had better marketing and less greedy clueless management.

Instead we got the great Microsoft technology winter.

I loved the ease of coding in 68000 assembly.
Just look at some of the arcade games coded
at the time in 68000 code to see how that
translates in quality of end product.
Intel was always unintuitive akwardly designed shit and to this day I refuse to code x86.

Someone save us from these Wintel assholes !
Someone make a proper multimedia dev environment on PowerPC with Linux or an updated AmigaOS please !!! Enough with this waste of computing resources because of agressive fat bastard tactics.

illusions

[reiisi]

IBM also tried it, but with the PPC.

EVerybody and their dog has tried it.

ARM is getting close.

stupid rumor

[reiisi]

You'll find out how stupid in about a year.

Never did that

[wiredog]

I used TASM to do my assembling.

I did once write a program in hexadecimal, for an embedded system.

I take it you believe everything you read?

[reiisi]

Kicking butt on performance ...

in the marketplace, but not in the machine. (At least not on my application mix.)

And, no, emulated PPC on iNTEL is never faster, unless you are talking about faster in emulation on a 2+GHz Core 2 Duo as opposed to a 1 GHz G4. And then just barely, maybe, sometimes, but not very often.

IBM and Motorola/Freescale wouldn't make the notebook "G5" because they were focused on something else, and because Apple kept asking for the latest fads in addition to processors that worked well for their application areas.

For some reason, the suits have always biased the market for iNTEL. If it's not the "standard", it is not good enough to be just as good on the average. It has to be twice as good in every case, or the bean counters say the "standard" is somehow cheaper.

The requirements in 2000?

[reiisi]

Or, more accurately, 1997 or thereabouts?

Steve was prescient about the market and about IBM and Motorola's attention span relative to desktops?

Remember, the x86 port was there for a long time.

well, yeah, but the arch is not 8086

[reiisi]

think bio

trs80 would be closer to a desktop, though

[reiisi]

keeping apples with apples, so to speak.

The big iron back then had already well broken the 64k barrier.

Watch out for inflation: $360 = $1069 today

[alispguru]

According to the Consumer Price Index Calculator $360 in 1979 = $1069 today.

Their 2008 numbers are based on linear extension of the 2006 - 2007 data, so this might be off.

emulating the brain's state does not mean immortal

[reiisi]

But, yeah, your point on having enough RAM to fill a 256 bit address space is quite relevant.

We really don't know enough about the function of the mind to be safe in assuming any specific number of bits-per-neuron and thinking we're down.

Even when we get the neural mass figured out, we have to start accounting for the hormonal system, and then the rest of the body. Thinking is not all we do, and much of the non-cerebral stuff feeds back into the cerebral.

time and money

[reiisi]

duality here --

time is all we've got,

and money is just an illusion.

It's all about your priorities. If you let the gaggle of salescritters down the hallway engineer your machinery, you have the situation we have today.

segmenting

[reiisi]

or, rather, the illusion of segmenting, was the other huge hidden charm point of the x86.

It allowed us to fool ourselves into thinking we could virtualize the application on commodity hardware way back when. So we could start small and the hardware would help us move up.

It didn't matter that the hardware didn't really help after all for most apps. It gave the engineers courage to go to the bean counters and say, "Let's start small, with something we know we can handle."

Specification overkill is what really killed the 68K. Nobody dared spec it unless the spec-ed to include the kitchen sink. Otherwise the bean-counters were constantly nagging them about why they couldn't use the supposedly cheaper "standard".

Re:Backward integers forever! (clue me in here.)

[reiisi]

You mean to tell me that there is some physical or metaphysical reason we should write numbers on paper opposite the way we write them in memory?

Let me check how I write things, just to be sure:

There are 11,000 people living in Takino.

Okay, string that out in memory, as ASCII text:

mymac: me$ hexdump -C
There are 11,000 people living in Takino.
00000000 54 68 65 72 65 20 61 72 65 20 31 31 2c 30 30 30 |There are 11,000|
00000010 20 70 65 6f 70 6c 65 20 6c 69 76 69 6e 67 20 69 | people living i|
00000020 6e 20 54 61 6b 69 6e 6f 2e 0a |n Takino..|
0000002a
mymac: me$

That wasn't clear enough:

mymac: me$ hexdump -C
12345 people
00000000 31 32 33 34 35 20 70 65 6f 70 6c 65 0a |12345 people.|
0000000d
mymac: me$

Or, in other words,

0000: 31 '1 * 10,000
0001: 32 '2 * 1,000
0002: 33 '3 * 100
0004: 34 '4 * 10
0005: 35 '5 * 1

Now, I cannot convince myself that I am writing that least significant digit first. So, you are telling me that there is some implicit reason why numerics in memory should be stored backwards from the way we write them, right?

The implicit reason in the x86 architecture is that you can short-circuit addition and subtraction in some cases on a least-significant first arch. If you dare. But, remember, if you dig back into the literature, there were good shortcuts for the most-significant first order, as well.

Of course, unless we like look-ahead when calculating by pencil, we usually work the basic math least-significant first. And, for what it's worth, when computers work on numeric strings, they do too. But you have to either start or stop at an offset, so it really doesn't buy you much to do the same thing in RAM that you do on paper -- start with the offset motion.

choice not to bother?

[reiisi]

That's more or less what Motorola did. Said they didn't want to compete with there customers.

A lot of their customers did think a standard was something to sell for money, though.

on the other hand,

[reiisi]

A lot of projects got started on the x86 in the illusion that the 16 byte "paragraph" would somehow help them with fine-grained memory allocation. (And once they understood the reality of the thing, it was hard to believe it wasn't too late to switch.)

Would have been better to have just made the segment registers full-width base registers. Except that would have cost iNTEL a few pennies more per processor, and pennies seemed to count back then. If the segment registers had been full 20 bits wide (a0 to a19) to start with, it would have been a lot less troublesome to extend them. Of course, it would have been a lot clearer that the 68K made more sense, as well.

fine grain, they thought

[reiisi]

(As I said somewhere above.)

Yeah, I do mean to imply that it was an illusion.

But, then again, back then, if you had four extra bits in any register, those four bits would tend to get used. (See the use of the upper byte of address space in the original Mac systems, for an example.)

before 1980?

[reiisi]

16K was considered reasonable on the first IBM PCs. 64K was large.

ergo, because iNTEL then _had_ to try harder

[reiisi]

n/t;

micro-coded processor?

[reiisi]

But, no, iNTEL was not the first to produce a CISC front end for a RISC-like architecture, even if you say there's a difference between what iNTEL does and micro-coding (ergo, the scheduling, and such).

Re:micro-coded processor?

[bhtooefr]

I wasn't claiming that Intel did. I was claiming that NexGen (who was bought by AMD) did.

What was the first processor that did use a CISC front end for a RISC-like architecture, then?

AFAIK, it's the NexGen Nx586, using an i386-compatible front end with "RISC86" architecture.

expect to be surprised

[reiisi]

n/t;

(Hmm. they tell me I've already said no text, even though that was under a different subject.)

lower price point than what?

[reiisi]

arm? mcore? ...

Tandy/Radio Shack Color Computer

[reiisi]

6809, and a very simple clock circuit. Maybe too simple.

But it made it nice for sharing the RAM with DMA video and stuff.

Strange dead ends in our industry.

fuzzy memory (carbon-based)

[Joseph_Daniel_Zukige]

But I do remember the articles about the NexGen, as well, mentioned the predecessor tech. You might try looking for writable microcode processors and such.

How do you consider Thumb in relation to the concept?

I seem to remember early POWER processors having mixed microcoding, and a project for hardware emulating the x86 instruction set on POWER or PPC, through a front end. Not sure if that's close enough to satisfy you.

There would also be similar, but different products, like the 360 emulator that ran on a couple of 68K processors with re-programmed microcode. (I think one processor was for the I/O channel controller and the other emulated a subset of the 360 machine code.)

Evolve by Depreciation

[cjb110]

Just wondering something, Intel and AMD keep adding to the x86, (MMX, SSE etc), do they ever take something away?
i.e. if there was something that worked at the time, but majorly sucks now, do they remove it?

If not why not?

Advantages of Speech Recognition

[Simonetta]

The problem of differenciating between 'there' and 'their' is not important. The reader can do that and fix it if they chose to. The major advantage of Speech Recognition is that it takes the thoughts of the moment that would never have been recorded on paper and makes them into a text file that can be stored, saved, or expanded at a future time. It allows personal histories to be preserved without having it become a serious task, like sitting down to write a book would be.