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 9B3DBC432C0 for ; Mon, 2 Dec 2019 09:02:45 +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 56CDA2231B for ; Mon, 2 Dec 2019 09:02:45 +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="cZwuwVzA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 56CDA2231B 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]:60822 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ibhbQ-0008TY-Hg for qemu-devel@archiver.kernel.org; Mon, 02 Dec 2019 04:02:44 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50877) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ibha9-0007Q5-2H for qemu-devel@nongnu.org; Mon, 02 Dec 2019 04:01:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ibha7-0005Fy-67 for qemu-devel@nongnu.org; Mon, 02 Dec 2019 04:01:24 -0500 Received: from mail-ot1-x344.google.com ([2607:f8b0:4864:20::344]:36352) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ibha6-0005FZ-Q1 for qemu-devel@nongnu.org; Mon, 02 Dec 2019 04:01:23 -0500 Received: by mail-ot1-x344.google.com with SMTP id i4so3485856otr.3 for ; Mon, 02 Dec 2019 01:01:22 -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=yXcORxTGPt1VrU/1lhDjcVCbReSDnNfKZVMf0iJfjoM=; b=cZwuwVzAmN5cyI8hq31cHJ50o0e0l8zoUnqu4BoxdIJFMyfc3gas53UrdKnp0pjVb4 myoyJa7NlJ73v1HMiPCu/jhj9stYwbs0Ym0cvFQVFTcHu/DiUJHIl849qFpccGWwtAgo /PNT4+gbCcX7JUYZEDEHzX3FGfoUxp8mGKjzR1iE2icCaoy2pB8xXgnfE3PBcFjSfTCS GBe2dTLVhN6Yr9xOm2IbJc9kj/RX/F5YPj37wg1jPVYGg9KIwCduURd8/hE9nRsxjFo2 0nK6ngOyAqvlwKEOiqWpRE5wSsHG9LTmBG7qMvxC3b9AnOkPb7isHXOTp1c2NMMcpJgG cCDg== 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=yXcORxTGPt1VrU/1lhDjcVCbReSDnNfKZVMf0iJfjoM=; b=DApokTnU3PcWxjUVpvRJmfWdeTDl90dEngAwCmQDvCusYrqeEgfmrLxS+BnFqbJExd gFYs0YzFpCdJevg+Dgh00nUYpLNch51wLmdMYOVEJt6xSS/xAzOME7wyHEJzEyHe0cj2 7abfSS02T6TKa7VTiNvb/lKOkhBOWzJ2Ju79k1cmMb/QOv9bgvB56atj+tTMKAH0Ljhb ZpEkmtSqesbOd0Iluxu8mQlu8aB9UXMx2hyeVX1RNsr882AYLzBzxDKRqLfeDrOyuwld 1yx4O+1CnKFfAFtEd98dJTMkAc1gv6XtJeQRU7bb57oMLUgwOx7/ZLjdT/AYBQalU1bE IjTw== X-Gm-Message-State: APjAAAXg5kpU4OPXRIZyfofFAyfpBe7ShgeYThBZXEBw8lj65/+XHKnY kvx2Sh5O3PFmzpuKZyEAcSDfdHyqUOa9vYohDGg= X-Google-Smtp-Source: APXvYqxKvB/A5eoCOZMNB1CHhSb75C+J/LhQSf7Zztawfop2UGonIDVXma/n5/lpaKsexpdxAQlphWFWPkZ4g3tJO9w= X-Received: by 2002:a9d:58c9:: with SMTP id s9mr15061037oth.121.1575277281563; Mon, 02 Dec 2019 01:01:21 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a9d:d21:0:0:0:0:0 with HTTP; Mon, 2 Dec 2019 01:01:21 -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 10:01:21 +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="000000000000ca5f8d0598b4d232" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::344 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" --000000000000ca5f8d0598b4d232 Content-Type: text/plain; charset="UTF-8" On Monday, December 2, 2019, Aleksandar Markovic < aleksandar.m.mail@gmail.com> wrote: > > > + > + /* 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); > + > My email client drives me crazy, all lines from the above segment should be consecutive, without any empty lines in between. If you see empty lines, that is because of my email client. > 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 >> > --000000000000ca5f8d0598b4d232 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Monday, December 2, 2019, Aleksandar Markovic <aleksandar.m.mail@gmail.com> wrote:=

+
+=C2=A0 =C2=A0 /* update status register */
+=C2=A0 = =C2=A0 tcg_gen_movi_tl(cpu_Vf, 0); /* Vf =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_mov_tl(Rd, R);
+

My email client = drives me crazy, all lines from the above segment should be consecutive, wi= thout any empty lines in between. If you see empty lines, that is because o= f my email client.=C2=A0


The idea is to distingui= sh visually better the portions for updating status register from the centr= al part of the operation (usually marked by "/* op */" comment. T= he code also gets more compact, which looks like a good thing too.

Aleksandar
=C2=A0
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 <mrolnik@gmail.com> wrote:
Hi Aleksand= ar.

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

=
Hey, Michael,

Please take alook at = this:

<= div>
It looks that all cases of AVR 16-gpr-registers cores be= long to the group "avrtiny10", that actu= ally 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 <mrolnik@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
--000000000000ca5f8d0598b4d232--