>>>>> "Anton" == Anton Ertl <[email protected]> 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
pgp5Bw2Rnyddy.pgp
Description: PGP signature
