This is the mail archive of the
cgen@sources.redhat.com
mailing list for the CGEN project.
Re: CGEN: RFA: Fast vs Full with scache-pbb
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', 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.
2) Only one of 'sem_fast' or 'sem_full' is initialized in the
idesc_table based on the FAST_P macro(sem.c)
3) sc->argbug.semantic contains sem_fast and sem_full members,
but is a union so you really only get one or the other.
My patch simply forces the call to <cpu>_pbb_begin to honour the
definition of FAST_P like the rest of sem.c does.
Dave