On Thursday 30 June 2011 20:06:22 Cactus wrote: > On Jun 30, 5:17 pm, Jason <ja...@njkfrudils.plus.com> wrote: > > On Thursday 30 June 2011 16:28:41 Cactus wrote: > > > On Jun 30, 4:14 pm, Jason <ja...@njkfrudils.plus.com> wrote: > > > > On Thursday 30 June 2011 16:07:37 Cactus wrote: > > > > > On Jun 30, 3:00 pm, Jason <ja...@njkfrudils.plus.com> wrote: > > > > > > On Thursday 30 June 2011 07:59:58 Jason wrote: > > > > > > > On Thursday 30 June 2011 01:51:41 Bill Hart wrote: > > > > > > > > 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. > > > > > > > > > > > > > > Without the square brackets we get the error > > > > > > > > > > > > > > tmp-fat_entry.s:61: Error: undefined symbol > > > > > > > `_GLOBAL_OFFSET_TABLE_' in operation > > > > > > > > > > > > > > strange. I'll go ahead with the rip relative form and if we get > > > > > > > a problem we only need to revert fat_entry.asm and change back > > > > > > > from yasm to gas in mpn/Makeasm.am > > > > > > > > > > > > > > Jason > > > > > > > > > > > > Hi , I've changed the x86_64 and x86_64w fat builds to RIP > > > > > > addressing , which is faster,neater and smaller and also set > > > > > > x86_64 to use yasm for all *.asm and *.as in the mpn directory. > > > > > > x86_64w already used yasm only , except for fat_entry.asm where > > > > > > gas is still used , we could fairly easily change this but whats > > > > > > the point. We could also implement the reverse and get gas to > > > > > > build all the *.as *.asm files , that way would remove the need > > > > > > for yasm(execpt for MSVC, which you have to download it separate > > > > > > anyway) > > > > > > > > > > I really don't want any code in x86_64w that does not (a) compile > > > > > with YASM, and (b) does not comply with Widows x64 calling > > > > > conventions. > > > > > > > > > > Brian > > > > > > > > It would involve no code or ABI changes , I would just use the GAS > > > > options to get it to accept the existing code with NO modifications , > > > > it's pretty easy to do , take a day or two , but I have no intention > > > > of doing it anytime soon :) > > > > > > And I forgot (c) no m4 either since this tool is completely alien to > > > Windows :-) > > > > Yep , no M4 , but I meant only for unix like shells , I'm not going to > > mess with the GUI,MSBUILD,CL builds, but to be perverse we could install > > M4 like we do for YASM .... :) or even worse autotools does support > > CL.EXE so ..... aaaarrrggghhhh > > > > > Maybe we should create two 'x86_64w directories' since the growth of > > > what is in the current x86_64w directory makes it ever less obvious > > > what I am managing and what I am not? > > > > No , the only directory not used by the MSVC builds is "fat" , there is > > no new asm code except fat_entry.asm and there wont be anything else. I > > know you don't have a separate GUI MSVC build for bobcat , but there is > > no new code there. I wont be writing any windows asm code as you can do > > it so much faster > > > > :) . If at some stage you get a bobcat say(they are great media players, > > > > fanless and silent) and wanted to do a GUI build for it , then the best > > asm functions are already there, otherwise just ignore the directory. > > MinGW64 can do a bobcat build and so can the CL MSVC build. > > Say I do write some specific linux bobcat code , then it's totally up to > > you whether you do a windows version. I will at some some be doing a > > fake ABI , so I can write and speed test windows code on a linux box > > without needing any windows OS'es on that particular cpu. > > I am not worried about the mingw64 build since I don't explicitly > support this. > > But most people will expect the MSVC command line build to be fully > compliant with x64 calling conventions and I don't think this will be > true for a FAT build unlesss the proper prolgues and epilogues have > been implemented in the initialisation and vectoring code. >
Yep , the current MinGW64 can be built and run as a FAT build , but I guess it's not completely compliant , have to think about it , see if it's worth fixing > To me it doesn't make sense to have even one *.asm file in the x86_64 > directory that requires m4 and GAS (both *nix tools). This directory > is explicitly for code that is intended for Windows and it should > hence be possible to build all the code it contains with native > Windows tools (+YASM). > > But since I place a high priority on maintaining the Windows status of > files in this directory, I will do the conversion if you can provide > the m4 output for the asm file in question. I can probably convert > without this but there seem to be some pretty nasty m4-isms that need > converting. > > If we cannot do this, I am inclined to split off the x86_64w Windows > code into a seperate directory and convert it to use MASM so that we > have a true fully native build (i.e. no YASM). This would allow the > Windows build with MSVC tools alone (several people have asked for > this). > > Brian -- 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.
