Re: [Qemu-devel] Latest SVN fails to build on Fedora Core 6 (same with 0.9.0)

Re: [Qemu-devel] Latest SVN fails to build on Fedora Core 6 (same with 0.9.0)

[Thomas Orgis]

I'd like to add that with qemu 0.9.0 release it's the same problem,
that somehow seems to recurr from time to time (seen old similar
reports with older qemu release(s)) in helper.c.

We at SourceMage GNU/Linux got reports of failed builds with that error
that are apparently fixed by reducing -march cflag to pentium-mmx as
opposed to pentium2,3,4 or pentium-m as well as any athlon.
Any sse flags also seem to trigger this error.
qemu 0.8.6 built without probs with -march=pentium-m, for example (we
still use the same compiler gcc-3.4.6 for this).

There's a thread on the user forum, too:
http://qemu-forum.ipi.fi/viewtopic.php?p=10045#10045

Is there actually some policy on CFLAGS settings? I didn't find a FAQ
like "do not set any -march other than the most basic, qemu performance
is ruled by hand-crafted assembler anyway and -msse won't also not
help anything" .. should there be one?
I guess there is something hand-crafted fighting with gcc over
registers...


Thomas.

Re: [Qemu-devel] Latest SVN fails to build on Fedora Core 6 (same with 0.9.0)

[Tony Nelson]

At 2:37 PM +0100 3/17/07, Thomas Orgis wrote:
>I'd like to add that with qemu 0.9.0 release it's the same problem,
>that somehow seems to recurr from time to time (seen old similar
>reports with older qemu release(s)) in helper.c.
>
>We at SourceMage GNU/Linux got reports of failed builds with that error
>that are apparently fixed by reducing -march cflag to pentium-mmx as
>opposed to pentium2,3,4 or pentium-m as well as any athlon.
>Any sse flags also seem to trigger this error.
>qemu 0.8.6 built without probs with -march=pentium-m, for example (we
>still use the same compiler gcc-3.4.6 for this).
 ...

Could this be caused by having a 586 kernel installed?  There's a bug in
FC6 anaconda that causes it to sometimes install the 586 kernel when it
should have installed the 686 kernel.  The fix is to install the 686 kernel.
-- 
____________________________________________________________________
TonyN.:'                       <mailto:tonynelson@georgeanelson.com>
      '                              <http://www.georgeanelson.com/>

Re: [Qemu-devel] Latest SVN fails to build on Fedora Core 6 (same with 0.9.0)

[Thomas Orgis]

Am Sun, 18 Mar 2007 00:45:00 -0400
schrieb Tony Nelson <tonynelson@georgeanelson.com>: 

> >We at SourceMage GNU/Linux got reports of failed builds with that error
> >that are apparently fixed by reducing -march cflag to pentium-mmx as
> >opposed to pentium2,3,4 or pentium-m as well as any athlon.
> >Any sse flags also seem to trigger this error.
> >qemu 0.8.6 built without probs with -march=pentium-m, for example (we
> >still use the same compiler gcc-3.4.6 for this).

> Could this be caused by having a 586 kernel installed?  There's a bug in
> FC6 anaconda that causes it to sometimes install the 586 kernel when it
> should have installed the 686 kernel.  The fix is to install the 686 kernel.

Now that surprises me. The chosen cpu setting for the kernel triggers
an error in _compiling_ qemu?
Or is this a special bug with the Fedora i586 kernel?

Well, my laptop system, where this also is reproducable, is totally
compiled with -march=pentium-m and the kernel is configured for a
Pentium-M.

Do you have more information on how the kernel triggering this is
possible? And why it is happening with wemu-0.9.0 but not with 0.8.6?


Thomas.

Re: [Qemu-devel] Latest SVN fails to build on Fedora Core 6 (same with 0.9.0)

[Nigel Horne]

[-- Attachment #1: Type: text/plain, Size: 566 bytes --]


>> Could this be caused by having a 586 kernel installed?  There's a bug in
>> FC6 anaconda that causes it to sometimes install the 586 kernel when it
>> should have installed the 686 kernel.  The fix is to install the 686 kernel.

The first part is true, the second is not, in that I already upgraded
to the 686 kernel, so the qemu build on FC6 is not fixed by installing the 686 kernel.

-Nigel

-- 
Nigel Horne. Arranger, Adjudicator, Band Trainer, Composer, Tutor, Typesetter.
NJH Music, Barnsley, UK.  ICQ#20252325
njh@bandsman.co.uk http://www.bandsman.co.uk

[-- Attachment #2: njh.vcf --]
[-- Type: text/x-vcard, Size: 181 bytes --]

begin:vcard
fn:Nigel Horne
n:Horne;Nigel
org:NJH Music
email;internet:njh@bandsman.co.uk
tel;fax:+44 870 705 9334
note:Skype: nigelhorne
x-mozilla-html:FALSE
version:2.1
end:vcard

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)

[Thomas Orgis]

Am Sun, 18 Mar 2007 09:18:40 +0000
schrieb Nigel Horne <njh@bandsman.co.uk>: 

> The first part is true, the second is not, in that I already upgraded
> to the 686 kernel, so the qemu build on FC6 is not fixed by installing the 686 kernel.

So, do we have any other clue about this?
Some qemu coder knows anything about this error?

> /opt/gcc34/bin/gcc -march=pentium2 -Wall -O2 -g -fno-strict-aliasing
> -fomit-frame-pointer -I. -I.. -I/usr/src/qemu-0.9.0/target-i386
> -I/usr/src/qemu-0.9.0 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
> -D_LARGEFILE_SOURCE -I/usr/src/qemu-0.9.0/fpu -DHAS_AUDIO
> -I/usr/src/qemu-0.9.0/slirp  -c -o
> helper.o /usr/src/qemu-0.9.0/target-i386/helper.c ../softmmu_template.h:
> In function `__stq_mmu': ../softmmu_template.h:260: error: unable to
> find a register to spill in class
> `GENERAL_REGS' ../softmmu_template.h:260: error: this is the insn:
> (insn:HI 365 364 366 13 ../softmmu_template.h:290 (parallel [ (set
> (reg:DI 0 ax [216]) (lshiftrt:DI (reg/v:DI 59 [ val ]) (subreg:QI
> (reg:SI 0 ax [215]) 0))) (clobber (scratch:SI)) (clobber (reg:CC 17
> flags)) ]) 309 {lshrdi3_1} (insn_list 364 (nil)) (expr_list:REG_DEAD
> (reg:SI 0 ax [215]) (expr_list:REG_UNUSED (reg:CC 17 flags)
> (expr_list:REG_UNUSED (scratch:SI) (nil)))))
> ../softmmu_template.h:260: confused by earlier errors, bailing out

It is really persistent with any pentium/athlon march setting above
pentium-mmx and alone with the -msse flag.
If the answer is "Do Not Use GCC Arch Setting" then it would be nice to
have it spelled out by someone else than me... of course I'd prefer
this thing to work;-)


Thomas.

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]

Thomas Orgis wrote:
> Am Sun, 18 Mar 2007 09:18:40 +0000
> schrieb Nigel Horne <njh@bandsman.co.uk>: 
>
>   
>> The first part is true, the second is not, in that I already upgraded
>> to the 686 kernel, so the qemu build on FC6 is not fixed by installing the 686 kernel.
>>     
>
> So, do we have any other clue about this?
> Some qemu coder knows anything about this error?
>
>   
>> /opt/gcc34/bin/gcc -march=pentium2 -Wall -O2 -g -fno-strict-aliasing
>> -fomit-frame-pointer -I. -I.. -I/usr/src/qemu-0.9.0/target-i386
>> -I/usr/src/qemu-0.9.0 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
>> -D_LARGEFILE_SOURCE -I/usr/src/qemu-0.9.0/fpu -DHAS_AUDIO
>> -I/usr/src/qemu-0.9.0/slirp  -c -o
>> helper.o /usr/src/qemu-0.9.0/target-i386/helper.c ../softmmu_template.h:
>> In function `__stq_mmu': ../softmmu_template.h:260: error: unable to
>> find a register to spill in class
>> `GENERAL_REGS' ../softmmu_template.h:260: error: this is the insn:
>> (insn:HI 365 364 366 13 ../softmmu_template.h:290 (parallel [ (set
>> (reg:DI 0 ax [216]) (lshiftrt:DI (reg/v:DI 59 [ val ]) (subreg:QI
>> (reg:SI 0 ax [215]) 0))) (clobber (scratch:SI)) (clobber (reg:CC 17
>> flags)) ]) 309 {lshrdi3_1} (insn_list 364 (nil)) (expr_list:REG_DEAD
>> (reg:SI 0 ax [215]) (expr_list:REG_UNUSED (reg:CC 17 flags)
>> (expr_list:REG_UNUSED (scratch:SI) (nil)))))
>> ../softmmu_template.h:260: confused by earlier errors, bailing out
>>     
>
> It is really persistent with any pentium/athlon march setting above
> pentium-mmx and alone with the -msse flag.
> If the answer is "Do Not Use GCC Arch Setting" then it would be nice to
> have it spelled out by someone else than me... of course I'd prefer
> this thing to work;-)
>
>
> Thomas.
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>   
I have seen this error as well when building with i686/pentium3/athlon
optimisations. As I am doing a course on x86 assembly programming
at the moment I can tell you that it suffers from register starvation
and the message tells you that there aren't enough registers left.

That's why I build QEMU on x86 with "-O2 -march=i486 -mtune=i686".

I am not a QEMU developer (yet!) but I am using it at the moment to
emulate SPARC, ARM and MIPS(EL) to build Linux executables natively
in (Slackware) Linux distributions for those architectures.

I hope to start contributing to PPC and Alpha emulation when I understand
more about QEMU's internal architecture.

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)

[Thomas Orgis]

Am Thu, 22 Mar 2007 21:13:00 +0100
schrieb Sunil Amitkumar Janki <psychicistnonconformist@gmail.com>: 

> I have seen this error as well when building with i686/pentium3/athlon
> optimisations. As I am doing a course on x86 assembly programming
> at the moment I can tell you that it suffers from register starvation
> and the message tells you that there aren't enough registers left.

Yeah, that's the message... what I wonder is this is to be expected.
Does SSE steal or add registers?
-march=pentium-mmx -m3dnow
seems to work, though. Is it just a coincidence that gcc optimizattion
uses some registers with high march (and SSE) that it didn't use with lower march?
I'm wondering if it's the code that is just lucky to compile with some
march settings and not so lucky with others or if it's a gcc bug or
whatever...


Thomas.

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]

Thomas Orgis wrote:
> Am Thu, 22 Mar 2007 21:13:00 +0100
> schrieb Sunil Amitkumar Janki <psychicistnonconformist@gmail.com>: 
>
>   
>> I have seen this error as well when building with i686/pentium3/athlon
>> optimisations. As I am doing a course on x86 assembly programming
>> at the moment I can tell you that it suffers from register starvation
>> and the message tells you that there aren't enough registers left.
>>     
>
> Yeah, that's the message... what I wonder is this is to be expected.
> Does SSE steal or add registers?
> -march=pentium-mmx -m3dnow
> seems to work, though. Is it just a coincidence that gcc optimizattion
> uses some registers with high march (and SSE) that it didn't use with lower march?
> I'm wondering if it's the code that is just lucky to compile with some
> march settings and not so lucky with others or if it's a gcc bug or
> whatever...
>
>
> Thomas.
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>   
The reason I build it with "-march=i486" is because Pentium optimisations
are really only meant for real Intel Pentium (MMX) and not for AMD K6 
(I/II/II).

You would probably be better off using "-march=k6-* -m3dnow -mmx" for
an Athlon. I have seen my Athlon slowing to a grind with a Pentium kernel
instead of an i486 or Athlon kernel.

I do not understand enough of QEMU yet, but I have checked out CVS and
am reading through its source. When I understand more I hope we can fix
this long-standing annoyance.

Do you have a 64-bit  X86 processor running 64-bit software? It doesn't
seem to suffer from this same problem. I am testing on an AMD Athlon 64
X2 (AM2) now and QEMU works with "-march=opteron" and of course KVM.

Sunil.

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)

[Paul Brook]

> I do not understand enough of QEMU yet, but I have checked out CVS and
> am reading through its source. When I understand more I hope we can fix
> this long-standing annoyance.

This is GCC PR16185 <http://gcc.gnu.org/PR16185>.
There's no fundamental reason why some options trigger it, and others don't. 
It trigerrs fairly randomly depending on the code generation choices gcc 
happens to make.

The problem is that x86 is chronically short of registers. qemu makes this 
significantly worse by telling gcc it can't use most of them. gcc simply 
isn't designed to work in these extreme situations.

Paul

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)

[Thomas Orgis]

Am Fri, 23 Mar 2007 15:45:49 +0000
schrieb Paul Brook <paul@codesourcery.com>: 

> > I do not understand enough of QEMU yet, but I have checked out CVS and
> > am reading through its source. When I understand more I hope we can fix
> > this long-standing annoyance.
> 
> This is GCC PR16185 <http://gcc.gnu.org/PR16185>.

Hm, I think I stumbled over this before... so it is still valid.

> There's no fundamental reason why some options trigger it, and others don't. 
> It trigerrs fairly randomly depending on the code generation choices gcc 
> happens to make.

So it is indeed the case that nothing particular in qemu triggers it,
just the general grab on the registers.
And it is something that won't be fixed anytime soon (in gcc), apart
from ia32 going out of use...
Personally, I started using qemu with my Pentium-M 1.4GHz laptop... so
32bit is the way there for a few years.
So I'll check for every new qemu release and gcc version if it perhaps
builds with normal optimization settings... or one identifies a spot to
release a register for x86 where it doesn't hurt qemu (since it's 
always softmmu_template.h with helper.c).

Anyway, this sounds more and more like a FAQ entry.
Perhaps it should be mentioned in qemu docs.

> 
> The problem is that x86 is chronically short of registers. qemu makes this 
> significantly worse by telling gcc it can't use most of them. gcc simply 
> isn't designed to work in these extreme situations.

Yep, x86 is chronically short of many things and loaded with others.
At work I secured two good old XP1000 alphas for myself...
they're not really as fast as my laptop, but register starvation is nothing
I expect to happen there. They got .. hm, what's the correct term... 
a shitload of registers! ;-)
x86 really was the worst arch to become market leader for home computing.
On the other hand that leadership was what made the arch mutate in the
ways it did.


Thomas.

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]

Thomas Orgis wrote:
> Am Fri, 23 Mar 2007 15:45:49 +0000
> schrieb Paul Brook <paul@codesourcery.com>: 
>
>   
>>> I do not understand enough of QEMU yet, but I have checked out CVS and
>>> am reading through its source. When I understand more I hope we can fix
>>> this long-standing annoyance.
>>>       
>> This is GCC PR16185 <http://gcc.gnu.org/PR16185>.
>>     
>
> Hm, I think I stumbled over this before... so it is still valid.
>
>   
>> There's no fundamental reason why some options trigger it, and others don't. 
>> It trigerrs fairly randomly depending on the code generation choices gcc 
>> happens to make.
>>     
>
> So it is indeed the case that nothing particular in qemu triggers it,
> just the general grab on the registers.
> And it is something that won't be fixed anytime soon (in gcc), apart
> from ia32 going out of use...
> Personally, I started using qemu with my Pentium-M 1.4GHz laptop... so
> 32bit is the way there for a few years.
> So I'll check for every new qemu release and gcc version if it perhaps
> builds with normal optimization settings... or one identifies a spot to
> release a register for x86 where it doesn't hurt qemu (since it's 
> always softmmu_template.h with helper.c).
>
> Anyway, this sounds more and more like a FAQ entry.
> Perhaps it should be mentioned in qemu docs.
>
>   
>> The problem is that x86 is chronically short of registers. qemu makes this 
>> significantly worse by telling gcc it can't use most of them. gcc simply 
>> isn't designed to work in these extreme situations.
>>     
>
> Yep, x86 is chronically short of many things and loaded with others.
> At work I secured two good old XP1000 alphas for myself...
> they're not really as fast as my laptop, but register starvation is nothing
> I expect to happen there. They got .. hm, what's the correct term... 
> a shitload of registers! ;-)
> x86 really was the worst arch to become market leader for home computing.
> On the other hand that leadership was what made the arch mutate in the
> ways it did.
>
>
> Thomas.
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>   
As far as X86 is concerned i386/i486/i586 are very different from later 
generation
processors. I am wondering whether another host and target architecture 
could be
created called i686 that makes use of something like MMX or other 
registers in Intel
Pentium II/III/4 and AMD Athlon to negate the lack of general purpose 
registers. In a
certain sense i486 compatibility holds back the options you have for 
optimisation.

The fact that QEMU works and can be optimised on x86_64 is the only 
saving grace
for the architecture, that is still suffering from a lack of registers 
compared to any
other architecture.

Anyhow, I expect 32-bit hardware to gradually die because of wear and 
tear in the
next few years and the replacement will be 64-bit hardware so the 
problem will solve
itself that way.

Sunil.

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)

[Julian Seward]

> As far as X86 is concerned i386/i486/i586 are very different from later
> generation
> processors. I am wondering whether another host and target architecture
> could be
> created called i686 that makes use of something like MMX or other
> registers in Intel
> Pentium II/III/4 and AMD Athlon to negate the lack of general purpose
> registers.

I don't see how.  MMX/SSE is suitable for SIMD processing of media data
and to some extent for floating point, but is largely unusable for ad-hoc
integer computation, especially anything that involves address calculations.

> The fact that QEMU works and can be optimised on x86_64 is the only
> saving grace
> for the architecture, that is still suffering from a lack of registers
> compared to any
> other architecture.

The lack of registers isn't ideal, but it's not a big deal, and in the
grand scheme of things x86_64 has a lot going for it.  The most 
important of which are that (from the software side) all the hard-won 
knowledge of how to compile good code for x86 carries across more or less
directly to x86_64, and (from the hardware side) hardware people already
know how to make fast, cheap x86s, so it's easy to move to making fast,
cheap x86_64s.

The problems of the gcc backend to qemu have already been discussed
extensively on this list.  Stealing 3+ registers from gcc on x86 really
is asking for trouble, and I believe it is generally understood that the
best long term solution is to move to a self-contained back end that 
does not use gcc for dynamic code generation.

J

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)

[Thomas Orgis]

Am Sat, 24 Mar 2007 12:55:16 +0000
schrieb Julian Seward <jseward@acm.org>: 

> The problems of the gcc backend to qemu have already been discussed
> extensively on this list.  Stealing 3+ registers from gcc on x86 really
> is asking for trouble, and I believe it is generally understood that the
> best long term solution is to move to a self-contained back end that 
> does not use gcc for dynamic code generation.

An innocent question: Would _not_ stealing 3 registers be a short term option?
I am still quite new to qemu (as a user, even) so I don't really know anything
about the dynamic code generation and what affects qemu performance anyway.


Thomas.

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)

[Rob Landley]

On Saturday 24 March 2007 8:32 am, Sunil Amitkumar Janki wrote:
> Anyhow, I expect 32-bit hardware to gradually die because of wear and 
> tear in the next few years and the replacement will be 64-bit hardware so
> the problem will solve itself that way.

Specifically, in 2008 32-bit x86 hardware both drops below 50% of the 
installed base and stops being a commercial viable option for new sales in 
the desktop or laptop space.  (Eric Raymond and I did research about this, 
and made a table and everything. :)

http://www.catb.org/~esr/writings/world-domination/world-domination-201.html#id248066

Rob
-- 
Vista: Windows Millenium Second Edition

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)

[Thomas Orgis]

Am Wed, 28 Mar 2007 15:56:59 -0400
schrieb Rob Landley <rob@landley.net>: 

> On Saturday 24 March 2007 8:32 am, Sunil Amitkumar Janki wrote:
> > Anyhow, I expect 32-bit hardware to gradually die because of wear and 
> > tear in the next few years and the replacement will be 64-bit hardware so
> > the problem will solve itself that way.
> 
> Specifically, in 2008 32-bit x86 hardware both drops below 50% of the 
> installed base and stops being a commercial viable option for new sales in 
> the desktop or laptop space.

Sure, 32bit is vanishing from new hardware sales.
But I got my first machine that is able to decentnly run qemu just half a year ago:
A used ThinkPad. I didn't buy a new computer system since my very first system
in 1995 (which had to return to shop because they put a broken video card in...
grmbl).
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?;-).

And... I don't expect the 32bit hardware to die because of "wear and tear",
especially when thinking of the i486DX4 that handles my DSL NAT routing needs,
or about the Pentium 100 serving as music jukebox;-)
Not to forget a i386DX40 that still just works fine when I decide to power it up.

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.

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


Thomas.

[Qemu-devel] QEMU Alpha target

[Stuart Brady]

On Thu, Mar 29, 2007 at 12:55:54PM +0200, Thomas Orgis wrote:

> hm, would qemu/kqemu work to run Tru64 accelerated in a vm on
> alpha?;-).

:-)

There do seem to be a few people who'd like Alpha emulation for QEMU.
Obviously, you'd want to get dynamic translation working first. :-)

OTOH, I'm now wondering which archs can support full virtualisation.
-- 
Stuart Brady

Re: [Qemu-devel] QEMU Alpha target

[Paul Brook]

> There do seem to be a few people who'd like Alpha emulation for QEMU.
> Obviously, you'd want to get dynamic translation working first. :-)
>
> OTOH, I'm now wondering which archs can support full virtualisation.

Depends how you define "full virtualization". If you call kqemu full 
virtualization then you can do that on pretty much any CPU.

Paul

Re: [Qemu-devel] QEMU Alpha target

[Stuart Brady]

On Thu, Mar 29, 2007 at 04:08:25PM +0100, Paul Brook wrote:
> > There do seem to be a few people who'd like Alpha emulation for QEMU.
> > Obviously, you'd want to get dynamic translation working first. :-)
> >
> > OTOH, I'm now wondering which archs can support full virtualisation.
> 
> Depends how you define "full virtualization". If you call kqemu full 
> virtualization then you can do that on pretty much any CPU.

I meant "meeting Popek and Goldberg's virtualisation requirements".
-- 
Stuart Brady

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]

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

Re: [Qemu-devel] QEMU Alpha target

[Paul Brook]

On Thursday 29 March 2007 16:12, Stuart Brady wrote:
> On Thu, Mar 29, 2007 at 04:08:25PM +0100, Paul Brook wrote:
> > > There do seem to be a few people who'd like Alpha emulation for QEMU.
> > > Obviously, you'd want to get dynamic translation working first. :-)
> > >
> > > OTOH, I'm now wondering which archs can support full virtualisation.
> >
> > Depends how you define "full virtualization". If you call kqemu full
> > virtualization then you can do that on pretty much any CPU.
>
> I meant "meeting Popek and Goldberg's virtualisation requirements".

In that case, I suspect most of them don't.
x86 certainly doesn't. Recent VT/SVM extensions bring it close, but there are 
still problems.
PPC and SPARC also have hypervisor extensions, which suggests the conventional 
instruction sets don't allow full virtualization.

Paul

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)

[Stuart Brady]

On Thu, Mar 29, 2007 at 05:25:47PM +0200, Sunil Amitkumar Janki wrote:

> 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.

I've been thinking about Alpha emulation for a while.  I'd be happy to
help in any way that I can.

> 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.

PA-RISC emulation is currently being worked on.

See http://hppaqemu.sourceforge.net/

Please feel free to ask questions about the code on the hppaqemu-devel
list.  Patches would be very much appreciated, too!

Thanks,
-- 
Stuart Brady

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)

[J. Mayer]

On Thu, 2007-03-29 at 17:08 +0100, Stuart Brady wrote:
> On Thu, Mar 29, 2007 at 05:25:47PM +0200, Sunil Amitkumar Janki wrote:
> 
> > 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.
> 
> I've been thinking about Alpha emulation for a while.  I'd be happy to
> help in any way that I can.

If you are interressed to this target, you may like this:
I did, for fun, a preliminary version of the alpha CPU emulation.
For now, it implements most of the CPU instructions and should be able
to achieve user mode emulation after a debugging pass. For now, only a
few static programs start and run. The problem is I have too few free
time to debug it correctly and no alpha hardware or specific knowledge
to help me.
So, if someone is interrested to debug and develop this target, I could
add the code I have to the Qemu repository as a start and let any
motivated one go on developping the target.

[...]

-- 
J. Mayer <l_indien@magic.fr>
Never organized

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)

[Brian Wheeler]

For a somewhat complete alpha emulator, there's es40 on sourceforge.  It
doesn't actually boot an OS yet, but its getting closer.  The firmware
comes up and but it hangs on OS initialization.


http://sourceforge.net/projects/es40/

Brian




On Thu, 2007-03-29 at 21:57 +0200, J. Mayer wrote:
> On Thu, 2007-03-29 at 17:08 +0100, Stuart Brady wrote:
> > On Thu, Mar 29, 2007 at 05:25:47PM +0200, Sunil Amitkumar Janki wrote:
> > 
> > > 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.
> > 
> > I've been thinking about Alpha emulation for a while.  I'd be happy to
> > help in any way that I can.
> 
> If you are interressed to this target, you may like this:
> I did, for fun, a preliminary version of the alpha CPU emulation.
> For now, it implements most of the CPU instructions and should be able
> to achieve user mode emulation after a debugging pass. For now, only a
> few static programs start and run. The problem is I have too few free
> time to debug it correctly and no alpha hardware or specific knowledge
> to help me.
> So, if someone is interrested to debug and develop this target, I could
> add the code I have to the Qemu repository as a start and let any
> motivated one go on developping the target.
> 
> [...]
> 

Re: [Qemu-devel] QEMU Alpha target

[J. Mayer]

On Thu, 2007-03-29 at 16:25 +0100, Paul Brook wrote:
> On Thursday 29 March 2007 16:12, Stuart Brady wrote:
> > On Thu, Mar 29, 2007 at 04:08:25PM +0100, Paul Brook wrote:
> > > > There do seem to be a few people who'd like Alpha emulation for QEMU.
> > > > Obviously, you'd want to get dynamic translation working first. :-)
> > > >
> > > > OTOH, I'm now wondering which archs can support full virtualisation.
> > >
> > > Depends how you define "full virtualization". If you call kqemu full
> > > virtualization then you can do that on pretty much any CPU.
> >
> > I meant "meeting Popek and Goldberg's virtualisation requirements".
> 
> In that case, I suspect most of them don't.
> x86 certainly doesn't. Recent VT/SVM extensions bring it close, but there are 
> still problems.
> PPC and SPARC also have hypervisor extensions, which suggests the conventional 
> instruction sets don't allow full virtualization.

PowerPC is fully virtualisable which is what Mac-On-Linux is supposed to
do. But this has a cost. Hypervisor mode seems to exists only to do the
same without any performance degradation.

-- 
J. Mayer <l_indien@magic.fr>
Never organized

[Qemu-devel] QEMU Alpha target

[Stuart Brady]

On Thu, Mar 29, 2007 at 09:57:08PM +0200, J. Mayer wrote:
> If you are interressed to this target, you may like this:
> I did, for fun, a preliminary version of the alpha CPU emulation.
> For now, it implements most of the CPU instructions and should be able
> to achieve user mode emulation after a debugging pass. For now, only a
> few static programs start and run. The problem is I have too few free
> time to debug it correctly and no alpha hardware or specific knowledge
> to help me.
> 
> So, if someone is interrested to debug and develop this target, I could
> add the code I have to the Qemu repository as a start and let any
> motivated one go on developping the target.

Great news!  I was wondering about the reference to 'TARGET_ALPHA' that
you made recently. :-)  While I'm interested, I can't promise to be of
much use, as I haven't worked with Alpha before.  OTOH, it can't hurt to
release the code, and I can certainly check it against documentation.

There certainly seems to be some interest, anyway. :-)
-- 
Stuart Brady

Re: [Qemu-devel] QEMU Alpha target

[J. Mayer]

On Thu, 2007-03-29 at 22:18 +0100, Stuart Brady wrote:
> On Thu, Mar 29, 2007 at 09:57:08PM +0200, J. Mayer wrote:
> > If you are interressed to this target, you may like this:
> > I did, for fun, a preliminary version of the alpha CPU emulation.
> > For now, it implements most of the CPU instructions and should be able
> > to achieve user mode emulation after a debugging pass. For now, only a
> > few static programs start and run. The problem is I have too few free
> > time to debug it correctly and no alpha hardware or specific knowledge
> > to help me.
> > 
> > So, if someone is interrested to debug and develop this target, I could
> > add the code I have to the Qemu repository as a start and let any
> > motivated one go on developping the target.
> 
> Great news!  I was wondering about the reference to 'TARGET_ALPHA' that
> you made recently. :-)  While I'm interested, I can't promise to be of
> much use, as I haven't worked with Alpha before.  OTOH, it can't hurt to
> release the code, and I can certainly check it against documentation.
> 
> There certainly seems to be some interest, anyway. :-)

I did not provide the code because I will not maintain and go on
developping it. And I don't want to add orphean code in the Qemu
repository. But if there is some people ready to work on it, I can do
it.
It already helped me find some fixes to be submited to run 64 bits
program in linux user target mode...


-- 
J. Mayer <l_indien@magic.fr>
Never organized

Re: [Qemu-devel] QEMU Alpha target

[Thomas Orgis]

Well, since I am someone in the lucky position of having alpha hardware in use
I can offer to test stuff.
I saved two boxen basically from the dumpster, one of which being my
primary workstation and the other open for other experiments, even.
I don't have time, especially now, but in a month or two, I guess I could
take any preliminary alpha kqemu out for a spin happily;-)

I'm not sure if I could offer ssh user access, I should ask our admin for that.
But I can compile and test code you throw at me.

There are some alphas awaiting their retirement or being halfway in it around
here... They have largely been replaced by Intel P4s and AthlonXPs in the years,
with the return to 64bit recently, most workstations being em64t or x86-64 now.
Heck, the name tag on our admin's office door still says "CRAY admin"... but
that one is long gone... *snif*
Well, computer business is bound to screw history. I moves on.


Alrighty then,

Thomas.

PS: Isn't it astonishing that everytime you mention alpha, ppl go "Aaaah... Alpha!";-)
But I figure the sheer mass of registers to spill (to quote gcc's error message
that started this thread) must indeed be a joy for qemu code.
And in general;-)

Re: [Qemu-devel] QEMU Alpha target

[Stuart Brady]

On Thu, Mar 29, 2007 at 11:31:14PM +0200, J. Mayer wrote:

> I did not provide the code because I will not maintain and go on
> developping it. And I don't want to add orphean code in the Qemu
> repository. But if there is some people ready to work on it, I can do
> it. It already helped me find some fixes to be submited to run 64
> bits program in linux user target mode...

In that case, it might be better to post a patch to the list.  If anyone
starts working on it, they can set up a repository for it elsewhere.
-- 
Stuart Brady