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