Re: CGEN: RFA: Fast vs Full with scache-pbb

[Dave Brolley <brolley@redhat.com>]

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