Am Fri, 23 Mar 2007 15:45:49 +0000
schrieb Paul Brook <address@hidden>:
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
address@hidden
http://lists.nongnu.org/mailman/listinfo/qemu-devel