proc littleEndian(b: openarray[byte]): uint32 =
      {.push boundChecks: off.}
      return uint32(b[0]) or (uint32(b[1]) shl 8) or (uint32(b[2]) shl 16) or (uint32(b[3]) shl 24)
      {.pop.}

    000000000000bf80 <littleEndian_u0__session95202695079520951784538200>:
        bf80:       8b 07                   mov    (%rdi),%eax
        bf82:       c3                      ret

Articles about GoLang assembly language[1] are particularly vexing because the instruction parameters are bass-ackwards - source, destination - like AT&T syntax, but register references are missing their % sigil and so appear to be MASM-style[2].

Authors blogging from deep inside some technical tent should take pity on readers who are not so deeply in the tent and offer a brief primer on assumed knowledge.

Any mistakes in the above should be viewed as confirmation of my confusion.

[0] https://en.wikipedia.org/wiki/X86_calling_conventions

[1] https://go.dev/doc/asm#x86

[2]https://en.wikipedia.org/wiki/X86_assembly_language

Because what the IT infrastructure needs is more CVEs.

The article is correct, but this code is only valid for platforms that allow unaligned access.

You can get the full list of platforms that Go considers safe for this from unalignedOK here: https://go.dev/src/cmd/compile/internal/ssa/config.go

You want the intersection of unalignedOK with little endian.

For more general Go practitioners like me, is there any harness/tooling I can bring into my projects to identify these bottlenecks (aside from profiling if any). More specifically, tooling that identifies workflows that actually have greater changes to be fine with 'unsafe'.