4 ms·
Some CPUs don't have a MUL or (like some 32-bit RISC architectures) DIV instruction, and on these, the C compile has to fall back to a function call.
by spc476 3y ago
Some CPUs don't have a MUL or (like some 32-bit RISC architectures) DIV instruction, and on these, the C compile has to fall back to a function call.
- throwawaymaths 3y agoYou sure the compiler doesn't inline it? That an operator might take more than one opcode I think is uncontroversial
- kps 3y agoMultiplication takes more than a handful of instructions if the hardware doesn't do it. https://godbolt.org/z/ccYPaz1Pj https://godbolt.org/z/ccYPaz1Pj For this example (AVR), this is the int multiply function __mulhi3: 00: 00 24 eor r0, r0 02: 55 27 eor r21, r21 04: 00 c0 rjmp .+0 06: 08 0e add r0, r24 08: 59 1f adc r21, r25 0a: 88 0f add r24, r24 0c: 99 1f adc r25, r25 0e: 00 97 sbiw r24, 0x00 10: 01 f0 breq .+0 12: 76 95 lsr r23 14: 67 95 ror r22 16: 00 f0 brcs .+0 18: 71 05 cpc r23, r1 1a: 01 f4 brne .+0 1c: 80 2d mov r24, r0 1e: 95 2f mov r25, r21 20: 08 95 ret
- throwawaymaths 3y agoI mean, pedantically speaking the normal zig operators do control flow in their operators, in checked mode they panic on overflow, etc (you're not supposed to recover from them but I suppose it's possible). There's probably (internal) control flow in the saturating operators, etc.
- pornel 3y agoNot always. I’ve seen division and atomic operations stay as function calls to libgcc. However, semantics of these are well-defined either way, unlike user-defined operators, so existence of a hidden call is at most an inconvenience when linking code from different compilers.
- deleted 3y ago[deleted]