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,URIBL_BLOCKED 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 0E67EC432C0 for ; Sat, 30 Nov 2019 23:12:17 +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 CCEF520725 for ; Sat, 30 Nov 2019 23:12:16 +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="o5CDT/XO" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CCEF520725 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]:39120 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ibBuR-0005Wo-Uq for qemu-devel@archiver.kernel.org; Sat, 30 Nov 2019 18:12:15 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47602) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ibBtW-0004gr-Be for qemu-devel@nongnu.org; Sat, 30 Nov 2019 18:11:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ibBtU-0004p2-Tm for qemu-devel@nongnu.org; Sat, 30 Nov 2019 18:11:18 -0500 Received: from mail-ot1-x341.google.com ([2607:f8b0:4864:20::341]:43234) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ibBtU-0004l2-KD for qemu-devel@nongnu.org; Sat, 30 Nov 2019 18:11:16 -0500 Received: by mail-ot1-x341.google.com with SMTP id l14so27809239oti.10 for ; Sat, 30 Nov 2019 15:11:15 -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=qksgmx4kXeHyR4rq7zOb2n8ALnn8N5LN8fkASJjEryo=; b=o5CDT/XOuAccnKE+VUllSFGSF3z6tFrpYNwB6UsPQQrFXU21G63KdOk8OwWNAvD6OF tCi01tKJHqm1B9SrhzGtIPaTTtfHPYaFh3YDkbHFaYI2TpFTzAyfqNRpSYgU561S34cS AUJF6YcwkgkI+ENg21uH6eq0XZRpTirQT1YlqyYCax9CJEsWaAQEEzctXUV54OLEd9cr NMh9m/WMgFuIAKTB61BZi8FooAV85IqqiviBHnIURqTEAA4ZZnFqnEY/mdSYNEUwzgnH 5a4O4+h31YNdS0Y0pOChvUyCpTxzS+m6XoeaR6kIFrXEaWGvOLCuVDhtkvto/D82Jm1G t25w== 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=qksgmx4kXeHyR4rq7zOb2n8ALnn8N5LN8fkASJjEryo=; b=HngHqAKgLJ/+aXjJixn0vMD/2iSTjw5ciQHF5YlKKQ8QImJVrz1SX0MArxcbb2CqUg VGujjV+yoX1/OyuYC0fr2A7NlJgzWBYxkk8tbuL++Nk04SGtBX3pSwEJKlrxlPBqMArd TYzbZDEvPGmoWKIGdieyRtBAs52bwmLp5mKFGt18Ul92gO7PlVofExsUvPI+h3YBVZk0 gbJJ1FyG3bVpZS/k2bfzyzC9y71XU5JfzSz7SE0naohKdh6uynywQEaNAD8+91AJFErA y8H2/3P8XlqQvebAAjzTQBJM/vS0qTcevaSJKaZcjuRDTdrQxjw3jobiBnFvxd6YIc/t VmOg== X-Gm-Message-State: APjAAAVSaLBwFi4DCE5o8IBKB1LsO2N/yNodAYxSS1xlwk8HLtaxKZj4 mzAWzzrxGpB+fcd9K3Whgjpe+huiaWKWw3tuBB0= X-Google-Smtp-Source: APXvYqwHx6nK0DTqKdn/eC+IbJW6sRSLH9T10gKkSJjbyApZPA6T6HcsFHgxaWmy0G8XJnYUB2P/oU51qXBQaMCOgf4= X-Received: by 2002:a9d:58c9:: with SMTP id s9mr10924720oth.121.1575155474754; Sat, 30 Nov 2019 15:11:14 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1391:0:0:0:0 with HTTP; Sat, 30 Nov 2019 15:11:13 -0800 (PST) In-Reply-To: References: <20191127175257.23480-1-mrolnik@gmail.com> <20191127175257.23480-6-mrolnik@gmail.com> From: Aleksandar Markovic Date: Sun, 1 Dec 2019 00:11:13 +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="00000000000089f17d0598987674" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::341 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" --00000000000089f17d0598987674 Content-Type: text/plain; charset="UTF-8" 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 > --00000000000089f17d0598987674 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Saturday, November 30, 2019, Michael Rolnik <mrolnik@gmail.com> wrote:
Hi Aleksandar.

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


Hey, Michael,

Please take alook at this:

https://en.m.wikipedia.org/wiki/ATtiny_microcontroller_comparison_ch= art

It looks that all cases of AVR 16-gpr-regi= sters cores belong to the group "av= rtiny10", that actually you may want to add to your solution. Just a h= int.

<= div>Best regards,
Aleks= andar



Regards,
Michael Rolnik

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


On Saturday, Novembe= r 30, 2019, Aleksandar Markovic <aleksandar.m.mail@gmail.com> wrote:


On Wednesday, Novemb= er 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
--00000000000089f17d0598987674--