OSDev.org

http://en.wikipedia.org/wiki/Intel_iAPX_432
This is the page about a very strange processor. It had a native support of OOP and a really different assembly. Why Intel has locked the developement of these products? Do you now where I can find some datasheets or opcodes table? I'd like programm an emulator for this platform

My dad's thesis (back in '88 I think) was about an object-oriented machine architecture. He was working with IBM at the time and said that yes, both IBM and Intel had plans for these architectures, but neither ended up going anywhere. Sure, it would be cool, but I don't think it would be the best business plan for the companies.

Intel didn't create the first 32-bit processor, nor did AMD create the first 64-bit processor.

There are many (..arguably better) architectures out there that existed long before Intel's offerings, some people were using such 'powerful' systems while the rest of us only had 8/16-bit microcomputers.

As for this specific architecture, it looks downright ridiculous.. be glad it's dead.

I haven't said it but this is the first not 80x86 32 processor designed (I ommited by Intel). Now it sound better?
However I don't share your opinion. According to this a lots of thing (and programming languages) now shouldn't be used

Karlosoft wrote:I haven't said it but this is the first not 80x86 32 processor designed (I ommited by Intel). Now it sound better?
However I don't share your opinion. According to this a lots of thing (and programming languages) now shouldn't be used

Actually it was created before the 386 according to wikipedia.. so it was Intel's first 32bit processor period. (Actually I think Intel had some server product that was running 32 bit before then but idk)

Interestingly, ARM, commonly considered a modern architecture, predates the 386

(That doesn't preclude it being more modern than the rather esoteric x86)

Owen wrote:Interestingly, ARM, commonly considered a modern architecture, predates the 386.

Just like Microsoft didn't invent most (any?) of the things they market so successfully, Intel wasn't the frontrunner it's sometimes perceived as.

Motorola 68000, 16/32bit, 1979.
Intel 80286, 16bit, 1982.
Motorola 68020, 32bit, 1984.
MIPS R2000, 32bit, 1985.
Intel 80386, 32bit, 1985.
ARM2, 32bit, 1986.
SPARC v7, 32bit, 1986.
MIPS R4000, 64bit, 1991.
DECAlpha EV4, 64bit, 1992.
SPARC v9, 64bit, 1993.
Intel Itanium, 64bit, 2001.
AMD64 Opteron, 64bit, 2003.

Though, to their credit, the 4004 was the first mass-manufactured microprocessor

(BTW: ARMs outnumber x86 CPUs in the world 100 to 1)

Owen wrote:Though, to their credit, the 4004 was the first mass-manufactured microprocessor

Yes, but Unix ran on the 16-bit PDP-11/20 microcomputer in 1970, one year before the 4004 microprocessor.

Brynet-Inc wrote:Yes, but Unix ran on the 16-bit PDP-11/20 microcomputer in 1970, one year before the 4004 microprocessor.

Yes, but how does that make Intel's glory dimmer?

fronty wrote:Yes, but how does that make Intel's glory dimmer?

I've been sworn to secrecy, no comment.

fronty wrote:

Brynet-Inc wrote:Yes, but Unix ran on the 16-bit PDP-11/20 microcomputer in 1970, one year before the 4004 microprocessor.

Yes, but how does that make Intel's glory dimmer?

That they're still manufacturing 4004 backward compatible processors today*

* Using a couple of tools, you can convert your 4004 assembly to 8008 assembly, to 8080 assembly, to 8086 assembly - Intel explicitly designed them this way

Owen wrote:

fronty wrote:

Brynet-Inc wrote:Yes, but Unix ran on the 16-bit PDP-11/20 microcomputer in 1970, one year before the 4004 microprocessor.

Yes, but how does that make Intel's glory dimmer?

That they're still manufacturing 4004 backward compatible processors today*

* Using a couple of tools, you can convert your 4004 assembly to 8008 assembly, to 8080 assembly, to 8086 assembly - Intel explicitly designed them this way

And this is why the x86 arch. is getting uglier every year. It's still mildly backwards compatible with a processor from 1971.

Is it really getting uglier? Take x86-64 for instance. Just because you *can* run in the legacy protected mode doesn't mean you can't treat the CPU as being something completely new. Backward compatibility in this sense is a feature, not a headache. Just write a 64-bit OS. If you had 2 separate architectures you'd go through pretty much the same trouble.

Also, there are a lot of processors in the world, some for instance running on Java bytecode. The reason why they don't always make it is performance and/or backward/forward compatibility with applications. As Brendan has noted in at least one of his latest posts, the x86 has lived so far because it provided backward compatibility. People want that, yes!

At the level of transistors on silicon, yes, it's getting lots uglier. Even at the software level, it's getting a little uglier. As intel adds modes, there have to be new registers and techniques to allow you to change between modes. Yes, people want backwards compatibility for awhile -- but the demand fades over time. It is also true that from an engineering standpoint, you always reach a point with every product where it could benefit greatly by reengineering it from the bottom up. If the tradeoff were backwards compatibility vs. 4 times the speed, more people would switch.