Hi Brian, I can't speak for the future, but for now, I would take Jason's .asm files just before the conversion I did yesterday to be authoritative. One can check out previous revisions from svn, and that is probably the best way to get the files for conversion.
We'll see if Jason decides to switch to yasm. I think it would be great if Jason at least switched to using Yasm for the files I have already converted. I really don't want to convert them every time a change is made to those files. But I'll leave it up to him whether he wants to write new files from scratch in gas or yasm format. Obviously my hope is he'll migrate to yasm for everything. But I would hate it if that started to stifle him. He's done such excellent work. At least we have a nice script for converting from gas format to yasm format, in case Jason or other developers prefer to submit files in that format. Bill. 2009/3/5 Cactus <rieman...@googlemail.com>: > > > > On Mar 4, 11:26 pm, Bill Hart <goodwillh...@googlemail.com> wrote: >> Yeah bring on 96 bit multiplies!! >> >> 2009/3/4 <ja...@njkfrudils.plus.com>: > - Show quoted text - >> >> >> >> > On Wednesday 04 March 2009 23:04:13 Bill Hart wrote: >> >> Yasm does seem to preserve what you code pretty well. I don't know of >> >> any weird optimisation it does. >> >> > Yes , so far it's been no worse than gas >> >> >> The other advantage is we ship a fixed version of yasm with MPIR and >> >> at least while we are doing that you can guarantee that you aren't >> >> going to hit some weird gas bugs that only occur on system X. >> >> >> The disadvantage is that not too many architectures are supported as >> >> of yet. Mainly x86 and perhaps PPC on its way. >> >> > yes , it's a bit limited >> >> >> Well, another really good thing about yasm is the developer has been >> >> very responsive and helpful. >> >> > There is quite a few tricks I would like assemblers to able to do , perhaps >> > with some persuasion... >> >> >> Of course the qword stuff I grew up on. I have never coded in AT&T >> >> format. My first assembler (apart from the motorolla 6802 and chip 8 >> >> one - they converted hexadecimal to binary :-) ) was MASM. Then I used >> >> A86, TASM and now YASM. >> >> > I started on Z80 , no assembler , then 6809 no assembler again , then 68008 >> > with an assembler . I knew the 6809 opcodes by heart , although I always >> > got >> > the jump displacements wrong and having a mul instruction was the bee's >> > knee's .Then i didn't touch assembler again for about 20 years , except >> > for a >> > couple of boot-loader type things. I would hate to program on a 8bit cpus >> > now , its bad enough on x86_64 :) >> > - Show quoted text - >> >> Bill. >> >> >> 2009/3/4 <ja...@njkfrudils.plus.com>: >> >> > 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>: > - Show quoted text - >> >> >> > 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 *$"%£&) >> >> > - Show quoted text - >> >> >> >> >> > 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 - >> >> >> > 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 :) >> >> >> > Jason >> >> > - Show quoted text - > > Hi All, > > I now have a problem on the Windows assembler that we need to resolve. > > Nearly all of my windows assembler is derived from JM's *.asm files in > x86_64 so all I have been doing is tracking JM's changes and moving > them onto Windows. There was a close correspondence between the two > sets of files so I generally didn't have to maintain my files as > independent code - I just tracked JM's efforts. > > But now that Bill has changed JM's files over to YASM, I no longer > have the *.asm reference files to track and this means that the > Windows assembler is effectively self standing. I can't track changes > since the two file sets no longer correspond. For example, this > morning I needed to re-translate mpn_mul_1 to adjust its Windows > equivalent but the master *.asm file no longer exists in the current > trunk revision. > > I really don't want to get into a position where the Linux and Windows > assembler code are not closely aligned but this will now happen unless > I derive the Windows stuff from the new *.as versions. So I really > need to know whether I can assume from here that the master versions > will be *.as not *.asm. > > Jason. are you going to move to YASM or stick with gas? > > The *.as files will, in the end, be a better basis from which to > derive the Windows versions so it will pay me to now derive the > Windows versions from these new versions. Although this is more work > now, it will save effort later in tracking changes, fixes and in > sorting out performance anomalies since we will know that the files > are closely related. > > So all I really need to know is what will be the master assembler > files in x86_64 from now on? > > If there is going to be further assembler support (for division ?), > will this be *.asm or *.as? > > I think the sensible thing to do is to convert the new *.as stuff for > Windows but this is only true if I don't have to cope with *.asm stuff > as well. > > I don't really mind which way you go as long as I don't end up haveing > to cope with both *.asm and *.as conversions! > > 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 -~----------~----~----~----~------~----~------~--~---
