[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v37 05/17] target/avr: Add instruction translation - Arithmet
|
From: |
Aleksandar Markovic |
|
Subject: |
Re: [PATCH v37 05/17] target/avr: Add instruction translation - Arithmetic and Logic Instructions |
|
Date: |
Mon, 2 Dec 2019 09:55:27 +0100 |
On Monday, December 2, 2019, Michael Rolnik <address@hidden> 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
On Sun, Dec 1, 2019 at 1:11 AM Aleksandar Markovic <
address@hidden> wrote:
On Saturday, November 30, 2019, Michael Rolnik <address@hidden> 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:
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
On Sat, Nov 30, 2019 at 6:29 PM Aleksandar Markovic <
address@hidden> wrote:
On Saturday, November 30, 2019, Aleksandar Markovic <address@hidden> wrote:
On Wednesday, November 27, 2019, Michael Rolnik <address@hidden> 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:
... 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