home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.asm.x86      Ahh, the lost art of x86 assembly      4,675 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 3,251 of 4,675   
   Bartc to Alexei A. Frounze   
   Re: What assembler?   
   20 Jan 18 12:33:37   
   
   From: bc@nospicedham.freeuk.com   
      
   On 20/01/2018 05:26, Alexei A. Frounze wrote:   
   > On Friday, January 19, 2018 at 4:14:15 AM UTC-8, Bartc wrote:   
   >> On 19/01/2018 08:08, Alexei A. Frounze wrote:   
   >>> On Thursday, January 18, 2018 at 6:13:31 PM UTC-8, Bartc wrote:   
   >>>> At the minute I'm stuck using ld from gcc (under Windows), as alternates   
   >>>> either have problems, or they don't exist.   
   >>>   
   >>> If you have tried mine (from Smaller C), what's missing?   
   >>   
   >> I think I've played with Smaller C in the past.   
   >>   
   >> But my requirements are that linker inputs be 64-bit object files in   
   >> COFF format, and also .DLL shared libraries.   
   >   
   > Oh, I see. Mine only supports 32-bit ELFs as there's no   
   > 64-bit support in Smaller C (yet?) and it's a format I   
   > found usable for both 32-bit and 16-bit code (NASM can   
   > emit 16-bit ELF relocations (an it's an extension) and   
   > segmentation isn't too much of a problem for a 32-bit   
   > format).   
      
   I've found that LD also accepts ELF64, so I could have chosen that as a   
   target. The docs seem simpler than for COFF64. (But then, if I wanted to   
   eventually produce PE+ files, I would still have to delve into COFF64 as   
   they are based on the same format.)   
      
   > ...   
   >> However, NASM also has some problems, the most notable of which is that   
   >> it gets VERY slow on large inputs.   
   >   
   > I found that NASM is bad with not large inputs but many   
   > jumps. It optimizes them for size and is quite slow there.   
   >   
   >> So I am now using my own assembler   
   >> for x64, and yesterday started switching over to using it over NASM.   
   >   
   > Give a try to YASM. In most cases it just works as a drop-in   
   > replacement for NASM. And it's significantly faster than   
   > NASM.   
      
   I've just tried YASM and it is indeed much faster: a test 120,000-line   
   ASM file took 41 seconds on NASM (26 seconds using -O0), but 0.6 seconds   
   with YASM.   
      
   (My own assembler also takes 0.6 seconds or so, but it's interpreted. I   
   believe a compiled version, which I'm thinking of doing, would do the   
   job in 30 msec.)   
      
   (Unfortunately the EXE resulting from the YASM object file crashes when   
   I try and run it, so I would need to find out why if I'm going to use   
   it. I needed to make some tweaks to remove some assembly errors with YASM.)   
      
   Regarding optimising for short jumps: my assembler at first did no   
   optimising for forward jumps, they always used 32-bit offsets. But I   
   couldn't see much difference in performance of the EXEs: one app might   
   be 1-2% faster with Nasm, another 1-2% slower. But I still have some   
   optimisations to do.   
      
   --   
   Bartc   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca