Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Stafford Horne <shorne@gmail.com>
To: Simon Marchi <simon.marchi@polymtl.ca>
Cc: GDB patches <gdb-patches@sourceware.org>,
	Openrisc <openrisc@lists.librecores.org>,
	Mike Frysinger <vapier@gentoo.org>
Subject: Re: [PATCH v4 3/5] sim: or1k: add or1k target to sim
Date: Mon, 04 Sep 2017 21:49:00 -0000	[thread overview]
Message-ID: <20170904214854.GN2609@lianli.shorne-pla.net> (raw)
In-Reply-To: <617acff0490f4ae9ffcf961fb55b2ef1@polymtl.ca>

On Mon, Sep 04, 2017 at 11:14:13PM +0200, Simon Marchi wrote:
> Hi Stafford,
> 
> I started to look at this patch, and I have to say that it's quite difficult
> for an outsider like me to follow.  I can see what the code is doing, and
> can correlate some parts with the openrisc spec.  But since there are no
> comments at all, I have no idea what the intents are, so I can't really tell
> whether the code is right or wrong wrt the intent.  Maybe it's just because
> of my lack of experience in the area, and somebody familiar with the sim
> code would find it obvious.  Still, I think adding some comments would help
> future contributors.

Fair enough,  to me I am also an outsider having inherited this.  It took
me some time to figure this all out as well.

I will try to add some comments.

> For example, in or1k_cpu_init:
> 
> > +void
> > +or1k_cpu_init (SIM_DESC sd, sim_cpu * current_cpu, const USI or1k_vr,
> > +	       const USI or1k_upr, const USI or1k_cpucfgr)
> > +{
> > +  SET_H_SYS_VR (or1k_vr);
> > +  SET_H_SYS_UPR (or1k_upr);
> > +  SET_H_SYS_CPUCFGR (or1k_cpucfgr);
> > +
> > +#define CHECK_SPR_FIELD(GROUP, INDEX, FIELD, test)
> > \
> > +  do {
> > \
> > +    USI field = GET_H_##SYS##_##INDEX##_##FIELD ();
> > \
> > +    if (!(test)) {
> > \
> > +      sim_io_eprintf(sd, "WARNING: unsupported %s field in %s
> > register: 0x%x\n", \
> > +                     #FIELD, #INDEX, field);
> > \
> > +    }
> > \
> > +  } while (0)
> > +
> > +  current_cpu->next_delay_slot = 0;
> > +  current_cpu->delay_slot = 0;
> > +
> > +  CHECK_SPR_FIELD (SYS, UPR, UP, field == 1);
> > +  CHECK_SPR_FIELD (SYS, UPR, DCP, field == 0);
> > +  CHECK_SPR_FIELD (SYS, UPR, ICP, field == 0);
> > +  CHECK_SPR_FIELD (SYS, UPR, DMP, field == 0);
> > +  CHECK_SPR_FIELD (SYS, UPR, MP, field == 0);
> > +  CHECK_SPR_FIELD (SYS, UPR, IMP, field == 0);
> > +  CHECK_SPR_FIELD (SYS, UPR, DUP, field == 0);
> > +  CHECK_SPR_FIELD (SYS, UPR, PCUP, field == 0);
> > +  CHECK_SPR_FIELD (SYS, UPR, PICP, field == 0);
> > +  CHECK_SPR_FIELD (SYS, UPR, PMP, field == 0);
> > +  CHECK_SPR_FIELD (SYS, UPR, TTP, field == 0);
> > +  CHECK_SPR_FIELD (SYS, UPR, CUP, field == 0);
> > +
> > +  CHECK_SPR_FIELD (SYS, CPUCFGR, NSGR, field == 0);
> > +  CHECK_SPR_FIELD (SYS, CPUCFGR, CGF, field == 0);
> > +  CHECK_SPR_FIELD (SYS, CPUCFGR, OB32S, field == 1);
> > +  CHECK_SPR_FIELD (SYS, CPUCFGR, OB64S, field == 0);
> > +  CHECK_SPR_FIELD (SYS, CPUCFGR, OF64S, field == 0);
> > +  CHECK_SPR_FIELD (SYS, CPUCFGR, OV64S, field == 0);
> 
> Here, I think a comment should explain what these checks are about.  I
> understand they are checking for CPU features, making sure they are or
> aren't there, but why?

These registers it checks, the UPR (unit present register) and CPUCFGR (CPU
configuration register), specify how the system has been configured.  I.e.
which features are available.

Here we do some sanity checks to make sure its not configured to enable
modules that are not available in the sim. Some flags can be configurable,
but the ones checked above cannot be. The configuration of the sim can be
passed in the by user as we can see in sim_open(), thats why these
validations are needed.

> > +
> > +#undef CHECK_SPR_FIELD
> > +
> > +  SET_H_SYS_UPR_UP (1);
> 
> This, looks fishy to me, but maybe there's a good reason for it to be there?
> In the checks above we made sure that the UP bit of the UPR register was
> set.  Why do we need to set it here?

This is here to configure the UPR[UP] (UPR is present flag) to 1, even in
case we didnt set it above when we do:

  SET_H_SYS_UPR (or1k_upr);

The call to SET_H_SYS_UPR() sets all of the flags in the UPR as sent in
from the user arguments.  If they didn't set UPR[UP] we make sure it gets
set.

> I understand that there can't be (and we don't want) a comment for each
> source line, but at least some high level ones.
> 

Understood, Ill try to make the major points commented.  Especially where
some of the more complicated code generation macros are used.

-Stafford


  reply	other threads:[~2017-09-04 21:49 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-29 14:47 [PATCH v4 0/5] sim port for OpenRISC Stafford Horne
2017-05-29 14:47 ` [PATCH v4 2/5] sim: cgen: add MUL2OFSI and MUL1OFSI macros (needed for OR1K l.mul[u]) Stafford Horne
2017-09-04 20:32   ` Simon Marchi
2017-09-04 21:05     ` Stafford Horne
2017-05-29 14:47 ` [PATCH v4 1/5] sim: cgen: add remainder functions (needed for OR1K lf.rem.[sd]) Stafford Horne
2017-08-31 21:11   ` Simon Marchi
2017-08-31 22:33     ` Stafford Horne
2017-09-01  7:57       ` Simon Marchi
2017-09-01  8:29         ` Stafford Horne
2017-05-29 14:48 ` [PATCH v4 3/5] sim: or1k: add or1k target to sim Stafford Horne
2017-09-04 21:14   ` Simon Marchi
2017-09-04 21:49     ` Stafford Horne [this message]
2017-09-05 18:53       ` Simon Marchi
2017-05-29 14:49 ` [PATCH v4 5/5] sim: testsuite: add testsuite for or1k sim Stafford Horne
2017-06-13 10:15 ` [PATCH v4 0/5] sim port for OpenRISC Stafford Horne
2017-08-10 13:22   ` Stafford Horne
2017-08-23  6:29     ` Stafford Horne
2017-08-31 19:57       ` Simon Marchi
2017-08-31 21:58         ` Stafford Horne

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=20170904214854.GN2609@lianli.shorne-pla.net \
    --to=shorne@gmail.com \
    --cc=gdb-patches@sourceware.org \
    --cc=openrisc@lists.librecores.org \
    --cc=simon.marchi@polymtl.ca \
    --cc=vapier@gentoo.org \
    /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