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. >> >> 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 >> >> >> * 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 >> >> > 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] >> >> > There are a few instructions like this but I felt it was safer to >> > leave them to fail so that they got looked at. >> >> >> * It choked on >> >> >> jge mulskiploop$1 >> >> MULLOOP($1) >> >> mulskiploop$1: >> >> >> Perhaps don't use $ as part of a label name. It thinks it is a macro >> >> parameter, which it doesn't seem to be. >> >> > I thought that it was a macro parameter - one that Jason uses to get a >> > unique internal jump label in a multi-use macro. >> >> >> I don't know why it converted MULLOOP($1) to MULLOOP$1 instead of >> >> MULLOOP 1 >> >> > Where did it do this Bill? I couldn't get it to do it. >> >> >> Capitals also appear to screw up in the conversion. The macros get >> >> converted to lower case, but the calls stay upper case (or is it vice >> >> versa, I forget). >> >> > I couldn't get it to do this either :-( >> >> >> More to come I am sure. I'm about half way. >> >> > Remember that there are problems with alignment padding in YASM. >> >> > The directive >> >> > align n >> >> > should be replaced with >> >> > alignb n, nop >> >> > Brian >> > - Show quoted text - > > Hi Bill > > I have a new version that does several of the things you want - is it > any use to you? > > The problem with the 'macros' in sqr_basecase is that they are hard to > distinguish from non macro symbols since there is no bracket around > the supposed parameter - how do I know that 'macro1' is 'macro 1' and > not the symbol 'macro1'? > > Translating macro(1) is easy but 'macro1' is a lot harder. I took the > view that it was better not to translate something than to translate > it wrongly :-) > > I do have a crude symbol table so I might be able to distinguish these > as macro calls. > > Brian > - Show quoted text - > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
