On 30 June 2011 01:39, Jason <ja...@njkfrudils.plus.com> wrote: > On Thursday 30 June 2011 00:42:07 jason wrote: >> > 12) Yasm to assemble all asm files , just need to get it to work in a FAT >> > build >> >> This only happens in a shared build and appears to be caused by square >> brackets in the fat_entrys.asm file. I not sure what the sure brackets >> are for? Anyway the whole thing should be rewritten with RIP relative >> addressing because the current code breaks the call/ret symmetry > > No it doesn't , DUH > >> , and >> this will knock a few cycles off. >> >> Jason > > using rip relative addressing fixes the problem , but I'm still not 100% > convinced as the old code was > > call L(movl_eip_edx) > L(entry_here$2): > addq $_GLOBAL_OFFSET_TABLE_+[.-L(entry_here$2)], %r11 > movq GSYM_PREFIX`'__gmpn_cpuvec@GOT(%r11), %r11 > jmp *m4_empty_if_zero($2)(%r11) > > the bit of code > > .-L(entry_here$2) > > should always evaluate to 0 ??? > and what do the square brackets do ? they get passed to the assembler(or > rather gcc) > > assuming they always evalulate to zero we can use > > lea _GLOBAL_OFFSET_TABLE(%rip),%r11 > movq GSYM_PREFIX`'__gmpn_cpuvec@GOT(%r11), %r11 > jmp *m4_empty_if_zero($2)(%r11) > > instead which passes make check >
Who the hell knows. You probably understand this better than any of us here. What you say certainly sounds feasible. Bill. -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
