c - Conversion from size_t to int -
following thread ...
for piece of code:
#include <stdio.h> int main(void) { int i; size_t u; (i = 0; < 10; i++) { u = (size_t)i; printf("i = %d, u = %zu\n", i, u); } return 0; }
the output in assembly is:
edit: compiled -o2
.file "demo.c" .section .rodata.str1.1,"ams",@progbits,1 .lc0: .string "i = %d, u = %zu\n" .section .text.startup,"ax",@progbits .p2align 4,,15 .globl main .type main, @function main: .lfb3: .cfi_startproc pushq %rbx .cfi_def_cfa_offset 16 .cfi_offset 3, -16 xorl %ebx, %ebx .p2align 4,,10 .p2align 3 .l2: movq %rbx, %rdx movl %ebx, %esi xorl %eax, %eax movl $.lc0, %edi addq $1, %rbx call printf cmpq $10, %rbx jne .l2 xorl %eax, %eax popq %rbx .cfi_def_cfa_offset 8 ret .cfi_endproc .lfe3: .size main, .-main .ident "gcc: (debian 4.7.2-5) 4.7.2" .section .note.gnu-stack,"",@progbits
is conversion u = (size_t)i;
consuming cycles?
yes, does, changes internal representation 32bit 64bit. specifically,
.l3: movl -4(%rbp), %eax cltq movq %rax, -16(%rbp) movq -16(%rbp), %rdx
reads i
, performs sign-extension , copying %rdx
. i'm unsure why value has pass through stack - mats pointed out, looks code non-noptimizing compiler run.
edit
in optimized assembly code, loop counter maintained wider data type. afair, mov
s between registers don't differ in run-time cycles wrt quad or dword (indeed don't: see table c-16 in intels pertinent doc, referenced this post.
Comments
Post a Comment