NOTE: Since many/most of the answers seem to ignore the requirement in the question that the input must be taken from
stdin and the output must be sent to
stdout, I suppose it is reasonable if I do so, too. I think that's a silly and arbitrary requirement, because it makes many languages non-competitive. The standard on Code Golf is to allow functions, and to allow functions taking input via arguments and outputting via their return value(s), so this is what I will follow.
x86-64 Assembly, standard Linux calling convention, 17 bytes
64 31 C0 0F B6 0F E3 09 48 FF C7 8D 44 01 D0 EB F2 C3
Try it online!
This is a minor, iterative improvement on qwr's answer, which is 18 bytes.
It saves 1 byte by using the relatively-obscure
JECXZ instruction (actually
JRCXZ, since this is 64-bit mode), which jumps if the value of the
rcx register is zero.
It also improves on qwr's original (arguably fixes a bug?) in that it supports the case where the input is an empty string, returning a sum of zero. (To be fair, the challenge doesn't specify whether it is required to handle this, so maybe it cannot be termed a "bug", and, in fact, my next attempt will have this same "bug", so I can hardly ding qwr for taking advantage of it, too!)
31 C0 xor eax, eax
0F B6 0F movzx ecx, BYTE PTR [rdi]
E3 09 jrcxz End
48 FF C7 inc rdi
8D 44 01 D0 lea eax, [rcx + rax - '0']
EB F2 jmp Loop
C3 ret ; result is in eax
x86-64 Assembly, fully custom calling convention, 14 bytes
64 31 C0 31 D2 AC 8D 54 02 D0 38 26 75 F7 C3
Try it online!
This is a variation on the same theme (it still takes the input as a pointer to the beginning of a NUL-terminated ASCII string), but it pulls out all the stops to really optimize for size:
It uses the ultra-compact x86 string instructions. In this case,
lods, which loads a byte into
al from the address in
rsi, and also increments
rsi to point to the next byte, using a single-byte encoding.
- In order to know whether to increment or decrement the source pointer, the
rsi instruction implicitly depends on the direction flag (
DF). Normally, you'd need to explicitly clear that flag with the
cld instruction, but, in this case, since we're running on a *nix-like operating system, per the challenge, we can assume it is already clear. (Also, when you're defining a custom calling convention, the state of the flags can be part of that; see below.)
It uses a custom calling convention so that we can (A) take the input string in the
rsi register, which is what the
lods instruction expects, saving us from having to copy it from one register to another, and (B) build the result in a custom register (
edx), freeing up
eax to use as a scratch register (because this is what the
lods instruction uses as an implicit destination operand).
lods instruction is only loading a single byte, so it only modified the low-order byte of the
eax register (
al). But the
lea instruction that we use to perform multiple arithmetic operations in a single instruction only works on the full 64-bit register, so we need to make sure that the high values are clear. We could do this with an explicit
movzx after the
lods instruction, but that would consume a lot of bytes. So, instead, we do it once, outside of the loop, with a single
xor instruction. This clears the entire
rax register, which works because we only ever touch the low-order byte (
- Another neat trick falls out of this: because we don't touch the high-order byte (
ah), it's guaranteed to be zero through all iterations of our loop, so we can compare (
cmp) the source pointer (string) to
ah instead of comparing it to a literal 0, which saves us one byte in the encoding.
-- ; cld ; can assume DF is always clear on Linux)
31 C0 xor eax, eax ; eax = 0 (al = 0, ah = 0)
31 D2 xor edx, edx ; edx = 0 (holds result)
AC lods ; al = BYTE PTR [rsi]
8D 54 02 D0 lea edx, [rdx + rax - '0'] ; edx += (eax - '0')
38 26 cmp BYTE PTR [rsi], ah ; is BYTE PTR [rsi] == ah (which is 0)?
75 F7 jne Loop ; loop back if not equal (non-zero)
C3 ret ; result is in edx
The custom calling convention is a pretty major "cheat" here, but it's not unusual in the "real world" to use a custom calling convention when writing code in assembly. If you're going to call it from C, you need to take steps to match the standard C calling convention, but who says we're calling it from C?! We don't need no stinkin' C! :-)