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)

[Sunil Amitkumar Janki <psychicistnonconformist@gmail.com>]

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
> EV67@667Mhz 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