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

[Anton Ertl]

On Sat, Mar 22, 2014 at 03:25:42PM +0100, David Kuehling wrote:
> >>>>> "Bernd" == Bernd Paysan <address@hidden> writes:
> 
> > Am Samstag, 22. März 2014, 07:24:55 schrieb David Kuehling:
> >> I'm using a recent gforth revision from git (6ec9915f6277de) and
> >> noticed that running gforth --dynamic produces pretty extreme
> >> performance degradation [..]
> 
> > How does this affect other microbenchmarks, e.g. onebench.fs? And:
> > SEE-CODE <word> shows the dynamically generated code; could you
> > provide that for the microbenchmark above?
> 
> Ahh, SEE-CODE does a nice job.  The disassembly for the full
> code-sequences of my recursive micro-benchmark for gforth-fast with and
> w/o --dynamic is listed below.  Looks like there is a problem with the
> CALL code sequence generated for calls into colon-definitions:
> 
>   gforth-fast --dynamic
>   : test1 ;
>   : test2 test1 ;
>   see-code test2
> 
>   $2BB725B0 call
>   $2BB725B4 <test1> 
>   ( $2BFC9FA8 ) 3 16 0 addu,
>   ( $2BFC9FAC ) 16 0 16 lw,
>   ( $2BFC9FB0 ) 2 18 0 addu,
>   ( $2BFC9FB4 ) 3 3 4 addiu,
>   ( $2BFC9FB8 ) 18 18 -4 addiu,
>   ( $2BFC9FBC ) 16 16 4 addiu,
>   ( $2BFC9FC0 ) 3 -4 2 sw,
>   ( $2BFC9FC4 ) 2 -4 16 lw,
>   ( $2BFC9FC8 ) $7C03E83B , ( illegal inst ) 
>   ( $2BFC9FCC ) 4 -32680 28 lw,
>   ( $2BFC9FD0 ) 30 3 0 addu,
>   ( $2BFC9FD4 ) 4 4 30 addu,
>   ( $2BFC9FD8 ) 3 2 0 addu,
>   ( $2BFC9FDC ) 4 256 29 sw,
>   ( $2BFC9FE0 ) 3 jr,
>   ( $2BFC9FE4 ) 1 1 0 or,
>   $2BB725B8 ;s ok
> 
> Compare this against the disassembly of CALL:
> see call:
> 
>   Code call  
>   ( $403C34 ) 3 16 0 addu,
>   ( $403C38 ) 16 0 16 lw,
>   ( $403C3C ) 2 18 0 addu,
>   ( $403C40 ) 3 3 4 addiu,
>   ( $403C44 ) 18 18 -4 addiu,
>   ( $403C48 ) 16 16 4 addiu,
>   ( $403C4C ) 3 -4 2 sw,
>   ( $403C50 ) 2 -4 16 lw,
>   ( $403C54 ) 3 2 0 addu,
>   ( $403C58 ) 3 jr,
>   ( $403C5C ) 1 1 0 or,
>   end-code
> 
> Instead of NEXT the code in test2 holds some nonsense, starting with
> invalid instruction $7C03E83B .

Looks to me like the dispatch code that is appended to the code for
the call does some additional stuff (in this particular case we could
actually take the whole CALL instead of cutting the dispatch part off
and appending some other dispatch code, but some gcc versions replace
the NEXT at the end of the word with a direct jump to dispatch code,
and then that does not work).  You can look at where the parts are
with

gforth-fast --debug

The output contains something like:

Compiled with gcc-4.3.2
goto * 0x804b539 0x804fec9 len=12
...
call            0-0   11 0x804b6f0 0x80501f0 0x804b6f0 len= 26 rest= 3 send=1

This means that the fragment appended every time there is something
other than a fall-through is 12 bytes long, whereas the normal code is
3 bytes long (IIRC what the numbers mean).  You can find the appended
fragment at 0x804b539 (or 0x804fec9), and the code for CALL at
0x804b6f0, 0x80501f0, or 0x804b6f0.

And for the machine where I did this, the code generated by the
dynamic call is also longer than the CALL code itself.

Maybe we need another round of playing around with gcc to find out how
to make it produce a short copyable "goto *".  Or we might change the
copying code to copy the whole thing if the NEXT part is relocatable.

> Don't know why that instruction doesn't
> SIGILL, but maybe it's a non-standard/undocumented instruction on
> Loongson2f.  The binutils also don't know anything about that opcode:
> 
>   echo -e "\x3b\xe8\x03\x7c" > /tmp/inst  
>   objdump -D -EL -b binary -m mips:loongson_2f /tmp/inst 
>   [..]
>    0:   7c03e83b        0x7c03e83b

Since this code was originally generated with gas, the binutils do
know about this.  To use gdb (i.e., binutils) for the disassembly, use

' disasm-gdb is discode

before doing the SEE-CODE or SEE.

- anton