| Message ID | 20090917152502.G54732@stanley.csl.cornell.edu |
|---|---|
| State | Superseded |
| Headers | show |
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 */ > > >
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
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
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.
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.
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
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
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
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.
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 */
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>