Побитовый сдвиг

0

2

Кто-ть может объяснить почему получаются разные результаты ?

  unsigned int ui = 0x80000000;
  uint32_t mask = ui << 1;
  printf("DEBUG %x\n", mask);

  unsigned int ui2 = 0xFFFFFFFF;
  uint32_t mask2 = ui2 << 32;
  printf("DEBUG %x\n", mask2);

Ссылка

←	makefile to cmake convertor?

Linux pci kernel driver

→

Потому что сдвиг более чем на размер операнда - UB.

slovazap ★★★★★
(27.07.13 15:29:36 MSK)

А почитать, что пишет компилятор никак? А gcc ведь всё объясняет

~~HNO-Arzt_~~
(27.07.13 15:31:08 MSK)

Ссылка

Потому что интеловские мануалы читать нужно. Ну или хотя бы K&R. Ну или хотя бы выхлоп компилятора.

d ★★★★★
(27.07.13 15:37:16 MSK)

Ответ на: комментарий от slovazap 27.07.13 15:29:36 MSK

Да, и разумеется на это выдаётся варнинг.

slovazap ★★★★★
(27.07.13 15:41:04 MSK)

Ссылка

Ответ на: комментарий от d 27.07.13 15:37:16 MSK

Потому что интеловские мануалы читать нужно

Как раз их - в самую последнюю очередь, потому что C++ кросс-платформенный язык и Intel ему совершенно не упал. Из них можно понять почему UB в данном случае ведёт себя именно так, но всё равно оно остаётся UB и прежде всего надо понять именно это.

slovazap ★★★★★
(27.07.13 15:43:55 MSK)

Ответ на: комментарий от slovazap 27.07.13 15:43:55 MSK

Соглашусь, мануалы следует читать если хочется знать, откуда это взялось и почему решили сделать именно так.

ТС, читай K&R: A.7.8 — Shift Operators

d ★★★★★
(27.07.13 16:03:49 MSK)

Ссылка

K&R: The result is undefined if the right operand is negative, or greater than or equal to the number of bits in the left expression's type.

dvl36 ★
(27.07.13 21:11:09 MSK)

Ссылка

Ответ на: комментарий от slovazap 27.07.13 15:43:55 MSK

Почему это? Если не изменяет память асмовские команды SHL/SHR при сдвиге больше чем на размер разрядной сетки равноценно сдвигу на N mod 32/64

anonymous
(27.07.13 22:16:17 MSK)

Ответ на: комментарий от anonymous 27.07.13 22:16:17 MSK

Почему это?

асмовские команды

Потому что ТС пишет не на асме, а на C?

d ★★★★★
(27.07.13 22:55:38 MSK)

Ссылка

Ответ на: комментарий от anonymous 27.07.13 22:16:17 MSK

Ещё один равноценный идиот.

anonymous
(27.07.13 23:53:05 MSK)

Ссылка

Я что то не понял: месяц побитовых сдвигов на ЛОРе, или это новый мейнстрим?
//предполагаю из за разницы величины сдвига и размера uint32_t

comp00 ★★★★
(27.07.13 23:57:05 MSK)

Ответ на: комментарий от comp00 27.07.13 23:57:05 MSK

Это линукс, детка! Ядерные хэккеры. Атомные, я бы даже сказал.

anonymous
(28.07.13 00:05:44 MSK)

Ответ на: комментарий от anonymous 27.07.13 22:16:17 MSK

Почему это? Если не изменяет память асмовские команды SHL/SHR при сдвиге больше чем на размер разрядной сетки равноценно сдвигу на N mod 32/64

Пара подсказок для тех кто в танке:

SHL/SHR есть только на одном единственном семействе процессоров.
Компилятор совершенно не обязан компилировать сдвиги именно в SH[LR]

Постарайтесь запомнить: UB - это только UB.

slovazap ★★★★★
(28.07.13 02:39:17 MSK)

uint32_t mask2 = ui2 << 32;
uint32_t << 32;
32 32
32 32
32 32

~~nanoolinux~~ ★★★★
(28.07.13 04:00:53 MSK)

Ответ на: комментарий от slovazap 28.07.13 02:39:17 MSK

SHL/SHR есть только на одном единственном семействе процессоров.

на других вроде тоже есть аналоги. Не?

Компилятор совершенно не обязан компилировать сдвиги именно в SH[LR]

с этим согласен. В данном случае компилятор это вообще во время компиляции считает, и в коде там тупо ответ.

00000000004004b0 <main>:
  4004b0:	48 83 ec 08          	sub    rsp,0x8
  4004b4:	31 f6                	xor    esi,esi
  4004b6:	bf 1c 07 40 00       	mov    edi,0x40071c
  4004bb:	31 c0                	xor    eax,eax
  4004bd:	e8 ce ff ff ff       	call   400490 <printf@plt>
  4004c2:	31 f6                	xor    esi,esi
  4004c4:	bf 1c 07 40 00       	mov    edi,0x40071c
  4004c9:	31 c0                	xor    eax,eax
  4004cb:	e8 c0 ff ff ff       	call   400490 <printf@plt>
  4004d0:	31 c0                	xor    eax,eax
  4004d2:	48 83 c4 08          	add    rsp,0x8
  4004d6:	c3                   	ret

Постарайтесь запомнить: UB - это только UB.

~~drBatty~~ ★★
(28.07.13 07:39:14 MSK)

Ответ на: комментарий от nanoolinux 28.07.13 04:00:53 MSK

32 32

давай лучше x-- - --x хвастаться? У меня 0.

~~drBatty~~ ★★
(28.07.13 07:41:24 MSK)

Ответ на: комментарий от anonymous 28.07.13 00:05:44 MSK

кварко-глюоные

~~qulinxao~~ ★★☆
(28.07.13 08:07:01 MSK)

Ссылка

match.h если библиотеку добавить результаты изменятся ?

anonymous
(28.07.13 08:39:34 MSK)

Ответ на: комментарий от anonymous 28.07.13 08:39:34 MSK

если библиотеку добавить результаты изменятся?

до последнего веришь в чудо?

false ★★★★★
(28.07.13 09:42:23 MSK)

Ссылка

Ответ на: комментарий от drBatty 28.07.13 07:41:24 MSK

Да ну. Лучше делать троллейбусы из буханок ;)

~~nanoolinux~~ ★★★★
(28.07.13 12:57:48 MSK)

Ссылка

Ответ на: комментарий от drBatty 28.07.13 07:39:14 MSK

В данном случае компилятор это вообще во время компиляции считает, и в коде там тупо ответ.

Да, в последнее время какая-то распространенная практика. Нужно подсовывать данные ввода чтоб оптимизатор не на*бал.

dvl36 ★
(28.07.13 13:08:36 MSK)

Ответ на: комментарий от dvl36 28.07.13 13:08:36 MSK

Да, в последнее время какая-то распространенная практика.

ага. В последние 10 лет.

~~drBatty~~ ★★
(28.07.13 14:35:24 MSK)

Ссылка

Ответ на: комментарий от drBatty 28.07.13 07:39:14 MSK

на других вроде тоже есть аналоги. Не?

Возможно есть, возможно нет. Если есть, с какой стати им работать также как на x86? Могут обнулять при сдвиге >= размера операнда, могут брать младшие биты сдвига, могут поднимать исключение, что угодно.

slovazap ★★★★★
(28.07.13 15:26:49 MSK)

Ответ на: комментарий от slovazap 28.07.13 15:26:49 MSK

с какой стати им работать также как на x86?

с какой стати иначе? Никто специально не будет делать «другую» систему команд.

Хотя в данном случае это не играет никакой роли:

$ gcc -Wall tt.c; ./a.out 
tt.c: В функции «main»:
tt.c:11:2: предупреждение: величина сдвига влево больше или равна ширине данного типа [по умолчанию включена]
DEBUG 0
DEBUG ffffffff
$ gcc -O2 -Wall tt.c; ./a.out 
tt.c: В функции «main»:
tt.c:11:2: предупреждение: величина сдвига влево больше или равна ширине данного типа [по умолчанию включена]
DEBUG 0
DEBUG 0

явный быдлокод, т.к. он даёт разные результаты в одних и тех же условиях(разница только в оптимизации, если кто не понял)

~~drBatty~~ ★★
(28.07.13 18:05:09 MSK)

Ответ на: комментарий от drBatty 28.07.13 18:05:09 MSK

с какой стати иначе? Никто специально не будет делать «другую» систему команд

Всё равно наоборот, никто специально не будет повторять особенности поведения x86 в граничных случаях.

Вот пруф:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489c/CIHDDCIF...

на ARM регистр обнулится.

slovazap ★★★★★
(28.07.13 20:57:07 MSK)

Ответ на: комментарий от slovazap 28.07.13 20:57:07 MSK

недопроцессоры никого не интересуют

anonymous
(28.07.13 21:10:01 MSK)

Ссылка

Ответ на: комментарий от slovazap 28.07.13 20:57:07 MSK

ладно, убедил. Лично я никогда в эту НЁХ и не вдавался.

~~drBatty~~ ★★
(28.07.13 21:12:36 MSK)

Ссылка

Ответ на: комментарий от slovazap 28.07.13 20:57:07 MSK

Причём тут АРМ и причём тут регистр, чепушила? Думаешь если сдвинуть не циклически регистр на любом-арме-не-арме на число бит, большее чем регистр может содержать, то может получиться что-то отличное от нуля, дебилушка?

СИ не знают, а всё туда же - в ЛИСП, в АРМы! Шибко умными себя считають.

anonymous
(28.07.13 21:27:56 MSK)

Ссылка

Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.

←	makefile to cmake convertor?

Development

Linux pci kernel driver

→

Похожие темы