Беззнаковые целые в MinGW-w64

В общем пишу на сишечке программу, компилирую MinGW-w64. Захотелось мне тут посмотреть на свой код через IDA Pro. Для примера взял такой код:

Код (C):

1. for(unsigned int i=0; i<MSize*MSize; i++)

MSize объявлен как unsigned int. Вижу в качестве проверки условия в IDA Pro:

Код (ASM):

1. loc_40167A:
2. mov     eax, [rbp-40h+MSize]
3. imul    eax, [rbp-40h+MSize]
4. cmp     [rbp-40h+i], eax
5. jb      short loc_401644

Т.о. при проверке условия он делает знаковое умножение, это вообще нормально? И как с этим бороться? Я понимаю, что вряд ли квадрат переменной MSize выйдет за пределы максимального знакового целого, но всё-таки такое поведение компилятора раздражает.

 

вполне нормально, если отключена оптимизация, или MSize - глобальная переменная, то есть может быть в любое время изменена из другого потока...

 

А почему если MSize - глобальная переменная, то он такую фигню делает? Собрал программу в Release конфигурации (опции компилятора: "-O2;-Wall"), но всё равно он юзает imul.

 

я же писал: MSize может быть изменена из другого потока, если это глобальная переменная, тогда выражение MSize * MSize нужно вычислять на каждой иттерации цикла, чтобы не терять семантику написанного кода... чтобы этого не было, объяви переменную auto MSize2 = MSize * MSize, и используй ее в качестве предела для иттераций цикла...

есть еще -O3... -Wall не имеет никакого отношения к оптимизации...

 

Rel, кажется вы меня не правильно поняли. Проблема не в том, что произведение вычисляется на каждой итерации, а в том, что вместо беззнакового умножения mul используется знаковое imul.

 

а, сорян... насчет этого не знаю... можно канеш предположить, что imul выполняется быстрее mul... но это странно... думаю, что тебе лучше об этом спросить в мейл-листе GCC или MinGW...

 

Проблемы нет, так как отличие знакового умножения от беззнакового только в устанавливаемых флагах; в edx:eax будет одно и то же.

 

При форме imul такой, как я привёл в #1 в edx ничего записано не будет. А на счёт того, что разницы не будет, это - да, я не подумал (разница будет в верхнем двойном слове, которое никуда записано не будет).

 

Вообще, использовать голый unsigned int нынче некошерно. Лучше что-нить типа size_t. Ну и умножение лучше из for вынести в отдельную переменную. Не всяк компилятор умён настолько.
По поводу imul - всё уже правильно сказали.

 

SadKo, А что собственно плохого в использовании unsigned int?

 

Да, в принципе, не много плохого: писать приходится немного больше символов, чем size_t, и портабельность страдает: на x32 sizeof(unsigned int) = 32, sizeof(size_t) = 32, а вот на x64 sizeof(unsigned int) = 32, а sizeof(size_t) = 64.

 

Чего-то не вижу, чтобы портабельность страдала.

 

В C++ чтение произвольной переменной, которая потенциально меняется в другом потоке, без должной синхронизации (установления отношения happens before) называется data race и приводит к неопределённому поведению.
Короче, не может глобальная переменная (не atomic) в любое время меняться из другого потока.

Не нужно и никто не вычисляет, в чём можно легко убедиться.
Берём код

Код (C):

1.  
2. unsigned MSize = 30;
3. unsigned f()
4. {
5.    unsigned ret = 0;
6.    for (unsigned i = 0; i < MSize*MSize; i++)
7.      ret += i;
8.    return ret;
9. }
10.  

и компилируем gcc:

Код (ASM):

1.  
2. f():
3. mov ecx, DWORD PTR MSize[rip]
4. imul ecx, ecx
5. test ecx, ecx
6. je .L4
7. xor edx, edx
8. xor eax, eax
9. .L3:
10. add eax, edx
11. add edx, 1
12. cmp edx, ecx
13. jne .L3
14. rep ret
15. .L4:
16. xor eax, eax
17. ret
18. MSize:
19. .long 30
20.  

или msvc:

Код (ASM):

1.  
2. MSize DD 01eH
3. f PROC
4. mov r9d, DWORD PTR MSize
5. xor ecx, ecx
6. imul r9d, r9d
7. mov edx, ecx
8. mov r10d, ecx
9. mov eax, ecx
10. cmp r9d, 2
11. jb SHORT $LC10@f
12. lea r8d, DWORD PTR [r9-1]
13. npad 2
14. $LL11@f:
15. inc edx
16. add ecx, eax
17. add edx, eax
18. add eax, 2
19. cmp eax, r8d
20. jb SHORT $LL11@f
21. $LC10@f:
22. cmp eax, r9d
23. cmovb r10d, eax
24. lea eax, DWORD PTR [rdx+rcx]
25. add eax, r10d
26. ret 0
27. f ENDP
28.  

Ну а насчёт imul уже сказали. Но я тоже скажу.

 

Mikl___, смелая замена. Но некорректная.

 

Mikl___, да я даже не про арифметику (кстати, она опять некорректная, должно быть 404550), а что замена здесь на константу неправомерна.