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

[David Kuehling]

>>>>> "Anton" == Anton Ertl <address@hidden> writes:

> 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

Running gforth-fast --debug --dynamic outputs (among others) the
following lines (I mistakenly claimed this is a debian squeeze system,
it's actually running debian wheezy, GCC is v4.6)

  Opened image file: /usr/local/lib/gforth/0.7.9_20140119/gforth.fi
  Magic found: Gforth5^E little endian, cell=4 bytes, char=1 bytes, au=1 bytes
  Compiled with gcc-4.6.3
  goto * 0x403a14 0x408f44 len=32
  call            0-0   12 0x403c34 0x4092f4 0x403c34 len= 28 rest= 4 send=1

Disassembling the code for goto* shows the broken opcode: 

$403a14 32 discode 0x7bdaf0=allocate(000000c6);

   0x00403a14 <gforth_engine+164>:      0x7c03e83b
   0x00403a18 <gforth_engine+168>:      lw      a0,-32680(gp)
   0x00403a1c <gforth_engine+172>:      move    s8,v1
   0x00403a20 <gforth_engine+176>:      addu    a0,a0,s8
   0x00403a24 <gforth_engine+180>:      move    v1,v0
   0x00403a28 <gforth_engine+184>:      sw      a0,256(sp)
   0x00403a2c <gforth_engine+188>:      jr      v1
   0x00403a30 <gforth_engine+192>:      move    at,at
free(0x7bdaf0)=-1;

This could be an inlined literal that's then loaded via -32680(gp)?
Then the GCC code generator would be pretty broken to use the address of
the literal as address of the label.  Anything not an illegal
instruction would make it difficult to explain a factor 7 slowdown.

>> 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.

Doing this doesn't help (already shown in the disassembled code above)

' disasm-gdb is discode  ok
: test1 ;  ok
: test2 test1 ;  ok
see-code test2 
2AFF2540 call
$2AFF2544 <test1> 0x7bdb20=allocate(000000c6);
free(0x7b41b8)=-1;
   0x2b449eb4:  move    v1,s0
   0x2b449eb8:  lw      s0,0(s0)
   0x2b449ebc:  move    v0,s2
   0x2b449ec0:  addiu   v1,v1,4
   0x2b449ec4:  addiu   s2,s2,-4
   0x2b449ec8:  addiu   s0,s0,4
   0x2b449ecc:  sw      v1,-4(v0)
   0x2b449ed0:  lw      v0,-4(s0)
   0x2b449ed4:  0x7c03e83b
   0x2b449ed8:  lw      a0,-32680(gp)
   0x2b449edc:  move    s8,v1
   0x2b449ee0:  addu    a0,a0,s8
   0x2b449ee4:  move    v1,v0
   0x2b449ee8:  sw      a0,256(sp)
   0x2b449eec:  jr      v1
   0x2b449ef0:  move    at,at
free(0x7bdb20)=-1;
$2AFF2548 ;s ok

Will try to dump intermediate assembly files corresponding to engine.c
once I find the time (maybe not before tomorrow).

cheers,

David
-- 
GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk2.gpg
Fingerprint: B63B 6AF2 4EEB F033 46F7  7F1D 935E 6F08 E457 205F

pgpTWGAK6QNKJ.pgp
Description: PGP signature