From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.3 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2A979C432C0 for ; Mon, 2 Dec 2019 08:56:19 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D8D3E214AF for ; Mon, 2 Dec 2019 08:56:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="D8mZcSEW" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D8D3E214AF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:60734 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ibhVB-00037E-V6 for qemu-devel@archiver.kernel.org; Mon, 02 Dec 2019 03:56:17 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50042) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ibhUT-0002eV-GL for qemu-devel@nongnu.org; Mon, 02 Dec 2019 03:55:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ibhUR-0002vX-Pp for qemu-devel@nongnu.org; Mon, 02 Dec 2019 03:55:33 -0500 Received: from mail-oi1-x244.google.com ([2607:f8b0:4864:20::244]:33930) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ibhUP-0002uV-AA for qemu-devel@nongnu.org; Mon, 02 Dec 2019 03:55:31 -0500 Received: by mail-oi1-x244.google.com with SMTP id l136so16093181oig.1 for ; Mon, 02 Dec 2019 00:55:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=24gZ/6gg8QS7cCnA9sSTA4xreKt6kedURzox1Y/jxT0=; b=D8mZcSEWid96bvg/A7QHapGswYx+tO0bcg+dqB/oCw9YWE+eZQl25xaXSXLXvu1ln2 Cv3+OxrWjDGVNYzboXXO0v4dDuARduoErJvaoVmV7Iee7ehtFbsPfhKbw7gRNLRmNI/G yH2h4n6VLGaiOXkvuopvgKBOJwyJ5CdBQhNS+egz2jEYZxcHyB71NQwDcekaL/OhbJGx 6c7u5rtwsemNo5yc7DGPXpSMS3ZO8n2tk4fi9OCiJwd3eswJreVTfzzVIjnq8W09+3Np a+tsnONBAmKe+dbn/YdFmVZSYYlHvLTJtHK7dTMXTXabsuo4S0psFAeJjrURB6UmGrw3 42Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=24gZ/6gg8QS7cCnA9sSTA4xreKt6kedURzox1Y/jxT0=; b=MNef7jV+BQwE3CCl8mQOfScQYrnETKYr6OdqlvEQ7EOYhr6tTtRsy/XwozO3L99uEQ IKN6v6uEo0yCkdSac/IaFYni5BLdc6BFulNIo/0iY6LEiD6THN0geGaGv7tMuKboag3E k0utT1N3JPG7nBbd1kpZmaZTbHWYgoQY7OpJYTTiA1dJq7YvfQ7wiSj0bOc5L8DYFIcQ uV+D3dCg+fA36RbltwbhluVIkNLiZ7zH09XeQV9Fdbi0y0la/bXnlrodjJJGG47WNCJ+ 8Ey/pRXUaDeTHxAKp0a3mvyr+Qq1+VGGxUIfZbR+veB522tmylPdpzJmIgrW2qcq1oL2 2agw== X-Gm-Message-State: APjAAAUj9SGR0/ixiRukJCh+3Jc7A5oXCpISEHZh1ZvXAH3X4ksARPqY BmITZ4XXR86+gFHHWvxYCrz5cNHYuizhzVZ3QL4= X-Google-Smtp-Source: APXvYqzyhMhok2jNfKmCE+Uio1JApuqxgKy+6JQVS9vCqKomSJFLN5atcrjCivqLhQtC/zfUeovCN0LT91a4xeGSqsk= X-Received: by 2002:aca:1817:: with SMTP id h23mr15582695oih.53.1575276927913; Mon, 02 Dec 2019 00:55:27 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a9d:d21:0:0:0:0:0 with HTTP; Mon, 2 Dec 2019 00:55:27 -0800 (PST) In-Reply-To: References: <20191127175257.23480-1-mrolnik@gmail.com> <20191127175257.23480-6-mrolnik@gmail.com> From: Aleksandar Markovic Date: Mon, 2 Dec 2019 09:55:27 +0100 Message-ID: Subject: Re: [PATCH v37 05/17] target/avr: Add instruction translation - Arithmetic and Logic Instructions To: Michael Rolnik Content-Type: multipart/alternative; boundary="000000000000b615570598b4bd34" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::244 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "thuth@redhat.com" , "me@xcancerberox.com.ar" , "richard.henderson@linaro.org" , "qemu-devel@nongnu.org" , "dovgaluk@ispras.ru" , "imammedo@redhat.com" , "philmd@redhat.com" Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --000000000000b615570598b4bd34 Content-Type: text/plain; charset="UTF-8" On Monday, December 2, 2019, Michael Rolnik wrote: > Aleksandar. > > I could not find what happens if an instruction with unsupported registers > is executed. So, I am leaving this tiny core for later. > > No problem with me. You already have instruction support for a rich variety of cores. These can certainly added it in future. May I suggest, then, a following cosmetic change: In order for a reader to get a brtter "first glance" feeling for emulations of ALL instructions that involve updating status register, I suggest that the code blocks like this one: + + /* Vf */ + tcg_gen_movi_tl(cpu_Vf, 0); /* Vf = 0 */ + + /* Zf */ + tcg_gen_setcondi_tl(TCG_COND_EQ, cpu_Zf, R, 0); /* Zf = R == 0 */ + + gen_ZNSf(R); + + /* R */ + tcg_gen_mov_tl(Rd, R); + be replaced with this one: + + /* update status register */ + tcg_gen_movi_tl(cpu_Vf, 0); /* Vf = 0 */ + tcg_gen_setcondi_tl(TCG_COND_EQ, cpu_Zf, R, 0); /* Zf = R == 0 */ + gen_ZNSf(R); + tcg_gen_mov_tl(Rd, R); + The idea is to distinguish visually better the portions for updating status register from the central part of the operation (usually marked by "/* op */" comment. The code also gets more compact, which looks like a good thing too. Aleksandar > Regards, > Michael Rolnik > > On Sun, Dec 1, 2019 at 1:11 AM Aleksandar Markovic < > aleksandar.m.mail@gmail.com> wrote: > >> >> >> On Saturday, November 30, 2019, Michael Rolnik wrote: >> >>> Hi Aleksandar. >>> >>> thanks for pointing that out I was not aware of that. >>> I can fix it. >>> >>> >> Hey, Michael, >> >> Please take alook at this: >> >> https://en.m.wikipedia.org/wiki/ATtiny_microcontroller_comparison_chart >> >> It looks that all cases of AVR 16-gpr-registers cores belong to the group >> "avrtiny10", that actually you may want to add to your solution. Just a >> hint. >> >> Best regards, >> Aleksandar >> >> >> >> Regards, >>> Michael Rolnik >>> >>> On Sat, Nov 30, 2019 at 6:29 PM Aleksandar Markovic < >>> aleksandar.m.mail@gmail.com> wrote: >>> >>>> >>>> >>>> On Saturday, November 30, 2019, Aleksandar Markovic < >>>> aleksandar.m.mail@gmail.com> wrote: >>>> >>>>> >>>>> >>>>> On Wednesday, November 27, 2019, Michael Rolnik >>>>> wrote: >>>>> >>>>> + >>>>>> + >>>>>> +/* >>>>>> + * Performs the logical AND between the contents of register Rd and >>>>>> register >>>>>> + * Rr and places the result in the destination register Rd. >>>>>> + */ >>>>>> +static bool trans_AND(DisasContext *ctx, arg_AND *a) >>>>>> +{ >>>>>> + TCGv Rd = cpu_r[a->rd]; >>>>>> + TCGv Rr = cpu_r[a->rr]; >>>>>> + TCGv R = tcg_temp_new_i32(); >>>>>> + >>>>>> + /* op */ >>>>>> + tcg_gen_and_tl(R, Rd, Rr); /* Rd = Rd and Rr */ >>>>>> + >>>>>> + /* Vf */ >>>>>> + tcg_gen_movi_tl(cpu_Vf, 0); /* Vf = 0 */ >>>>>> + >>>>>> + /* Zf */ >>>>>> + tcg_gen_setcondi_tl(TCG_COND_EQ, cpu_Zf, R, 0); /* Zf = R == 0 >>>>>> */ >>>>>> + >>>>>> + gen_ZNSf(R); >>>>>> + >>>>>> + /* R */ >>>>>> + tcg_gen_mov_tl(Rd, R); >>>>>> + >>>>>> + tcg_temp_free_i32(R); >>>>>> + >>>>>> + return true; >>>>>> +} >>>>>> + >>>>>> + >>>>>> >>>>> >>>>> According to specs: >>>>> >>>>> http://ww1.microchip.com/downloads/en/devicedoc/atmel-42505-8-bit-avr- >>>>> microcontrollers-attiny102-attiny104_datasheet.pdf >>>>> >>>>> ... the chips in question have cores with 16 GPRs (that correspond to >>>>> GPRs R16-R31 of more common AVR cores with 32 GPRs). >>>>> >>>>> >>>> There are more examples; >>>> >>>> http://ww1.microchip.com/downloads/en/DeviceDoc/atmel-8127-avr-8-bit- >>>> microcontroller-attiny4-attiny5-attiny9-attiny10_datasheet.pdf >>>> >>>> Also ATtiny20, ATtiny40. >>>> >>>> How do you handle such cores? >>>>> >>>>> I don't see here anything preventing usage of all 32 GPRs, resulting, >>>>> of course, in an inaccurate emulation. >>>>> >>>>> Thanks, >>>>> Aleksandar >>>>> >>>> >>> >>> -- >>> Best Regards, >>> Michael Rolnik >>> >> > > -- > Best Regards, > Michael Rolnik > --000000000000b615570598b4bd34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Monday, December 2, 2019, Michael Rolnik <mrolnik@gmail.com> wrote:
Aleksandar.

I could not find = what happens if an instruction with unsupported registers is executed. So, = I am leaving this tiny core for later.


No problem with me. You already have instruction sup= port for a rich variety of cores. These can certainly added it in future.

May I suggest, then, a following cosmetic change: I= n order for a reader to get a brtter "first glance" feeling for e= mulations of ALL instructions that involve updating status register, I sugg= est that the code blocks like this one:

+
+=C2=A0 =C2=A0 /* Vf */
+=C2=A0 =C2=A0 t= cg_gen_movi_tl(cpu_Vf, 0); /* Vf =3D 0 */
+
+=C2=A0 =C2=A0 /* Zf */
+=C2=A0 =C2=A0 tcg_gen_setco= ndi_tl(TCG_COND_EQ, cpu_Zf, R, 0); /* Zf =3D R =3D=3D 0= */
+
+=C2=A0 =C2=A0 gen_ZNSf(R);
+
+=C2=A0 =C2=A0 /* R */
+= =C2=A0 =C2=A0 tcg_gen_mov_tl(Rd, R);
+
<= div>
be replaced with this one:
<= br>
+
+=C2=A0 =C2=A0 /* update status re= gister */
+=C2=A0 =C2=A0 tcg_gen_movi_tl(cpu_Vf, 0); /* V= f =3D 0 */
+=C2=A0 =C2=A0 tcg_gen_setcondi_tl(TCG_COND_EQ, cpu_Zf, R, 0); /* Zf =3D R =3D=3D 0 */
+=C2=A0 =C2=A0 gen_ZNSf(R);
+=C2=A0 =C2=A0 tcg_gen_mo= v_tl(Rd, R);
+

The idea is to distinguish visually better the portions for u= pdating status register from the central part of the operation (usually mar= ked by "/* op */" comment. The code also gets more compact, which= looks like a good thing too.

Aleksandar
=C2=A0
Reg= ards,
Michael Rolnik

On Sun, Dec 1, 2019 at 1:11 AM Aleksand= ar Markovic <aleksandar.m.mail@gmail.com> wrote:


On Saturday, November 30, 2019, Mi= chael Rolnik <mro= lnik@gmail.com> wrote:
Hi Aleksandar.

thanks for point= ing that out I was not aware=C2=A0of that.
I can fix it.


Hey, Michael,
=
Please take alook at this:


It looks that all c= ases of AVR 16-gpr-registers cores belong to the group "avrtiny10", that actually you may want to add to your solut= ion. Just a hint.

Best regards,
Aleksandar



Regards,=
Michael Rolnik

On Sat, Nov 30, 2019 at 6:29 PM Aleksandar M= arkovic <aleksandar.m.mail@gmail.com> wrote:


On Saturday, November 30, 2019, Aleksa= ndar Markovic <aleksandar.m.mail@gmail.com> wrote:


On Wednesday, November 27, 2019, Micha= el Rolnik <mrolni= k@gmail.com> wrote:

+
+
+/*
+ *=C2=A0 Performs the logical AND between the contents of register Rd and = register
+ *=C2=A0 Rr and places the result in the destination register Rd.
+ */
+static bool trans_AND(DisasContext *ctx, arg_AND *a)
+{
+=C2=A0 =C2=A0 TCGv Rd =3D cpu_r[a->rd];
+=C2=A0 =C2=A0 TCGv Rr =3D cpu_r[a->rr];
+=C2=A0 =C2=A0 TCGv R =3D tcg_temp_new_i32();
+
+=C2=A0 =C2=A0 /* op */
+=C2=A0 =C2=A0 tcg_gen_and_tl(R, Rd, Rr); /* Rd =3D Rd and Rr */
+
+=C2=A0 =C2=A0 /* Vf */
+=C2=A0 =C2=A0 tcg_gen_movi_tl(cpu_Vf, 0); /* Vf =3D 0 */
+
+=C2=A0 =C2=A0 /* Zf */
+=C2=A0 =C2=A0 tcg_gen_setcondi_tl(TCG_COND_EQ, cpu_Zf, R, 0); /* Zf = =3D R =3D=3D 0 */
+
+=C2=A0 =C2=A0 gen_ZNSf(R);
+
+=C2=A0 =C2=A0 /* R */
+=C2=A0 =C2=A0 tcg_gen_mov_tl(Rd, R);
+
+=C2=A0 =C2=A0 tcg_temp_free_i32(R);
+
+=C2=A0 =C2=A0 return true;
+}
+
+

According to specs:

http://ww1.microchip.com/downloads/en/devicedoc/atmel-42505-8= -bit-avr-microcontrollers-attiny102-attiny104_datasheet.pdf

... the chips in question have cores with= 16 GPRs (that correspond to GPRs R16-R31 of more common AVR cores with 32 = GPRs).


There are more = examples;

Also ATtiny20, ATtiny40.

How do you handle such cores?

I don't see here anything preventing usage of all 32 = GPRs, resulting, of course, in an inaccurate emulation.

Thanks,
Aleksandar


--
Best Regards,
Michael Rolnik


--
Best Regards,
Michael Rolnik
--000000000000b615570598b4bd34--