From: Ulrich Hecht <uli@suse.de>
To: Aurelien Jarno <aurelien@aurel32.net>
Cc: aliguori@us.ibm.com, riku.voipio@iki.fi, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 3/4] S/390 host support for TCG
Date: Mon, 9 Nov 2009 18:54:28 +0200 [thread overview]
Message-ID: <200911091754.29864.uli@suse.de> (raw)
In-Reply-To: <20091102171718.GB23141@volta.aurel32.net>
On Monday 02 November 2009, Aurelien Jarno wrote:
> First of all I have a question about s390/s390x. It seems that you
> plan to support both s390 and s390x in the same file. Is that correct?
Actually, I didn't think about supporting s390 hosts at all, but it
should be possible.
> Do you know how far the 32-bit support is far from compiling/working?
It is not entirely unlikely that it's close. You obviously can't use the
64-bit instructions on a 31-bit host, but other than that...
> Would it be really possible to support both in the same file?
It would, but we would need different implementations for the 64-bit
operations.
From a practical point of view, I don't see any merit in supporting
31-bit hosts, simply because there aren't many in use anymore. (It's a
different story for the target: 31-bit _software_ is still widespread.)
> > +SEARCH_DIR("/usr/s390x-suse-linux/lib64");
> > SEARCH_DIR("/usr/local/lib64"); SEARCH_DIR("/lib64");
> > SEARCH_DIR("/usr/lib64"); SEARCH_DIR("/usr/s390x-suse-linux/lib");
> > SEARCH_DIR("/usr/lib64"); SEARCH_DIR("/usr/local/lib");
> > SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib");
>
> Why adding some search directories manually here? The one you are
> adding are SuSE specific. They should already be detected by the
> configure script and added to config-host.ld.
I merely copied the linker script and made some minor adjustments, I
didn't really pay much attention to what it actually contains...
> > + tcg_out32(s, 0xa7840000); /* je label1 (offset will be patched
> > in later) */
>
> Would be nice to have the corresponding tcg_out_ function and the
> corresponding value instead of the magic value. Also I am not sure the
> comment is correct here, "je" being an x86_64 instruction.
objdump disassembles it as "je", though the POP doesn't specify any
aliases for the different mask values for BRC.
> > + tcg_out_sh64(s, SH64_SRAG, data_reg, data_reg,
> > SH64_REG_NONE, 48); + break;
> > + case 2 | 4:
> > + tcg_out_b9(s, B9_LGFR, data_reg, arg0);
> > + break;
> > + case 0: case 1: case 2: case 3: default:
> > + /* unsigned -> just copy */
> > + tcg_out_b9(s, B9_LGR, data_reg, arg0);
>
> Is it always correct? On x86_64, starting with gcc 4.3, it is not
> guaranteed anymore that non used bits are set to 0.
Do I understand you correctly in that you are suggesting to do an
explicit zero extension here? (But what does GCC have to do with
TCG-generated code?)
> > + case INDEX_op_call:
> > + //fprintf(stderr,"op 0x%x call 0x%lx 0x%lx
> > 0x%lx\n",opc,args[0],args[1],args[2]); + if (const_args[0]) {
> > + tcg_target_long off = (args[0] -
> > (tcg_target_long)s->code_ptr + 4) >> 1; /* FIXME: + 4? Where did
> > that come from? */ + if (off > -0x80000000 && off <
> > 0x7fffffff) { /* relative call */ + tcg_out_brasl(s,
> > TCG_REG_R14, off << 1);
> > + tcg_abort(); // untested
>
> If not tested, it's probably better to remove this part and do not
> mark call accepting constants.
I suppose so. It's obviously never used anyway.
>
> > + }
> > + else { /* too far for a relative call, load full
> > address */ + tcg_out_movi(s, TCG_TYPE_PTR,
> > TCG_REG_R13, args[0]); + tcg_out_rr(s, RR_BASR,
> > TCG_REG_R14, TCG_REG_R13);
>
> Not sure it is very useful here. It's probably better to redefine the
> constraints of the constant, so that the reg allocator use a register
> to pass the value.
>
> > + }
> > + }
> > + else { /* call function in register args[0] */
> > + tcg_out_rr(s, RR_BASR, TCG_REG_R14, args[0]);
> > + }
> > + break;
> > + case INDEX_op_jmp:
> > + fprintf(stderr,"op 0x%x jmp 0x%lx 0x%lx
> > 0x%lx\n",opc,args[0],args[1],args[2]); + tcg_abort();
> > + break;
>
> What about implementing that?
Do you know a target that actually uses it? I try to avoid implementing
stuff that I can't test.
> > +static inline void tcg_out_addi(TCGContext *s, int reg,
> > tcg_target_long val) +{
> > + tcg_abort();
> > +}
>
> Why this one is not implemented? This is definitely needed so that
> arguments can be passed on the stack.
Generally, if something is not implemented yet it's because it has never
been used anywhere.
> > +#define TCG_TARGET_HAS_div_i32
> > +#undef TCG_TARGET_HAS_div_i64
>
> Is that corrects? It looks strange an architecture has different
> division in 32- and 64-bits mode.
The 64-bit instruction set actually has both. Maybe I just forgot to
implement it.
CU
Uli
--
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
next prev parent reply other threads:[~2009-11-09 16:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-24 17:08 [Qemu-devel] [PATCH 0/4] S/390 host and target support Ulrich Hecht
2009-07-24 17:08 ` [Qemu-devel] [PATCH 1/4] S/390 CPU emulation Ulrich Hecht
2009-07-24 17:08 ` [Qemu-devel] [PATCH 2/4] S/390 host/target build system support Ulrich Hecht
2009-07-24 17:08 ` [Qemu-devel] [PATCH 3/4] S/390 host support for TCG Ulrich Hecht
2009-07-24 17:08 ` [Qemu-devel] [PATCH 4/4] linux-user: S/390 64-bit (s390x) support Ulrich Hecht
2009-07-24 17:59 ` [Qemu-devel] [PATCH 3/4] S/390 host support for TCG malc
2009-11-02 17:17 ` Aurelien Jarno
2009-11-09 16:54 ` Ulrich Hecht [this message]
2009-11-10 17:01 ` Aurelien Jarno
[not found] ` <m3vdlirkqw.fsf@neno.mitica>
2009-07-27 10:20 ` [Qemu-devel] Re: [PATCH 2/4] S/390 host/target build system support Ulrich Hecht
2009-07-25 17:05 ` [Qemu-devel] [PATCH 1/4] S/390 CPU emulation Blue Swirl
2009-07-27 10:54 ` Ulrich Hecht
2009-07-27 11:09 ` Filip Navara
2009-10-06 23:22 ` [Qemu-devel] [PATCH 0/4] S/390 host and target support Alexander Graf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200911091754.29864.uli@suse.de \
--to=uli@suse.de \
--cc=aliguori@us.ibm.com \
--cc=aurelien@aurel32.net \
--cc=qemu-devel@nongnu.org \
--cc=riku.voipio@iki.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).