public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: Stafford Horne <shorne@gmail.com>
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:14:00 -0000	[thread overview]
Message-ID: <617acff0490f4ae9ffcf961fb55b2ef1@polymtl.ca> (raw)
In-Reply-To: <aaf9bb46e9b3a59d1fff197c08fa25c7e0bd3b16.1496066478.git.shorne@gmail.com>

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.

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?

> +
> +#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?

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.

Thanks,

Simon

  reply	other threads:[~2017-09-04 21:14 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 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: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:48 ` [PATCH v4 3/5] sim: or1k: add or1k target to sim Stafford Horne
2017-09-04 21:14   ` Simon Marchi [this message]
2017-09-04 21:49     ` Stafford Horne
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=617acff0490f4ae9ffcf961fb55b2ef1@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=gdb-patches@sourceware.org \
    --cc=openrisc@lists.librecores.org \
    --cc=shorne@gmail.com \
    --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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).