PPC, MIPS, Alpha, IA64 and i860 i believe... What do all these have in common? Noone used them.
At the time, these architectures offered vastly superior performance to x86, but couldn't run legacy windows apps or legacy apps designed for other OS that typically ran on the hardware. Since there were so few users, virtually no commercial software was ever ported to non x86 windows and very few people ever even bothered to port open source code to them.
MS' biggest strength - proprietary lockin, is also their biggest weakness... If your going to move to an incompatible hardware platform, and lose access to your legacy software in the process then you'd be a fool to run windows... Linux already runs on ARM, will not lock you in like windows is designed to, costs nothing, and already runs 99% of the same software the x86 version does.
And ofcourse if everyone is running open source code, the architecture becomes irrelevant and we can switch again very easily if something better than ARM comes along. It's also possible to have a range of architectures for different purposes, ARM or MIPS for low power devices, perhaps x86, IA64 or Alpha for high performance devices where power usage isn't a concern.
I used NT4 on Alpha - there were even beta copies of Windows 2000 for the Alpha. It also had FX!32 which was fairly decent at allowing x86 binaries to run under Alpha NT4 which meant companies didn't need to port software specifically for the Alpha.
That still didn't bring the fastest processor architechture into mainstream use- even when it was only slightly more expensive and FX!32 offered compelling performance for the platform. There's a hint there.
But key is, did it run x86 software faster? Running it through something like, FX!32, it would have to quite a bit faster than x86 to best x86 at x86.
So in affect, it was more expensive , slower, processor because all the apps where x86.
FX!32 allowed software to *run*, but it didn't run very fast which negated the performance advantage of the Alpha. If your apps weren't Alpha native, then you might as well buy cheaper x86 hardware to achieve a similar performance level.
Exactly! Historically, Intel does not have a great track record at succeeding in the marketplace with new architectures.
If we just go with Intel:
i432 Super Object Oriented - lots of transistors, super CISCy. Very slow too, but probably could have been sped up decently (half the problem was the compiler and lack of caches) i860 - Very fast for it's day as long as you don't need to respond to a trap or interrupt... Evil to program. Great for an accelerator but not a great general purpose CPU i960 - This on
Itanium failed due to closed source binary software...
Only the original vendor can produce a port to a new architecture.
10 Original vendor, being a for-profit business sees no profit in porting to a new architecture that has no users. 20 Users see no reason to buy an architecture that has no software available for it. 30 goto 10
Any new architecture is pretty much doomed to failure in the general purpose market, even one backed by someone as big as Intel.
You certainly need a 'critical mass' for a new architecture to sell, but it's not all doom and gloom for the other players. We mostly don't write in assembler nowadays. We use compilers. If a good compiler is produced, and made available at a reasonable cost, and a vendor believes a port will be profitable in terms of amortizing the full lifecycle cost of the port then they may port.
To generalize - consider architecture A with resources rA applied to it achieves a performance (either raw or per watt) of pA.
This is why MS are pushing.NET, moves them away from being in a death embrace with x86 (that and it gives a complete platform to lock people into).
I see byte code as a way closed source code can get the "run on anything" of open source, without opening the source.
With open source, you just compile it on the platform in question (ok it is more than that, but can be that).
If you have the source, and it's in the repository specific for a processor (and why not, not that many types of processors), why not j
After Goliath's defeat, giants ceased to command respect.
- Freeman Dyson
first full bodied nonx86? (Score:1)
Don't want to spoil the act, but historically there were several non x86 versions of windows nt before (dec alpha comes to my mind, and others...)
Re:first full bodied nonx86? (Score:4, Insightful)
PPC, MIPS, Alpha, IA64 and i860 i believe...
What do all these have in common? Noone used them.
At the time, these architectures offered vastly superior performance to x86, but couldn't run legacy windows apps or legacy apps designed for other OS that typically ran on the hardware. Since there were so few users, virtually no commercial software was ever ported to non x86 windows and very few people ever even bothered to port open source code to them.
MS' biggest strength - proprietary lockin, is also their biggest weakness...
If your going to move to an incompatible hardware platform, and lose access to your legacy software in the process then you'd be a fool to run windows... Linux already runs on ARM, will not lock you in like windows is designed to, costs nothing, and already runs 99% of the same software the x86 version does.
And ofcourse if everyone is running open source code, the architecture becomes irrelevant and we can switch again very easily if something better than ARM comes along.
It's also possible to have a range of architectures for different purposes, ARM or MIPS for low power devices, perhaps x86, IA64 or Alpha for high performance devices where power usage isn't a concern.
Re: (Score:3)
I used NT4 on Alpha - there were even beta copies of Windows 2000 for the Alpha.
It also had FX!32 which was fairly decent at allowing x86 binaries to run under Alpha NT4 which meant companies didn't need to port software specifically for the Alpha.
Re: (Score:2)
That still didn't bring the fastest processor architechture into mainstream use- even when it was only slightly more expensive and FX!32 offered compelling performance for the platform. There's a hint there.
Re: (Score:2)
Re: (Score:2)
I still have the msdn windows 2k beta version for alpha. :) runs great!
Re: (Score:2)
FX!32 allowed software to *run*, but it didn't run very fast which negated the performance advantage of the Alpha. If your apps weren't Alpha native, then you might as well buy cheaper x86 hardware to achieve a similar performance level.
Re: (Score:2)
Exactly! Historically, Intel does not have a great track record at succeeding in the marketplace with new architectures.
If we just go with Intel:
i432 Super Object Oriented - lots of transistors, super CISCy. Very slow too, but probably could have been sped up decently (half the problem was the compiler and lack of caches)
i860 - Very fast for it's day as long as you don't need to respond to a trap or interrupt... Evil to program. Great for an accelerator but not a great general purpose CPU
i960 - This on
Re: (Score:2)
Itanium failed due to closed source binary software...
Only the original vendor can produce a port to a new architecture.
10 Original vendor, being a for-profit business sees no profit in porting to a new architecture that has no users.
20 Users see no reason to buy an architecture that has no software available for it.
30 goto 10
Any new architecture is pretty much doomed to failure in the general purpose market, even one backed by someone as big as Intel.
Re: (Score:1)
You certainly need a 'critical mass' for a new architecture to sell, but it's not all doom and gloom for the other players. We mostly don't write in assembler nowadays. We use compilers. If a good compiler is produced, and made available at a reasonable cost, and a vendor believes a port will be profitable in terms of amortizing the full lifecycle cost of the port then they may port.
To generalize - consider architecture A with resources rA applied to it achieves a performance (either raw or per watt) of pA.
Re: (Score:2)
I see byte code as a way closed source code can get the "run on anything" of open source, without opening the source.
With open source, you just compile it on the platform in question (ok it is more than that, but can be that).
If you have the source, and it's in the repository specific for a processor (and why not, not that many types of processors), why not j