From: Aleksandar Markovic <aleksandar.m.mail@gmail.com>
To: Michael Rolnik <mrolnik@gmail.com>
Cc: "thuth@redhat.com" <thuth@redhat.com>,
"richard.henderson@linaro.org" <richard.henderson@linaro.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"dovgaluk@ispras.ru" <dovgaluk@ispras.ru>,
"imammedo@redhat.com" <imammedo@redhat.com>,
"philmd@redhat.com" <philmd@redhat.com>
Subject: Re: [PATCH v32 04/13] target/avr: Add instruction translation - Registers definition
Date: Fri, 18 Oct 2019 18:51:04 +0200 [thread overview]
Message-ID: <CAL1e-=g4H84RAX231Gg1+MXMh-YzRV0fuUj4u98QASLJ1xzd=A@mail.gmail.com> (raw)
In-Reply-To: <CAK4993j44GK=zyuGbo86Li=7Gt2BrwWuzdLe3rggnOtMPR7f2Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 8870 bytes --]
On Friday, October 18, 2019, Michael Rolnik <mrolnik@gmail.com> wrote:
> On Fri, Oct 18, 2019 at 4:23 PM Aleksandar Markovic
> <aleksandar.m.mail@gmail.com> wrote:
> >
> >
> >
> > On Friday, October 18, 2019, Michael Rolnik <mrolnik@gmail.com> wrote:
> >>
> >>
> >>
> >> On Fri, Oct 18, 2019 at 11:52 AM Aleksandar Markovic <
> aleksandar.m.mail@gmail.com> wrote:
> >>>
> >>>
> >>>
> >>> On Thursday, October 17, 2019, Michael Rolnik <mrolnik@gmail.com>
> wrote:
> >>>>
> >>>> On Thu, Oct 17, 2019 at 11:17 PM Aleksandar Markovic
> >>>> <aleksandar.m.mail@gmail.com> wrote:
> >>>> >>
> >>>> >>
> >>>> >> >> +static TCGv cpu_Cf;
> >>>> >> >> +static TCGv cpu_Zf;
> >>>> >> >> +static TCGv cpu_Nf;
> >>>> >> >> +static TCGv cpu_Vf;
> >>>> >> >> +static TCGv cpu_Sf;
> >>>> >> >> +static TCGv cpu_Hf;
> >>>> >> >> +static TCGv cpu_Tf;
> >>>> >> >> +static TCGv cpu_If;
> >>>> >> >> +
> >>>> >> >
> >>>> >> >
> >>>> >> > Hello, Michael,
> >>>> >> >
> >>>> >> > Is there any particular reason or motivation beyond modelling
> status register flags as TCGv variables?
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >> I think it's easier this way as I don't need to convert flag
> values to
> >>>> >> bits or bits to flag values.
> >>>> >
> >>>> >
> >>>> > Ok. But, how do you map 0/1 flag value to the value of a TCGv
> variable and vice versa? In other words, what value or values (out of 2^32
> vales) of a TCGv variable mean the flag is 1? And the same question for 0.
> >>>> >
> >>>> > Is 0110000111000010100 one or zero?
> >>>> >
> >>>> > Besides, in such arrangement, how do you display the 8-bit status
> register in gdb, if at all?
> >>>>
> >>>> each flag register is either 0 or 1,....
> >>>>
> >>>>
> >>>>
> >>>
> >>> Michael,
> >>>
> >>> If this is true, why is there a special handling of two flags in the
> following code:
> >>>
> >>>
> >>> static inline uint8_t cpu_get_sreg(CPUAVRState *env)
> >>> {
> >>> uint8_t sreg;
> >>> sreg = (env->sregC & 0x01) << 0
> >>> | (env->sregZ == 0 ? 1 : 0) << 1
> >>> | (env->sregN) << 2
> >>> | (env->sregV) << 3
> >>> | (env->sregS) << 4
> >>> | (env->sregH) << 5
> >>> | (env->sregT) << 6
> >>> | (env->sregI) << 7;
> >>> return sreg;
> >>> }
> >>> static inline void cpu_set_sreg(CPUAVRState *env, uint8_t sreg)
> >>> {
> >>> env->sregC = (sreg >> 0) & 0x01;
> >>> env->sregZ = (sreg >> 1) & 0x01 ? 0 : 1;
> >>> env->sregN = (sreg >> 2) & 0x01;
> >>> env->sregV = (sreg >> 3) & 0x01;
> >>> env->sregS = (sreg >> 4) & 0x01;
> >>> env->sregH = (sreg >> 5) & 0x01;
> >>> env->sregT = (sreg >> 6) & 0x01;
> >>> env->sregI = (sreg >> 7) & 0x01;
> >>> }
> >>> ?
> >>>
> >> Aleksandar,
> >>
> >> If I understand your question correctly cpu_get_sreg assembles SREG
> value to be presented by GDB, and cpu_set_sreg sets flags values when GDB
> modifies SREG.
> >>
> >> Michael
> >
> >
> >
> >
Why is handling of sregC and sregZ flags different than handling of other
> flags? This contradicts your previos statement that 1 (in TCGv) means 1
> (flag), and 0 (in TCGv) means 0 (flag)?
> >
> >
> > Whatever is the explanation, ot should be included, in my opinion, in
> code comments.
> >
> > Please, Michael, let's first clarify the issue from the question above.
> >
> > Thanks, Aleksandar
> >
> >
> there is a comment here
> https://github.com/michaelrolnik/qemu-avr/blob/
> master/target/avr/cpu.h#L122-L129
> >
...but it does explain WHY of my question.
The reason I insist on your explanation is that when we model a cpu or a
device in QEMU, a goal is that the model is as close to the hardware as
possible. One may not, for pletora of reasons, succeed in reaching that
goal, or, I can imagine, on purpose depart from that goal for some reason -
perhaps that was the case in your implementation, where you modelled a
single 8-bit status register with 8 TCGv variables.
But, even that way of modelling was done inconsistently across bits of the
status register. In that light, I want to know the justification for that,
so repeat my question: Why is handling of sregC and sregZ flags different
than handling of other flags in functions cpu_get_sreg()
and cpu_get_sreg()? This was not explained in any comment or commit
message. And is in contradiction with one of your previous answers.
Yours,
Aleksandar
> >
> >
> >>>
> >>> Thanks,
> >>> A.
> >>>>
> >>>>
> >>>> they are calculated here
> >>>> 1. https://github.com/michaelrolnik/qemu-avr/blob/
> avr-v32/target/avr/translate.c#L146-L148
> >>>> 2. https://github.com/michaelrolnik/qemu-avr/blob/
> avr-v32/target/avr/translate.c#L166
> >>>> 3. https://github.com/michaelrolnik/qemu-avr/blob/
> avr-v32/target/avr/translate.c#L185-L187
> >>>> 4. https://github.com/michaelrolnik/qemu-avr/blob/
> avr-v32/target/avr/translate.c#L205
> >>>> 5. https://github.com/michaelrolnik/qemu-avr/blob/
> avr-v32/target/avr/translate.c#L214-L215
> >>>> 6. https://github.com/michaelrolnik/qemu-avr/blob/
> avr-v32/target/avr/translate.c#L222-L223
> >>>> The COU itself never uses SREG at all, only the flags.
> >>>>
> >>>> As for the GDB it's get assembled/disassembled here
> >>>> 1. https://github.com/michaelrolnik/qemu-avr/blob/
> avr-v32/target/avr/cpu.h#L219-L243
> >>>> 2. https://github.com/michaelrolnik/qemu-avr/blob/
> avr-v32/target/avr/gdbstub.c#L35-L37
> >>>> 3. https://github.com/michaelrolnik/qemu-avr/blob/
> avr-v32/target/avr/gdbstub.c#L66-L68
> >>>>
> >>>> >
> >>>> > A.
> >>>> >
> >>>> >>
> >>>> >> >
> >>>> >> > A.
> >>>> >> >
> >>>> >> >
> >>>> >> >
> >>>> >> >>
> >>>> >> >> +static TCGv cpu_rampD;
> >>>> >> >> +static TCGv cpu_rampX;
> >>>> >> >> +static TCGv cpu_rampY;
> >>>> >> >> +static TCGv cpu_rampZ;
> >>>> >> >> +
> >>>> >> >> +static TCGv cpu_r[NO_CPU_REGISTERS];
> >>>> >> >> +static TCGv cpu_eind;
> >>>> >> >> +static TCGv cpu_sp;
> >>>> >> >> +
> >>>> >> >> +static TCGv cpu_skip;
> >>>> >> >> +
> >>>> >> >> +static const char reg_names[NO_CPU_REGISTERS][8] = {
> >>>> >> >> + "r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7",
> >>>> >> >> + "r8", "r9", "r10", "r11", "r12", "r13", "r14", "r15",
> >>>> >> >> + "r16", "r17", "r18", "r19", "r20", "r21", "r22", "r23",
> >>>> >> >> + "r24", "r25", "r26", "r27", "r28", "r29", "r30", "r31",
> >>>> >> >> +};
> >>>> >> >> +#define REG(x) (cpu_r[x])
> >>>> >> >> +
> >>>> >> >> +enum {
> >>>> >> >> + DISAS_EXIT = DISAS_TARGET_0, /* We want return to the
> cpu main loop. */
> >>>> >> >> + DISAS_LOOKUP = DISAS_TARGET_1, /* We have a variable
> condition exit. */
> >>>> >> >> + DISAS_CHAIN = DISAS_TARGET_2, /* We have a single
> condition exit. */
> >>>> >> >> +};
> >>>> >> >> +
> >>>> >> >> +typedef struct DisasContext DisasContext;
> >>>> >> >> +
> >>>> >> >> +/* This is the state at translation time. */
> >>>> >> >> +struct DisasContext {
> >>>> >> >> + TranslationBlock *tb;
> >>>> >> >> +
> >>>> >> >> + CPUAVRState *env;
> >>>> >> >> + CPUState *cs;
> >>>> >> >> +
> >>>> >> >> + target_long npc;
> >>>> >> >> + uint32_t opcode;
> >>>> >> >> +
> >>>> >> >> + /* Routine used to access memory */
> >>>> >> >> + int memidx;
> >>>> >> >> + int bstate;
> >>>> >> >> + int singlestep;
> >>>> >> >> +
> >>>> >> >> + TCGv skip_var0;
> >>>> >> >> + TCGv skip_var1;
> >>>> >> >> + TCGCond skip_cond;
> >>>> >> >> + bool free_skip_var0;
> >>>> >> >> +};
> >>>> >> >> +
> >>>> >> >> +static int to_A(DisasContext *ctx, int indx) { return 16 +
> (indx % 16); }
> >>>> >> >> +static int to_B(DisasContext *ctx, int indx) { return 16 +
> (indx % 8); }
> >>>> >> >> +static int to_C(DisasContext *ctx, int indx) { return 24 +
> (indx % 4) * 2; }
> >>>> >> >> +static int to_D(DisasContext *ctx, int indx) { return (indx %
> 16) * 2; }
> >>>> >> >> +
> >>>> >> >> +static uint16_t next_word(DisasContext *ctx)
> >>>> >> >> +{
> >>>> >> >> + return cpu_lduw_code(ctx->env, ctx->npc++ * 2);
> >>>> >> >> +}
> >>>> >> >> +
> >>>> >> >> +static int append_16(DisasContext *ctx, int x)
> >>>> >> >> +{
> >>>> >> >> + return x << 16 | next_word(ctx);
> >>>> >> >> +}
> >>>> >> >> +
> >>>> >> >> +
> >>>> >> >> +static bool avr_have_feature(DisasContext *ctx, int feature)
> >>>> >> >> +{
> >>>> >> >> + if (!avr_feature(ctx->env, feature)) {
> >>>> >> >> + gen_helper_unsupported(cpu_env);
> >>>> >> >> + ctx->bstate = DISAS_NORETURN;
> >>>> >> >> + return false;
> >>>> >> >> + }
> >>>> >> >> + return true;
> >>>> >> >> +}
> >>>> >> >> +
> >>>> >> >> +static bool decode_insn(DisasContext *ctx, uint16_t insn);
> >>>> >> >> +#include "decode_insn.inc.c"
> >>>> >> >> +
> >>>> >> >> --
> >>>> >> >> 2.17.2 (Apple Git-113)
> >>>> >> >>
> >>>> >>
> >>>> >>
> >>>> >> --
> >>>> >> Best Regards,
> >>>> >> Michael Rolnik
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Best Regards,
> >>>> Michael Rolnik
> >>
> >>
> >>
> >> --
> >> Best Regards,
> >> Michael Rolnik
>
>
>
> --
> Best Regards,
> Michael Rolnik
>
[-- Attachment #2: Type: text/html, Size: 16024 bytes --]
next prev parent reply other threads:[~2019-10-18 16:53 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-14 16:18 [PATCH v32 00/13] QEMU AVR 8 bit cores Michael Rolnik
2019-10-14 16:18 ` [PATCH v32 01/13] target/avr: Add outward facing interfaces and core CPU logic Michael Rolnik
2019-10-14 16:18 ` [PATCH v32 02/13] target/avr: Add instruction helpers Michael Rolnik
2019-10-14 16:18 ` [PATCH v32 03/13] target/avr: Add instruction decoding Michael Rolnik
2019-10-14 16:18 ` [PATCH v32 04/13] target/avr: Add instruction translation - Registers definition Michael Rolnik
2019-10-17 17:25 ` Aleksandar Markovic
2019-10-17 19:15 ` Michael Rolnik
2019-10-17 20:16 ` Aleksandar Markovic
2019-10-17 20:43 ` Michael Rolnik
2019-10-18 8:52 ` Aleksandar Markovic
2019-10-18 11:27 ` Michael Rolnik
2019-10-18 12:10 ` Michael Rolnik
2019-10-18 13:23 ` Aleksandar Markovic
2019-10-18 13:56 ` Michael Rolnik
2019-10-18 16:51 ` Aleksandar Markovic [this message]
2019-10-18 18:08 ` Aleksandar Markovic
2019-10-19 20:18 ` Michael Rolnik
2019-10-14 16:18 ` [PATCH v32 05/13] target/avr: Add instruction translation - Arithmetic and Logic Instructions Michael Rolnik
2019-10-14 16:18 ` [PATCH v32 06/13] target/avr: Add instruction translation - Branch Instructions Michael Rolnik
2019-10-14 16:18 ` [PATCH v32 07/13] target/avr: Add instruction translation - Bit and Bit-test Instructions Michael Rolnik
2019-10-14 16:18 ` [PATCH v32 08/13] target/avr: Add instruction translation - MCU Control Instructions Michael Rolnik
2019-10-14 16:18 ` [PATCH v32 09/13] target/avr: Add instruction translation - CPU main translation function Michael Rolnik
2019-10-14 16:18 ` [PATCH v32 10/13] target/avr: Add limited support for USART and 16 bit timer peripherals Michael Rolnik
2019-10-14 16:18 ` [PATCH v32 11/13] target/avr: Add example board configuration Michael Rolnik
2019-10-14 16:18 ` [PATCH v32 12/13] target/avr: Register AVR support with the rest of QEMU, the build system, and the WMAINTAINERS file Michael Rolnik
2019-10-14 16:18 ` [PATCH v32 13/13] target/avr: Add tests Michael Rolnik
-- strict thread matches above, loose matches on Subject: below --
2019-10-13 7:47 [PATCH v32 00/13] QEMU AVR 8 bit cores Michael Rolnik
2019-10-13 7:47 ` [PATCH v32 04/13] target/avr: Add instruction translation - Registers definition Michael Rolnik
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='CAL1e-=g4H84RAX231Gg1+MXMh-YzRV0fuUj4u98QASLJ1xzd=A@mail.gmail.com' \
--to=aleksandar.m.mail@gmail.com \
--cc=dovgaluk@ispras.ru \
--cc=imammedo@redhat.com \
--cc=mrolnik@gmail.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=thuth@redhat.com \
/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).