[Qemu-devel] [PATCH] Fix extlh instruction on Alpha

[Qemu-devel] [PATCH] Fix extlh instruction on Alpha

[Vince Weaver]

The extlh instruction on Alpha currently doesn't work properly.
It's a combination of a cut/paste bug (16 where it should be 32) as well 
as a "shift by 64" bug.

This improves on an earlier patch that used labels, conditional jumps, 
and local variables.  Thanks go especially to Aurelien Jarno and Andreas 
Schwab who have a much better eye for bit-wise TCG optimization than I do.

Vince

Signed-off-by: Vince Weaver <vince@csl.cornell.edu>

diff --git a/target-alpha/translate.c b/target-alpha/translate.c
index 9d2bc45..9e7e9b2 100644
--- a/target-alpha/translate.c
+++ b/target-alpha/translate.c
@@ -524,14 +524,15 @@ static inline void gen_ext_h(void(*tcg_gen_ext_i64)(TCGv t0, TCGv t1),
             else
                 tcg_gen_mov_i64(cpu_ir[rc], cpu_ir[ra]);
         } else {
-            TCGv tmp1, tmp2;
+            TCGv tmp1;
             tmp1 = tcg_temp_new();
+
             tcg_gen_andi_i64(tmp1, cpu_ir[rb], 7);
             tcg_gen_shli_i64(tmp1, tmp1, 3);
-            tmp2 = tcg_const_i64(64);
-            tcg_gen_sub_i64(tmp1, tmp2, tmp1);
-            tcg_temp_free(tmp2);
+            tcg_gen_neg_i64(tmp1, tmp1);
+            tcg_gen_andi_i64(tmp1, tmp1, 0x3f);
             tcg_gen_shl_i64(cpu_ir[rc], cpu_ir[ra], tmp1);
+
             tcg_temp_free(tmp1);
         }
         if (tcg_gen_ext_i64)
@@ -1316,7 +1317,7 @@ static inline int translate_one(DisasContext *ctx, uint32_t insn)
             break;
         case 0x6A:
             /* EXTLH */
-            gen_ext_h(&tcg_gen_ext16u_i64, ra, rb, rc, islit, lit);
+            gen_ext_h(&tcg_gen_ext32u_i64, ra, rb, rc, islit, lit);
             break;
         case 0x72:
             /* MSKQH */

Re: [Qemu-devel] [PATCH] Fix extlh instruction on Alpha

[Aurelien Jarno]

On Thu, Sep 17, 2009 at 03:28:52PM -0400, Vince Weaver wrote:
> 
> The extlh instruction on Alpha currently doesn't work properly.
> It's a combination of a cut/paste bug (16 where it should be 32) as well 
> as a "shift by 64" bug.
> 
> This improves on an earlier patch that used labels, conditional jumps, 
> and local variables.  Thanks go especially to Aurelien Jarno and Andreas 
> Schwab who have a much better eye for bit-wise TCG optimization than I do.
> 
> Vince
> 
> Signed-off-by: Vince Weaver <vince@csl.cornell.edu>

Thanks, applied to both master and stable-0.11.

> diff --git a/target-alpha/translate.c b/target-alpha/translate.c
> index 9d2bc45..9e7e9b2 100644
> --- a/target-alpha/translate.c
> +++ b/target-alpha/translate.c
> @@ -524,14 +524,15 @@ static inline void gen_ext_h(void(*tcg_gen_ext_i64)(TCGv t0, TCGv t1),
>              else
>                  tcg_gen_mov_i64(cpu_ir[rc], cpu_ir[ra]);
>          } else {
> -            TCGv tmp1, tmp2;
> +            TCGv tmp1;
>              tmp1 = tcg_temp_new();
> +
>              tcg_gen_andi_i64(tmp1, cpu_ir[rb], 7);
>              tcg_gen_shli_i64(tmp1, tmp1, 3);
> -            tmp2 = tcg_const_i64(64);
> -            tcg_gen_sub_i64(tmp1, tmp2, tmp1);
> -            tcg_temp_free(tmp2);
> +            tcg_gen_neg_i64(tmp1, tmp1);
> +            tcg_gen_andi_i64(tmp1, tmp1, 0x3f);
>              tcg_gen_shl_i64(cpu_ir[rc], cpu_ir[ra], tmp1);
> +
>              tcg_temp_free(tmp1);
>          }
>          if (tcg_gen_ext_i64)
> @@ -1316,7 +1317,7 @@ static inline int translate_one(DisasContext *ctx, uint32_t insn)
>              break;
>          case 0x6A:
>              /* EXTLH */
> -            gen_ext_h(&tcg_gen_ext16u_i64, ra, rb, rc, islit, lit);
> +            gen_ext_h(&tcg_gen_ext32u_i64, ra, rb, rc, islit, lit);
>              break;
>          case 0x72:
>              /* MSKQH */
> 
> 
> 

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Re: [Qemu-devel] [PATCH] Fix extlh instruction on Alpha

[Rob Landley]

On Thursday 17 September 2009 14:28:52 Vince Weaver wrote:
> The extlh instruction on Alpha currently doesn't work properly.
> It's a combination of a cut/paste bug (16 where it should be 32) as well
> as a "shift by 64" bug.
>
> This improves on an earlier patch that used labels, conditional jumps,
> and local variables.  Thanks go especially to Aurelien Jarno and Andreas
> Schwab who have a much better eye for bit-wise TCG optimization than I do.
>
> Vince

Any idea how hard it would be to whip up a qemu-system-alpha emulation?  I 
note that several real-world alpha boards were essentially just a PC with a 
different processor.  (In fact the original Athlon used the Alpha EV6 bus and 
was pin-compatible, so you could drop-in replace the processor with an Alpha 
if you could somehow reflash the bios with alpha instructions instead of x86.)

I'd like to boot Alpha Linux on qemu, and it doesn't seem like there's _that_ 
much more to do.  But last I asked (a couple years ago) I was told the Alpha 
protected mode stuff wasn't implemented yet...

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds

Re: [Qemu-devel] [PATCH] Fix extlh instruction on Alpha

[Laurent Desnogues]

On Mon, Sep 21, 2009 at 4:20 AM, Rob Landley <rob@landley.net> wrote:
>
> Any idea how hard it would be to whip up a qemu-system-alpha emulation?  I
> note that several real-world alpha boards were essentially just a PC with a
> different processor.  (In fact the original Athlon used the Alpha EV6 bus and
> was pin-compatible, so you could drop-in replace the processor with an Alpha
> if you could somehow reflash the bios with alpha instructions instead of x86.)
>
> I'd like to boot Alpha Linux on qemu, and it doesn't seem like there's _that_
> much more to do.  But last I asked (a couple years ago) I was told the Alpha
> protected mode stuff wasn't implemented yet...

There's been a series of patch to add ES40 proposed by Tristan Gingold
last March.  Look here:

http://www.archivum.info/qemu-devel@nongnu.org/2009-03/00723/%5BQemu-devel%5D_%5BPATCH_0_24%5D:_add_alpha_es40_system_emulation


Laurent

Re: [Qemu-devel] [PATCH] Fix extlh instruction on Alpha

[Tristan Gingold]

On Sep 21, 2009, at 8:23 AM, Laurent Desnogues wrote:

> On Mon, Sep 21, 2009 at 4:20 AM, Rob Landley <rob@landley.net> wrote:
>> I'd like to boot Alpha Linux on qemu, and it doesn't seem like  
>> there's _that_
>> much more to do.  But last I asked (a couple years ago) I was told  
>> the Alpha
>> protected mode stuff wasn't implemented yet...
>
> There's been a series of patch to add ES40 proposed by Tristan Gingold
> last March.  Look here:
>
> http://www.archivum.info/qemu-devel@nongnu.org/2009-03/00723/%5BQemu-devel%5D_%5BPATCH_0_24%5D:_add_alpha_es40_system_emulation

I haven't had time to continue to work on it.  It was able to boot and  
run linux and partially boot
tru64.  Both AlphaBios and SRM were ok.

The main issue was speed and IO-TLB (necessary for Tru64 and VMS).

Tristan.

Re: [Qemu-devel] [PATCH] Fix extlh instruction on Alpha

[Rob Landley]

On Monday 21 September 2009 06:37:24 Tristan Gingold wrote:
> On Sep 21, 2009, at 8:23 AM, Laurent Desnogues wrote:
> > On Mon, Sep 21, 2009 at 4:20 AM, Rob Landley <rob@landley.net> wrote:
> >> I'd like to boot Alpha Linux on qemu, and it doesn't seem like
> >> there's _that_
> >> much more to do.  But last I asked (a couple years ago) I was told
> >> the Alpha
> >> protected mode stuff wasn't implemented yet...
> >
> > There's been a series of patch to add ES40 proposed by Tristan Gingold
> > last March.  Look here:
> >
> > http://www.archivum.info/qemu-devel@nongnu.org/2009-03/00723/%5BQemu-deve
> >l%5D_%5BPATCH_0_24%5D:_add_alpha_es40_system_emulation
>
> I haven't had time to continue to work on it.  It was able to boot and
> run linux and partially boot
> tru64.  Both AlphaBios and SRM were ok.
>
> The main issue was speed and IO-TLB (necessary for Tru64 and VMS).

I'm only worrying about Linux at the moment.  If the patch series boots Linux, 
I'm happy to test it.

Did you boot Linux with -kernel?  Do you have the Linux .config you used?  And 
what gcc/binutils tuple were you using?  (Just straight alpha-unknown-linux?)

Thanks,

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds

Re: [Qemu-devel] [PATCH] Fix extlh instruction on Alpha

[Tristan Gingold]

On Sep 21, 2009, at 8:48 PM, Rob Landley wrote:

> On Monday 21 September 2009 06:37:24 Tristan Gingold wrote:
>> On Sep 21, 2009, at 8:23 AM, Laurent Desnogues wrote:
>>> On Mon, Sep 21, 2009 at 4:20 AM, Rob Landley <rob@landley.net>  
>>> wrote:
>>>> I'd like to boot Alpha Linux on qemu, and it doesn't seem like
>>>> there's _that_
>>>> much more to do.  But last I asked (a couple years ago) I was told
>>>> the Alpha
>>>> protected mode stuff wasn't implemented yet...
>>>
>>> There's been a series of patch to add ES40 proposed by Tristan  
>>> Gingold
>>> last March.  Look here:
>>>
>>> http://www.archivum.info/qemu-devel@nongnu.org/2009-03/00723/%5BQemu-deve
>>> l%5D_%5BPATCH_0_24%5D:_add_alpha_es40_system_emulation
>>
>> I haven't had time to continue to work on it.  It was able to boot  
>> and
>> run linux and partially boot
>> tru64.  Both AlphaBios and SRM were ok.
>>
>> The main issue was speed and IO-TLB (necessary for Tru64 and VMS).
>
> I'm only worrying about Linux at the moment.  If the patch series  
> boots Linux,
> I'm happy to test it.

Yes, I got a linux shell.

> Did you boot Linux with -kernel?

No.

>  Do you have the Linux .config you used?  And
> what gcc/binutils tuple were you using?  (Just straight alpha- 
> unknown-linux?)

Yes.

Tristan.

Re: [Qemu-devel] [PATCH] Fix extlh instruction on Alpha

[Rob Landley]

On Monday 21 September 2009 01:23:50 Laurent Desnogues wrote:
> On Mon, Sep 21, 2009 at 4:20 AM, Rob Landley <rob@landley.net> wrote:
> > Any idea how hard it would be to whip up a qemu-system-alpha emulation?
> >  I note that several real-world alpha boards were essentially just a PC
> > with a different processor.  (In fact the original Athlon used the Alpha
> > EV6 bus and was pin-compatible, so you could drop-in replace the
> > processor with an Alpha if you could somehow reflash the bios with alpha
> > instructions instead of x86.)
> >
> > I'd like to boot Alpha Linux on qemu, and it doesn't seem like there's
> > _that_ much more to do.  But last I asked (a couple years ago) I was told
> > the Alpha protected mode stuff wasn't implemented yet...
>
> There's been a series of patch to add ES40 proposed by Tristan Gingold
> last March.

Ooh, thanks.

> Look here:
>
> http://www.archivum.info/qemu-devel@nongnu.org/2009-03/00723/%5BQemu-devel%
>5D_%5BPATCH_0_24%5D:_add_alpha_es40_system_emulation

That's the March 19th posting, he actually posted a newer series on March 30.  
Still just boots the Bios, not Linux, but it seems a good thing to poke at

Looks promising.  Has there been any progress since then?  (Did any of the 
series get merged?  Is it worth trying to apply this series to current -git, 
feeding it a linux -kernel, and seeing what happens?)

> Laurent

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds

qemu-system-alpha (was: Re: [Qemu-devel] [PATCH] Fix extlh instruction on Alpha)

[Brian Wheeler]

On Sun, 2009-09-20 at 21:20 -0500, Rob Landley wrote:
> On Thursday 17 September 2009 14:28:52 Vince Weaver wrote:
> > The extlh instruction on Alpha currently doesn't work properly.
> > It's a combination of a cut/paste bug (16 where it should be 32) as well
> > as a "shift by 64" bug.
> >
> > This improves on an earlier patch that used labels, conditional jumps,
> > and local variables.  Thanks go especially to Aurelien Jarno and Andreas
> > Schwab who have a much better eye for bit-wise TCG optimization than I do.
> >
> > Vince
> 
> Any idea how hard it would be to whip up a qemu-system-alpha emulation?  I 
> note that several real-world alpha boards were essentially just a PC with a 
> different processor.  

Yep.  The ES40 used the ALI1543 chipset and was pretty pc-ish is most
respects.  There were a couple of DEC specific chips on board (such as
an IOMMU).  

But the hardware isn't the real problem, I don't think.  I think the
real problems (for QEMU, at least) are the PAL and SRM.

The PAL adds several os-specific pseudo-instructions to the instruction
set.  MILO has a linux palcode, but no other open source ones are
available that I know of.  Without VMS or Tru64 Palcode you're limited
to linux.  I think the BSDs use the Tru64 Palcode.  I suppose its
possible to have the palcode routines hard-coded into qemu, though you'd
need several sets of them (one for each supported OS type)

There doesn't seem to be an open source SRM which can be used to boot
the machine and provide the initial user interface.  MILO also performs
this function, but its hard to build and pretty old.  

I believe that charon axp solves this problem by having their own
mini-implementation of the srm (and presumably the PAL) which only
supports setting/viewing the environment and booting.  The real SRM has
lots of features that aren't really needed on emulated hardware.

> I'd like to boot Alpha Linux on qemu, and it doesn't seem like there's _that_ 
> much more to do.  But last I asked (a couple years ago) I was told the Alpha 
> protected mode stuff wasn't implemented yet...

There were patches last year for an es40, but they never made it to the
main tree...and weren't quite finished.

Re: qemu-system-alpha (was: Re: [Qemu-devel] [PATCH] Fix extlh instruction on Alpha)

[Rob Landley]

On Monday 21 September 2009 08:31:49 Brian Wheeler wrote:
> On Sun, 2009-09-20 at 21:20 -0500, Rob Landley wrote:
> > On Thursday 17 September 2009 14:28:52 Vince Weaver wrote:
> > > The extlh instruction on Alpha currently doesn't work properly.
> > > It's a combination of a cut/paste bug (16 where it should be 32) as
> > > well as a "shift by 64" bug.
> > >
> > > This improves on an earlier patch that used labels, conditional jumps,
> > > and local variables.  Thanks go especially to Aurelien Jarno and
> > > Andreas Schwab who have a much better eye for bit-wise TCG optimization
> > > than I do.
> > >
> > > Vince
> >
> > Any idea how hard it would be to whip up a qemu-system-alpha emulation? 
> > I note that several real-world alpha boards were essentially just a PC
> > with a different processor.
>
> Yep.  The ES40 used the ALI1543 chipset and was pretty pc-ish is most
> respects.  There were a couple of DEC specific chips on board (such as
> an IOMMU).
>
> But the hardware isn't the real problem, I don't think.  I think the
> real problems (for QEMU, at least) are the PAL and SRM.
>
> The PAL adds several os-specific pseudo-instructions to the instruction
> set.  MILO has a linux palcode, but no other open source ones are
> available that I know of.  Without VMS or Tru64 Palcode you're limited
> to linux.  I think the BSDs use the Tru64 Palcode.  I suppose its
> possible to have the palcode routines hard-coded into qemu, though you'd
> need several sets of them (one for each supported OS type)

What I'd really like to use is the -kernel option to boot Linux.

I have a project (http://impactlinux.com/fwl) that's trying to build a simple 
uclibc/busybox Linux system image for each qemu-system target, plus a native 
compiler (gcc,binutils,make,bash), and then using distcc to call out to the 
host's cross compiler through the virtual network to speed up native builds 
without all the other complexity of cross compiling (lying to ./configure in 
three dozen different ways while keeping two different toolchains with their own 
sets of headers and libraries from leaking into each other).

It's also a fun way to do nightly regression tests of busybox, uClibc, and the 
linux kernel on various different targets, so things like 2.6.30's mips bug or 
the current sh4 weirdness in 2.6.31 get caught early enough that the 
developers remember what changed.

It boots a kernel via -kernel and feeds in a root filesystem as /dev/hda or 
/dev/sda (or initramfs in a pinch, but that seldom gives you enough space 11 
megabytes of compressed toolchain before the memory mappings go "boing" during 
initramfs extract).  The way I'm booting uses a serial console, emulated hard 
drive (ide or scsi), emulated network card, 256 megs of ram, and optionally a 
battery-backed clock (I can fake it with rdate if the network card works, make 
gets really unhappy otherwise), the processor emulation in question, and a 
kernel configured to boot on that particular qemu setup.

So far I've got ppc, arm, mips, sh4, x86, x86-64, and a very buggy sparc 
booting to a shell prompt, and all of 'em except sparc can build and run 
"hello world" natively.  (uClibc's sparc support is not happy, hopefully 
current -git sucks less.)

I whipped up an Alpha config back when I started the project, but there's never 
been a way to test it, so it got lost.  Similar with m68k and cris.  (Last I 
checked the emulated cris boards were toys with a fixed small amount of memory, 
no hard drive, no way to add a network card, and I don't remember if they even 
emulated a battery-backed clock.)

> There doesn't seem to be an open source SRM which can be used to boot
> the machine and provide the initial user interface.  MILO also performs
> this function, but its hard to build and pretty old.
>
> I believe that charon axp solves this problem by having their own
> mini-implementation of the srm (and presumably the PAL) which only
> supports setting/viewing the environment and booting.  The real SRM has
> lots of features that aren't really needed on emulated hardware.

Reminds me of the nightmare getting openbios/openhackware on ppc to feed in a 
coherent device tree.  I just want enough setup to make -kernel work, but 
that's often nontrivial. :(

> > I'd like to boot Alpha Linux on qemu, and it doesn't seem like there's
> > _that_ much more to do.  But last I asked (a couple years ago) I was told
> > the Alpha protected mode stuff wasn't implemented yet...
>
> There were patches last year for an es40, but they never made it to the
> main tree...and weren't quite finished.

I'm happy to test (and document) something that almost works.  But if it 
doesn't almost work, I'm unlikely to be much help. :(

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds