Re: [gforth] Performance anomality with dynamic superinstructions on MIPSel

[Bernd Paysan]

Am Montag, 24. März 2014, 11:02:46 schrieb Anton Ertl:
> On Mon, Mar 24, 2014 at 03:17:41AM +0100, Bernd Paysan wrote:
> > What did the trick?  Using FIRST_NEXT actually in after_last:, this is a
> > dummy for getting the tail of the last address, we can put anything we
> > like there. Doing FIRST_NEXT there makes it a noop, and since there's
> > nothing to move into the goto, it stays as small as it should.
> 
> But does that work with the versions of GCC that combine all the
> indirect gotos into one?

Yes, because that workaround will jump to before_goto in all other NEXTs:

#if GCC_PR15242_WORKAROUND
#define DO_GOTO goto before_goto
#else
#define DO_GOTO goto *real_ca
#endif

If PR15242_WORKAROUND is defined (for those historical GCCs which do have this 
problem), the only goto *real_ca is in FIRST_NEXT.  That one is now actually 
the last next, but it is the only one.

> We actually cut the primitives into the
> pre-goto part and the goto part, and then stick the first goto * there
> to work around that.  And IIRC these versions of gcc jump to the first
> goto *.
> 
> The following solutions suggest themselves to me:
> 
> 1) Check whether the goto part of the primitive itself is relocatable.
> If it is, use it.  If not, use the shortest goto part that is
> relocatable.

Yes; this sounds like the best idea.  Actually, you should first check the 
whole primitive for relocatibiliy, and copy the whole primitive in all cases.  
If the primitive doesn't change the control flow, step back by the size of its 
goto part when you copy the next primitive (so it overwrites that part).

> 2) Just like for checking for registers and long longs, try whether
> the engine works without the workaround mentioned above, and only
> employ the workaround if it doesn't.

The workaround is for historical GCCs; we might also cut support for those.  
Who's stlill using GCC 3.x?  If you want to use a historical GCC, please use 
GCC 2.95.2 (though this one has no -fwrapv switch, and also causes some 
troubles ;-).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

signature.asc
Description: This is a digitally signed message part.