From: Doug Evans <dje@transmeta.com>
To: Dave Brolley <brolley@redhat.com>
Cc: cgen@sources.redhat.com
Subject: Re: CGEN: RFA: Fast vs Full with scache-pbb
Date: Wed, 06 Sep 2000 14:45:00 -0000 [thread overview]
Message-ID: <14774.47827.940964.97339@casey.transmeta.com> (raw)
In-Reply-To: <39B6B44B.A541F8A5@redhat.com>
Dave Brolley writes:
> Doug Evans wrote:
> >
> > Dave Brolley writes:
> > > > It turns out that the call to <cpu>_pbb_begin in the generated
> > > > <cpu>_sem_x_begin was passing STATE_RUN_FAST_P (CPU_STATE
> > > > (current_cpu)) as the 'fast_p' argument. Now this flag will be 0
> > > > if -t is specified and 1 otherwise. However the rest of the
> > > > generated code (mloop.c, sem.c) is not set up for dynamic
> > > > fast/full switching (although it looks like some work was done
> > > > toward this goal in the past). As a result, only the 'sem_full'
> > > > function in the idesc_table is initialized for my build. Passing
> > > > fast_p==1 causes the semantic engine to attempt to use 'sem_fast'
> > > > function which is not initialized.
> >
> > What do you mean by "dynamic fast/full switching".
>
> As far as I can tell, one can supply two versions of the semantic
> functions: 'fast' or 'full'. It looks like the intent was that
> the use of fast vs full semantics could be switched on the fly at
> simulation time via the 'fast_p' parameter to 'extract' and
> 'execute',
There are two separate things here. Don't get them confused.
1) ability to select fast/full when the user invokes the simulator
- this is the normal case
- one can claim this is a variant of (2) but that's not necessarily
the case so let's keep it distinct
2) ability to select fast/full while the simulator is running
- I can't remember if I played much with this. One use would be
when one wants to trace selective pieces of code or not trace
until some "event" occured.
(I'm using a _very_ loose definition of "event" here.)
> however this capability is currently thwarted by at
> least three things:
>
> 1) The generated code in mloop.c contains '#define FAST_P 0' or
> '#define FAST_P 1' which is then passed to extract and execute.
Yep. Note that because it's a constant, gcc can do constant folding on it.
> 2) Only one of 'sem_fast' or 'sem_full' is initialized in the
> idesc_table based on the FAST_P macro(sem.c)
But the file may get compiled twice.
Note this code in, for example, m32r/sem.c:
/* This is used so that we can compile two copies of the semantic code,
one with full feature support and one without that runs fast(er).
FAST_P, when desired, is defined on the command line, -DFAST_P=1. */
#if FAST_P
#define SEM_FN_NAME(cpu,fn) XCONCAT3 (cpu,_semf_,fn)
#undef TRACE_RESULT
#define TRACE_RESULT(cpu, abuf, name, type, val)
#else
#define SEM_FN_NAME(cpu,fn) XCONCAT3 (cpu,_sem_,fn)
#endif
> 3) sc->argbug.semantic contains sem_fast and sem_full members,
> but is a union so you really only get one or the other.
Not quite. Whether you get one, the other, or both, depends
on how things are built. From sim/common/cgen-engine.h:
/* In the ARGBUF struct, a pointer to the semantic routine for the insn. */
union sem {
#if ! WITH_SEM_SWITCH_FULL
SEMANTIC_FN *sem_full;
#endif
#if ! WITH_SEM_SWITCH_FAST
SEMANTIC_FN *sem_fast;
#endif
#if WITH_SEM_SWITCH_FULL || WITH_SEM_SWITCH_FAST
#ifdef __GNUC__
void *sem_case;
#else
int sem_case;
#endif
#endif
};
> My patch simply forces the call to <cpu>_pbb_begin to honour the
> definition of FAST_P like the rest of sem.c does.
There may still be a need for your patch, but maybe you could confirm
you're building your simulator the way the m32r and fr30 sims are?
I wonder if there's a target specific tweak that is the more
appropriate fix.
next prev parent reply other threads:[~2000-09-06 14:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-09-01 11:53 Dave Brolley
2000-09-03 19:23 ` Ben Elliston
2000-09-05 9:17 ` Dave Brolley
2000-09-06 13:37 ` Doug Evans
2000-09-06 14:17 ` Dave Brolley
2000-09-06 14:45 ` Doug Evans [this message]
2000-09-08 11:19 ` Dave Brolley
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=14774.47827.940964.97339@casey.transmeta.com \
--to=dje@transmeta.com \
--cc=brolley@redhat.com \
--cc=cgen@sources.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 read-only IMAP folder(s) and NNTP newsgroup(s).