On Mon, 10 Dec 2012 20:06:58 +0000 (UTC) Grant Edwards <grant.b.edwa...@gmail.com> wrote:
> On 2012-12-10, Alan McKinnon <alan.mckin...@gmail.com> wrote: > > On Mon, 10 Dec 2012 19:06:36 +0000 (UTC) > > Grant Edwards <grant.b.edwa...@gmail.com> wrote: > > > >> On 2012-12-10, Volker Armin Hemmann <volkerar...@googlemail.com> > >> wrote: > >> > Am Samstag, 8. Dezember 2012, 19:25:55 schrieb Grant: > >> > > >> >> It seems like ARM processors will destroy x86 before too long. > >> >> Does anyone think this won't happen? > >> > > >> > no > >> > > >> > two reasons: > >> > > >> > not enough power > >> > does not run x86 software > >> > > >> > the second one is a real deal breaker. > >> > >> Only until somebody invents some sort of scheme where you can > >> write a program using a source language that isn't tied directly > >> to the processor architecture. Then you'd be able to build > >> programs (or even OS kernels) so that they'd run on a variety of > >> CPU architectures! > > > > We can do that *already* > > > > java > > perl > > python > > dotnet > > and any number of other languages compiled to bytecode. There's too > > many to list. > > I know. :) > > And even if you stick with old-school compiled languages to C, > supporting multiple architectures isn't any more difficult than > supporting the plethora of x86-based motherboards and chipsets. > > * Apple transitioned from 68K to PPC to x86 without much problem, > and they don't seem to have any problem getting software to run on > ARM devices. Apple tightly controls the entire computer end-to-end and they know *exactly* what is already on the user's machine: How many kinds of video cards: 1 How many kinds of screens: 1 How many drive types: 1 How many optical drive types: 1 How many boot methods: 1 I could go on, but you get the point. The larger part of the variable factors simply don't exist for Apple to the same degree faced by Windows and Linux. This makes a migration several orders of magnitude easier for Apple. > > * Linux is available for non x86 platforms. :) Only by a monumental crowd-source effort never before witnessed in the history of engineering. When Apple migrate CPUs (they have now done it three times), they tweak a few compile settings, write a few new drivers for new hardware, and run make. A surprisingly large chunk of the code base builds fine. A relatively small team takes care of the rest. The same action on Linux takes somewhat longer, and considerably more effort while the vast army of suckers^Wvolunteers and concentrate on their little bit while waiting for the reverse-engineering lads to finish doing their thing. > > Nobody has developed significant applications in assembly language for > decades, so I don't see why there's a requirement to "run x86 > software"... I don't get your point. Are you talking about code finely-hand-tuned to run on a specific cpu? The kinds of software the average user really wants to run are very much tied to the hardware: kernel drivers boot code media players codecs It's true we don't hand tune each app to the cpu anymore, we hand tune the compiler to the cpu. > I use a couple of large, commerical Java apps under Linux and they > both work great. OTOH, some of the smaller "free" Java apps I've > tried were pretty bad... I'm not sure what you mean by this. Code quality varies, this is always true. The best quality proprietary code I've experienced was from Sybase. The worst quality proprieatry code I've experienced was from Oracle. This doesn't prove anything except that maybe when you bedazzle bean counters you can get away with anything... -- Alan McKinnon alan.mckin...@gmail.com
