From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Brolley To: Doug Evans Cc: cgen@sources.redhat.com Subject: Re: CGEN: RFA: Fast vs Full with scache-pbb Date: Wed, 06 Sep 2000 14:17:00 -0000 Message-id: <39B6B44B.A541F8A5@redhat.com> References: <39AFFB1F.99F2A190@redhat.com> <39B51C99.3A2FC29C@redhat.com> <14774.43800.665729.386324@casey.transmeta.com> X-SW-Source: 2000-q3/msg00077.html Doug Evans wrote: > > Dave Brolley writes: > > > It turns out that the call to _pbb_begin in the generated > > > _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 _pbb_begin to honour the definition of FAST_P like the rest of sem.c does. Dave