qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] 0.9.0 and svn don't build with -march=pentium2 etc.; w


From: Sunil Amitkumar Janki
Subject: Re: [Qemu-devel] 0.9.0 and svn don't build with -march=pentium2 etc.; was: Latest SVN fails to build on Fedora Core 6 (same with 0.9.0)
Date: Thu, 29 Mar 2007 17:25:47 +0200
User-agent: Thunderbird 1.5.0.10 (X11/20070221)

Thomas Orgis wrote:
Sure, 32bit is vanishing from new hardware sales.


You can hardly buy a 32-bit AMD chip anymore and I wouldn't buy a 32-bit Intel
chip when you can get a 64-bit AMD for the same price or less.


So for me, 32 bits are the state-of-the art, apart from my two machines at work,
which are Compaq XP1000's being 64 bit all-over, but as astonishing an
address@hidden still can be at crunching floating point numbers, it's not a host
for qemu VMs (esp. since it cannot use kqemu to accelerate x86 code ... hm,
would qemu/kqemu work to run Tru64 accelerated in a vm on alpha?;-).



So it is for me, please don't think I advocate having the latest and the greatest at
all times. I tend to run my computers as long as possible, changing broken
components one at a time to keep expenses low. My Dell Latitude C600 laptop
, which was used when I bought it, is almost six years old and still going strong.

Lately I have had some people coming to me to repair their broken systems and as it is hard to find or justify 32-bit hardware anymore I just built AMD Semprons and Athlon64s into them. It was the cheapest solution apart from putting together
used parts.

And a few of my older systems are starting to fail as well, so I'll have to gradually replace them as well. I have some older 486 and Pentiums lying around here but they are collecting dust until I find a new function for them. The Pentiums are useful
with Windowmaker or some other lightweight windowmanager.

Last year I bought some older Compaq Pentium II/III's, put some memory in them, added an older hard disk drive and Linux and their life is extended that way. So I'm not really new to getting more life out of older hardware. As long as it's still sold, possibly second-hand, 32-bit x86 will stay relevant, but it's not where the action is
anymore (except for Intel clearing out their "obsolete" stock).

About the Alphas, it would be great to run Tru64 on them or for the occasional OpenVMS session. I'm looking forward to implementing an Alpha target even though I've never seen or used them. You must be very lucky to have them at your disposal.

And I'm also very much intrigued by a PA-RISC target, not least because HP-(S)UX was the platform I learned Autocad and Pro-Engineer on. Thankfully I never got to
use those on Windows.

But I'm very new to this QEMU thing, so don't expect too much soon. I'm reading through the architecture manuals and trying to figure out how to implement QEMU
targets for both of them.

QEMU's internals seem to have some pretty steep prerequisites as someone else on this list noticed and it all looks pretty cryptic to me anyways, but I'm trying. That's the most important thing free software has taught me: If it doesn't work
first time, try again and again until it's clear and works!

Well, I don't intend to run qemu on these old systems, and I only do it casually
on my ThinkPad to test some software under a different OS.
Sure, if becoming a qemu power user with several VMs doing work and
compiling stuff, I'd think about becoming a dual/quad AMD64 user.


Yes but we are reaching the tipping point where Linux and the BSDs are
THE major general purpose operating systems to run on any hardware.
So the exact processor architecture in general will not matter for software
availability in the future, except for closed source software.

To put it another way, you can choose the hardware architecture
that runs your software best. All available hardware is fast enough
to run Linux. Call it post-x86 if you will.

On that edge, though, qemu should find a way to arrange with current
gcc versions... gcc3.4 won't hold forever.


Thomas.


I concur that it will be increasingly difficult to keep a gcc 3.4 compiler around
for QEMU. So the port to gcc4 will have to be done, now that even Slackware
is adopting gcc 4.1.2.

Sunil






reply via email to

[Prev in Thread] Current Thread [Next in Thread]