Conversation

Notices

1. Embed this notice
   mcc (mcc@mastodon.social)'s status on Wednesday, 22-Jan-2025 10:40:42 JST mcc

   #BabelOfCode 2024
   Week 3
   Language: x86_64 assembly [AMD64] (macroassembler: GNU as/gas)

   PREV WEEK: https://mastodon.social/@mcc/113783248514095140
   RULES: https://mastodon.social/@mcc/113676228091546556

   I planned ASM for today and when I saw the challenge *almost* bounced to TCL, because I *don't* wanna write a parser in ASM. But the language here is exceedingly regular, so probs a state machine is enough.

   Successfully ran this hello world https://cs.lmu.edu/~ray/notes/gasexamples/ which I think should be all I need to start.

   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Wednesday, 22-Jan-2025 10:40:42 JST mcc

     in reply to

     My language "confidence level" for this week is high, but down to medium-high for step 2 (because obvs I don't know WHAT they'll throw at me at step 2). I'm kinda unenthused about the gas macro language. The macro language documentation ( https://sourceware.org/binutils/docs/as/Macro.html + https://sourceware.org/binutils/docs/as/Altmacro.html , I think that's literally all they wrote ) is sketchy and unclear. Can macros take a macro name as argument and invoke the passed-in macro? I literally can't tell. I'm going to uncover syntax by trial and error

   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Wednesday, 22-Jan-2025 10:41:09 JST mcc

     in reply to

     I've decided to add a new rule to my challenge, which is in addition to doing a different language every week I'm going to try to use exclusively *languages I haven't programmed in before*.

     If that's the rule, x86_64 is a stretch as I've *written* x86_64— but I count it as valid, because I've never written a whole AMD64 *program*, only snippets embedded in a C file or OllyDbg-injected into an exe at runtime. Only ASMs I've written whole programs in are MIPS and LLVM in-memory representation.

   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Wednesday, 22-Jan-2025 10:41:09 JST mcc

     in reply to

     Finding many things that are just sort of It's Assumed You Know This but may or may not be written anywhere. Like, there's a "movb" instruction which is not in the instruction reference I'm using and is not recognized by my syntax highlighter, but gas accepts it.

     Question. I do

     mov %al, %esi

     It says operand type mismatch. OK. I think I can simulate this with

     mov $0, %rax
     mov $eax, $esi

     BC non-al bits of rax get cleared in instruction 1.

     …But what's the "widening"/truncating version of mov?

   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Wednesday, 22-Jan-2025 10:41:09 JST mcc

     in reply to

     Ah… well… that did not take long

   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Wednesday, 22-Jan-2025 10:41:09 JST mcc

     in reply to

     I'm sorry the x86_64 multiply instruction works fucking *how*. What fucking century is it

   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Wednesday, 22-Jan-2025 10:41:09 JST mcc

     in reply to

     So it took longer than I'd hoped, but I now have a working first-pass AMD64 ASM program that can decode an ASCII number in the .data segment and print it out again.

     https://github.com/mcclure/aoc2024/blob/ad0a3f670a4ed6d403f81863977175315284d220/03-01-multiply/src/number-echo.s

     Build instructions in adjacent run.txt.

     I have some questions.

     (1 of 2). I think I don't like GNU/AT&T assembly format and would like to switch to Intel assembly format. Is Intel format… documented… somewhere? This is the closest I found. https://sourceware.org/binutils/docs/as/i386_002dVariations.html

   • Embed this notice
     I Can't Believe It's Not Zero! (steve@discuss.systems)'s status on Thursday, 23-Jan-2025 01:15:52 JST I Can't Believe It's Not Zero!

     in reply to

     • William D. Jones
     • disregard Joe Groff
     • Paul Khuong

     @joe @cr1901 @pkhuong (They did it for 8->16, 16->32, and SSE->AVX/AVX512. And each time they managed to find a way to make it worse.)

   • Embed this notice
     I Can't Believe It's Not Zero! (steve@discuss.systems)'s status on Thursday, 23-Jan-2025 01:15:53 JST I Can't Believe It's Not Zero!

     in reply to

     • William D. Jones
     • disregard Joe Groff
     • Paul Khuong

     @joe @cr1901 @pkhuong Intel's dedication to making that particular mistake _over and over again_ will never cease to amaze me.

     Rich Felker repeated this.
   • Embed this notice
     disregard Joe Groff (joe@f.duriansoftware.com)'s status on Thursday, 23-Jan-2025 01:15:54 JST disregard Joe Groff

     in reply to

     • I Can't Believe It's Not Zero!
     • William D. Jones
     • Paul Khuong

     @steve @cr1901 @pkhuong nonetheless it is absolutely the right thing for a contemporary ISA to not have unnecessary partial register updates in the first place, to cr1901’s point about risc-v. luckily AMD at least figured that out by the time they designed x86-64

   • Embed this notice
     I Can't Believe It's Not Zero! (steve@discuss.systems)'s status on Thursday, 23-Jan-2025 01:15:55 JST I Can't Believe It's Not Zero!

     in reply to

     • William D. Jones
     • disregard Joe Groff
     • Paul Khuong

     @cr1901 @joe @pkhuong dependency-breaking xor/movzx are "free" (they have to be decoded, but they don't need to execute).

   • Embed this notice
     William D. Jones (cr1901@mastodon.social)'s status on Thursday, 23-Jan-2025 01:15:56 JST William D. Jones

     in reply to

     • I Can't Believe It's Not Zero!
     • disregard Joe Groff
     • Paul Khuong

     @joe @steve @pkhuong Ya know, if an extra xor/movsx/movsxd is less performance penalty than eating a partial load, I'm beginning to realize why RISC-V zero/sign-extends even byte loads...

   • Embed this notice
     disregard Joe Groff (joe@f.duriansoftware.com)'s status on Thursday, 23-Jan-2025 01:15:57 JST disregard Joe Groff

     in reply to

     • I Can't Believe It's Not Zero!
     • William D. Jones
     • Paul Khuong

     @steve @cr1901 @pkhuong and even with that, compilers will often sever the dependency explicitly by doing an xor or movsx/xx to the destination at the start of an operation chain

     the other thing that makes 16 bit operations slow on some uarches iirc is a penalty for the operand size prefix byte

   • Embed this notice
     William D. Jones (cr1901@mastodon.social)'s status on Thursday, 23-Jan-2025 01:15:58 JST William D. Jones

     in reply to

     • Paul Khuong

     @pkhuong @mcc What makes 8 bit ops faster, even tho both will have partial deps?

   • Embed this notice
     I Can't Believe It's Not Zero! (steve@discuss.systems)'s status on Thursday, 23-Jan-2025 01:15:58 JST I Can't Believe It's Not Zero!

     in reply to

     • William D. Jones
     • Paul Khuong

     @cr1901 @pkhuong @mcc there’s just a special fast-path for them

   • Embed this notice
     Paul Khuong (pkhuong@discuss.systems)'s status on Thursday, 23-Jan-2025 01:15:59 JST Paul Khuong

     in reply to

     • William D. Jones

     @cr1901 @mcc 16 bit ops are extra slow nowadays (no one uses them).

   • Embed this notice
     William D. Jones (cr1901@mastodon.social)'s status on Thursday, 23-Jan-2025 01:16:00 JST William D. Jones

     in reply to

     • Paul Khuong

     @pkhuong @mcc What's special about 16-bit partial deps that doesn't apply to 8-bit ones?

   • Embed this notice
     Paul Khuong (pkhuong@discuss.systems)'s status on Thursday, 23-Jan-2025 01:16:01 JST Paul Khuong

     in reply to

     @mcc movzx/sx for widening. regular mov for narrowing, but be mindful of partial dependencies on 8 and 16 bit destinations (16b in particular).

     The size suffix is an at&t special and not part of the ISA (which also has movd/movq…)