On Wednesday 01 November 2006 16:34, Rob Landley wrote:
> On Tuesday 31 October 2006 10:22 pm, Paul Brook wrote:
> > > > and glue them together like we do with dyngen. However once you've
> > > > done that you've implemented most of what's needed for fully dynamic
> > > > qops, so it doesn't really
On Tuesday 31 October 2006 10:22 pm, Paul Brook wrote:
> > > and glue them together like we do with dyngen. However once you've done
> > > that you've implemented most of what's needed for fully dynamic qops, so
> > > it doesn't really seem worth it.
> >
> > I missed a curve. What's "fully dynami
On Wednesday 01 November 2006 01:51, Rob Landley wrote:
> On Tuesday 31 October 2006 7:29 pm, Paul Brook wrote:
> > > Actually it sounds additive rather than multiplicative. Does each
> > > target have an entirely unrelated set of ops, or is there a shared set
> > > of primitive ops plus some oddb
On Tuesday 31 October 2006 7:29 pm, Paul Brook wrote:
> > Actually it sounds additive rather than multiplicative. Does each target
> > have an entirely unrelated set of ops, or is there a shared set of
> > primitive ops plus some oddballs?
>
> The shared set of primitive ops is basically qops :-)
> Actually it sounds additive rather than multiplicative. Does each target
> have an entirely unrelated set of ops, or is there a shared set of
> primitive ops plus some oddballs?
The shared set of primitive ops is basically qops :-)
You probably could figure out a single common qet of qops, then
> Where's the shift? I think the above code means you generate an immediate
> value (the 2), add it to R2 with the result going in a spill register, and
> then add the spill register to R1, with the result going to R0. Should
> that middle line be some kind of gen_op_lshift32() instead of
> gen_o
On Tuesday 31 October 2006 5:08 pm, Paul Brook wrote:
> On Tuesday 31 October 2006 20:41, Rob Landley wrote:
> > Welcome to Stupid Question Theatre! With your host, Paul Brook. Today's
> > contestant is: Rob Landley. How dumb will it get?
Bonus round!
> > I thought what you were doing was repl
On Tuesday 31 October 2006 2:02 pm, Paul Brook wrote:
> As an example take the arm instruction
>
> add, r0, r1, r2, lsl #2
>
> This is equivalent to the C expression
>
> r0 = r1 + (r2 << 2)
...
> When fully converted to the new system this would become:
>
> int tmp = gen_new_qreg(); /* Al
On Tuesday 31 October 2006 22:31, Laurent Desnogues wrote:
> Paul Brook a écrit :
> > Replacing the pregenerated blocks with hand written assembly isn't
> > feasible. Each target has its own set of ops, and each host would need
> > its own assembly implementation of those ops. Multiply 11 targets b
Paul Brook a écrit :
Replacing the pregenerated blocks with hand written assembly isn't feasible.
Each target has its own set of ops, and each host would need its own assembly
implementation of those ops. Multiply 11 targets by 11 hosts and you get a
unmaintainable mess :-)
Shouldn't you have
On Tuesday 31 October 2006 20:41, Rob Landley wrote:
> Welcome to Stupid Question Theatre! With your host, Paul Brook. Today's
> contestant is: Rob Landley. How dumb will it get?
>
> On Tuesday 31 October 2006 2:02 pm, Paul Brook wrote:
> > The basic principle is very similar. Host code is decom
Welcome to Stupid Question Theatre! With your host, Paul Brook. Today's
contestant is: Rob Landley. How dumb will it get?
On Tuesday 31 October 2006 2:02 pm, Paul Brook wrote:
> The basic principle is very similar. Host code is decomposed into an
> intermediate form consisting of simple opera
On Tuesday 31 October 2006 16:53, Rob Landley wrote:
> On Monday 23 October 2006 2:37 pm, Paul Brook wrote:
> > > > Better to just teach qemu how to generate code.
> > > > In fact I've already done most of the infrastructure (and a fair
> > > > amount of the legwork) for this. The only major missin
On Monday 23 October 2006 2:37 pm, Paul Brook wrote:
> > > Better to just teach qemu how to generate code.
> > > In fact I've already done most of the infrastructure (and a fair amount
> > > of the legwork) for this. The only major missing function is code to do
> > > softmmu load/store ops.
> > >
On Monday 30 October 2006 22:54, Stephen Torri wrote:
> > As I said before, the x86 target is a hybrid of the new and old code. ie.
> > if it didn't work before it probably won't work after. configure
> > with --target-list=m68k-user and it should work fine with gcc4.
> >
> > Paul
>
> I need a x86
> As I said before, the x86 target is a hybrid of the new and old code. ie. if
> it didn't work before it probably won't work after. configure
> with --target-list=m68k-user and it should work fine with gcc4.
>
> Paul
I need a x86 instruction set simulator that can step-by-step execute
could a
> > > So given that one of the reasons for doing this would be getting away
> > > from depending on specific and increasily out of date versions of gcc
> > > to build the thing, what would be involved in getting this version to
> > > build under gcc-4.x?
> >
> > Should work pretty much out the box.
On Monday 30 October 2006 9:56 am, Paul Brook wrote:
> On Monday 30 October 2006 04:35, Rob Landley wrote:
> > On Monday 23 October 2006 1:58 pm, Paul Brook wrote:
> > > > Although, all told, it would seem to me that what might be called for
> > > > here is a new gcc target. A gcc target specifica
On Monday 30 October 2006 04:35, Rob Landley wrote:
> On Monday 23 October 2006 1:58 pm, Paul Brook wrote:
> > > Although, all told, it would seem to me that what might be called for
> > > here is a new gcc target. A gcc target specifically for generating
> > > qemu code. That would just simply g
On Monday 23 October 2006 1:58 pm, Paul Brook wrote:
> > Although, all told, it would seem to me that what might be called for
> > here is a new gcc target. A gcc target specifically for generating qemu
> > code. That would just simply generate whatever qemu wanted for function
> > postamble.
>
On Wed, Oct 25, 2006 at 03:39:18PM -0400, Rob Landley wrote:
> gcc -Wall -O2 -g -fno-strict-aliasing -I. -I..
> -I/home/landley/qemu/nowt.dyndns.org/qemu/target-sparc
> -I/home/landley/qemu/nowt.dyndns.org/qemu
> -I/home/landley/qemu/nowt.dyndns.org/qemu/host-i386 -D_GNU_SOURCE
> -D_FILE_OFFSET
On Tuesday 24 October 2006 8:24 pm, Paul Brook wrote:
> ColdFire is the only target that uses it exclusively. Arm is currently a
> hybrid of dyngen and the new backend. So is i386, to a lesser extent.
> Other targets have minimal changes necessary to make them work.
Ok.
> > Do you have a quic
On Wednesday 25 October 2006 00:39, Rob Landley wrote:
> On Monday 23 October 2006 2:37 pm, Paul Brook wrote:
> > It turn out that qemu already does most of the hard work, and a code
> > generation backend is fairly simple. The diff for my current
> > implementation is <2k lines of common code, plu
On Monday 23 October 2006 2:37 pm, Paul Brook wrote:
> It turn out that qemu already does most of the hard work, and a code
> generation backend is fairly simple. The diff for my current implementation
> is <2k lines of common code, plus <1k lines for each of x86, amd64 and ppc32
> hosts.
My un
On Monday 23 October 2006 19:04, K. Richard Pixley wrote:
> Paul Brook wrote:
> > Better to just teach qemu how to generate code.
> > In fact I've already done most of the infrastructure (and a fair amount
> > of the legwork) for this. The only major missing function is code to do
> > softmmu load/
K. Richard Pixley a écrit :
Well, perhaps. Except that with gcc, we get to leverage the ongoing gcc
optimizations, bug fixes, new cpu support, debugger support, etc.
Granted, not all of these are going to be relevant to the qemu
environment, but in a contest between gcc generated code and qe
On Sunday 22 October 2006 9:45 pm, Johannes Schindelin wrote:
> > I was pondered trying to get tcc to build qemu,
>
> (since tcc only supports x86 targets, this is not really a solution.)
No, it supports arm as well. (And I merged a recent patch to support arm
EABI.) I remember hearing about a
Paul Brook wrote:
Better to just teach qemu how to generate code.
In fact I've already done most of the infrastructure (and a fair amount of the
legwork) for this. The only major missing function is code to do softmmu
load/store ops.
https://nowt.dyndns.org/
Well, perhaps. Except that with gc
On Monday 23 October 2006 18:41, K. Richard Pixley wrote:
> Martin Guy wrote:
> >> Now, gcc4 can produce code with several return instructions (with no
> >> option to turn that of, as far as I understand). You cannot cut them
> >> out,
> >> and therefore you cannot chain the simple functions.
> >
>
Johannes Schindelin wrote:
On Sun, 22 Oct 2006, Rob Landley wrote:
Basically, gcc changed in a way that broke qemu.
Yes, they did. But even if I understand your frustration (which I share),
I also understand the gcc people. After all, using gcc to create the
blocks for
Martin Guy wrote:
Now, gcc4 can produce code with several return instructions (with no
option to turn that of, as far as I understand). You cannot cut them
out,
and therefore you cannot chain the simple functions.
...unless you also map return instructions within the generated
functions into
Paul Brook wrote:
We already do that. It doesn't stop gcc putting the return in the middle
of the function.
Paul
void f1();
void f2();
void f(int *z, int x, int y)
{
if (x) {
*z = x;
f1();
} else {
*z = y;
f2();
}
asm volatile ("");
}
wor
> > We already do that. It doesn't stop gcc putting the return in the middle
> > of the function.
> >
> > Paul
>
> void f1();
> void f2();
>
> void f(int *z, int x, int y)
> {
> if (x) {
> *z = x;
> f1();
> } else {
> *z = y;
> f2();
> }
> asm volatil
Paul Brook wrote:
That's exactly what my gcc4 hacks do.
It gets complicated because a x86 uses variable length insn encodings so
you don't know where insn boundaries are, and a jmp instruction is larger
than a ret instruction so it's not always possible to do a straight
replacement.
how
> > That's exactly what my gcc4 hacks do.
> >
> > It gets complicated because a x86 uses variable length insn encodings so
> > you don't know where insn boundaries are, and a jmp instruction is larger
> > than a ret instruction so it's not always possible to do a straight
> > replacement.
>
> how a
Paul Brook wrote:
On Monday 23 October 2006 09:16, Martin Guy wrote:
Now, gcc4 can produce code with several return instructions (with no
option to turn that of, as far as I understand). You cannot cut them out,
and therefore you cannot chain the simple functions.
...unless you also m
On Monday 23 October 2006 09:16, Martin Guy wrote:
> > Now, gcc4 can produce code with several return instructions (with no
> > option to turn that of, as far as I understand). You cannot cut them out,
> > and therefore you cannot chain the simple functions.
>
> ...unless you also map return instru
Now, gcc4 can produce code with several return instructions (with no
option to turn that of, as far as I understand). You cannot cut them out,
and therefore you cannot chain the simple functions.
...unless you also map return instructions within the generated
functions into branches to the soon-
> Basically, gcc changed in a way that broke qemu. There's been an open bug
> report in gcc ever since, but the GCC developers really aren't interested
> in backwards compatability.
That's not entirely true. There are two problems:
- qemu makes assumptions about the layout of the code gcc gener
Hi Rob,
On Sun, 22 Oct 2006, Rob Landley wrote:
> Basically, gcc changed in a way that broke qemu.
Yes, they did. But even if I understand your frustration (which I share),
I also understand the gcc people. After all, using gcc to create the
blocks for dynamic translation is a _hack_. The resu
On Friday 20 October 2006 2:53 pm, K. Richard Pixley wrote:
> Could someone please explain the issue with gcc4, please? Or point me
> to an existing explanation?
>
> I mean, I understand that qemu is believed to be building incorrectly
> with gcc4. But what is the failure mode folks have been
Hi K. Richard,
On Fri, 20 Oct 2006, K. Richard Pixley wrote:
> Could someone please explain the issue with gcc4, please? Or point me
> to an existing explanation?
The issue is that gcc4 optimizes better, but this breaks assumptions of
QEmu.
Example: The basic idea (simplified!) of QEmu is wr
Could someone please explain the issue with gcc4, please? Or point me
to an existing explanation?
I mean, I understand that qemu is believed to be building incorrectly
with gcc4. But what is the failure mode folks have been seeing? And
what's being done about it or what needs to be done abo
43 matches
Mail list logo
