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