On Mar 4, 10:53 pm, ja...@njkfrudils.plus.com wrote:
> On Wednesday 04 March 2009 20:52:20 Bill Hart wrote:
>
>
>
> > Hi Brian,
>
> > I will finish off the K8 code as is, and have already done the K10
> > code. But if you could email the output of applying the new version to
> > the Core 2 code, that would probably save me lots of time.
>
> > Bill.
>
> > 2009/3/4 Cactus <rieman...@googlemail.com>:
> > > On Mar 4, 8:25 pm, Bill Hart <goodwillh...@googlemail.com> wrote:
> > >> Hmm, so far no alignment issues appear to have slowed things down. I
> > >> didn't know about the alignb thing.
>
> > >> What may be useful is a version of the converter in the x86_64
> > >> directory which converts any .asm files to .as files in yasm format.
>
> > >> The issues with the $ were in sqr_basecase in the amd64 dir. It ends up
> > >> with:
>
> > >> jge mulskiploop%1
> > >> mulloop %1
> > >> mulskiploop%1:
>
> > >> at about line 277, which yasm doesn't like.
>
> > >> If that first %1 is a macro parameter, I don't know what it is
> > >> supposed to be. It doesn't occur inside a macro. The code works,
> > >> assuming it is just part of the label, anyhow.
>
> It used to occur inside another macro , same for extra quotes around $ ,
>
>
>
> > >> Also in sqr_basecase you have examples of macros in lower case and the
> > >> calls to the macros in upper case.
>
> > >> As for mulq [rcx] that is always unambiguous. The q signifies a qword.
>
> > >> Bill.
>
> > >> 2009/3/4 Cactus <rieman...@googlemail.com>:
>
> > > - Show quoted text -
>
> > >> > On Mar 4, 7:12 pm, Bill Hart <goodwillh...@googlemail.com> wrote:
> > >> >> This thread will be for notes on converting Jason's code to yasm
> > >> >> format. It might help Jason to avoid a couple of minor things which
> > >> >> cause crunching in the gears and may help Brian improve the python
> > >> >> script.
>
> > >> >> * Yasm doesn't like loop labels to be called loop: Anything else is
> > >> >> fine, e.g. loop1:
>
> > >> > I have got used to making that change!
>
> > >> >> * There is no prologue necessary for linux. The code can just end
> > >> >> with ret
>
> I was never sure about prologue/epilogue and just copied the existing files ,
>
> > >> >> * include(`../config.m4') becomes %include '../yasm_mac.inc'
>
> > >> > I can add this with an option for Linux/Windows (different include
> > >> > files)
>
> > >> >> * ASM_START is not required
>
> Again I was never sure what this was ment to do
>
> > >> > Agreed I left it there as I don't want to remove anything in case it
> > >> > matters
>
> > >> >> * win64_gcc_start mpn_blah can become GLOBAL_FUNC mpn_blah
>
> > >> > Again I can translate that differently for Linux and Windows
>
> > >> >> * It didn't know what to do with mulq [rcx], it needs mul qword [rcx]
>
> I can live with most masm'ism's , they are just alternatives for something
> similar in gas , but the dword ptr stuff is just *$"%£&)
It's not really about masm, which has to use these all over the place.
It is only needed in yasm when the instruction doesn't determine the
length of an operand
mul rax,[mem]
is ok because it is known that [mem] is a 64-bit reference. But in
mul [mem]
it isn't possible to know whether ax, eax or rax is intended so its is
necessary to put
mul qword [mem]
for 64-bit operands. I personally much prefer this to the .length on
the end of instruction mneumonics since it is only needed on a few
instructions.
> I suppose now that I not using GMP but MPIR , I should switch over to yasm . I
> will admit I don't trust it, it's too new , there is enough wierd shit going
> on with assembler code as it is. My other gripe is that it works on windows ,
> being an open source person , I don't like it :)
It's hardly new - I have been using it for over five years :-) And
on Windows too :-)
Its pretty reliable and Peter Johnson is very good at correcting any
issues that come up. He is also pretty fast at adding new
instructions when they are announced.
But I do agree that it really needs a better macro processor - but it
can't be worse than M4 :-)
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
-~----------~----~----~----~------~----~------~--~---
