[mappu]

Cool!

My comments as an inexperienced assembly developer, assuming this is optimising for binary size:

- The pug/doN macros do an extra reg-reg copy if passed a register - and the recursive definition calls pop/pop/pop instead of just add %esp, -4*N, you could shave a few bytes

- AT&T syntax will always look weird to me, but the heavy use of macros and local labels is quite elegant

- A little bit of candid swearing in the comments? Fine by me, but is this officially associated with canonical?

[aroman]

> - A little bit of candid swearing in the comments? Fine by me, but is this officially associated with canonical?

Assuming you mean Canonical Ltd., the company behind Ubuntu, this has absolutely nothing with them — this is hosted on canonical.org, not canonical.com.

[pbsd]

Agree, AT&T syntax was just not designed for human reading. I doubt this is too optimized for size, since there are obvious tricks that it misses.

Another observation: the strlen code is incorrect, as it also counts the \0. We can fix this, and make the code 1 byte shorter (in glorious Intel syntax):

    lea esi, source        ; depends on source
    xor ecx, ecx           ; 2 bytes
    salc                   ; 1 byte
    cld                    ; 1 byte
    _back:
    scasb                  ; 1 byte 
    loopnz _back           ; 2 bytes
    not ecx                ; 2 bytes

[kragen]

Thank you! About the time you wrote this, I discovered that the strlen code was incorrect in a different way as well, and then I went to sleep. Sort of embarrassing.

[kragen]

BTW, I've fixed the strlen code (although differently). I didn't know about SALC! That's a very clever way of zeroing AL.

I think at this point I might be able to get away with CLD since I never STD any more :)

Some of the obvious tricks it misses are probably because they're not obvious to me, while others may be just because I haven't gotten to them yet.

[pbsd]

Your way is much cleaner; mine was just a size gimmick. I just can't resist it :)

[derleth]

> you could shave a few bytes

This is practically axiomatic in assembly language programming.

It's just not worth it to turn you code into what you'd need to turn it into in order to make it as small (or as fast) as it can possibly be on that specific version of that specific microarchitecture from that specific manufacturer, such work being undone by the next version of the hardware.

> AT&T syntax will always look weird to me

AT&T syntax is meant to be a generic assembly language syntax; it's supposed to look equally weird to everyone, regardless of what CPU they're writing code for. GAS will accept Intel syntax, or a somewhat heterodox variant thereof. NASM is the usual assembler of choice on modern x86 Unix-a-likes, I think.

http://www.nasm.us/

> A little bit of candid swearing in the comments?

Hey, if the Linux kernel devs can do it, why not them?