- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
// http://cmustdie.com/ - баттхерт анскильных лалок, неосиливших сишку
// Возьмём следующий фрагмент кода на языке Си:
int x = 1;
x = x << sizeof(int) * 8;
// Попробуем предположить, какой результат у нас получится. Допустим, мы скомпилировали этот
// код для процессоров архитектуры ARM. Инструкция битового сдвига в рамках этой аппаратной
// платформы определена так, что итоговым значением переменной "x" должен быть "0". С другой
// стороны, мы можем транслировать нашу программу в машинный код архитектуры x86. И уже там
// битовый сдвиг реализован таким образом, что значение "x" не изменится и останется равным
// "1". Мы могли бы сделать вывод, что результат работы данного фрагмента кода зависит от
// того, для какой аппаратной платформы мы его скомпилировали. Но на самом деле это не так.
// В действительности данный фрагмент кода может быть обработан компилятором любым возможным
// и невозможным образом. Причина в следующем: согласно тексту стандарта языка Си битовый
// сдвиг на величину, большую или равную размеру выражения в битах, является неопределённым
// поведением. Получается, нет никакой гарантии, что этот кусок кода вообще будет работать.
j123123 12.11.2021 19:12 # +3
> Вполне вероятно, что среди разработчиков компилятора gcc были непревзойденные мастера софистики. В любом случае способности компилятора к оптимизациям явно превосходят все доступные человеческому разуму пределы.
Какой багор )))
об этом кстати есть баг: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
memcpy implementation optimized as a call to memcpy
Можно memcpy на ассемблере написать, тогда нихуя уже не заоптимизируется
ASD_77 12.11.2021 19:16 # 0
bormand 12.11.2021 19:17 # 0
guest6 12.11.2021 19:25 # +2
j123123 12.11.2021 19:27 # 0
HE_OTBE4Au_YE6KY 12.11.2021 19:41 # 0
С этим багом я столкнулся ещё когда спамил на gaycity.ru.
JlAKOMKA 12.11.2021 20:37 # 0
bormand 12.11.2021 19:34 # +3
Какой багор )))
HE_OTBE4Au_YE6KY 12.11.2021 19:39 # 0
bormand 12.11.2021 19:39 # +2
guest6 12.11.2021 19:12 # 0
ASD_77 12.11.2021 19:15 # 0
Kozel 13.11.2021 11:10 # −1
При мне кое-кому приходилось вычислять, сколько процентов от одного большого числа составляет другое (потенциально не влезающее в 4 байта при умножении на 100). И они там нагородили что-то плавающее.
Кстати, у каких-нибудь компиляторов языков уровня выше ассемблера есть гарантия, что при умножении 4-байтовых чисел и использовании результата как 8-байтового задействуются вышеупомянутые инструкции?
ЗЫ при чём здесь zx spectrum, если ROR, ROL и даже RCR с RCL есть и в x86?
bormand 13.11.2021 11:44 # 0
Desktop 13.11.2021 16:52 # 0
Steve_Brown 15.11.2021 11:54 # 0
j123123 12.11.2021 19:16 # +1
лалки проявили свою анскильность. Ведь CHAR_BIT есть:
и он не везде 8
bormand 12.11.2021 20:40 # 0
BAJlEHOK 12.11.2021 19:28 # 0
Сударыня-барыня,
Если баринъ при цепочке,
Значит, баринъ безъ часовъ.
ObeseYoung 14.11.2021 00:08 # 0
j123123 15.11.2021 01:31 # 0
N2709 - Adding a Fundamental Type for N-bit Integers
_BitInt(N), where N is the number of bits you want in an integer, is a really, really big deal for C in my opinion. There have been entire extensions built around C for analyzing the compile-time information available to integers in C programs. Most often, that information is used to determine the effective range of integer operations, and strip off those bits for savings in e.g. FPGAs or other custom hardware. Entire optimizations go into “how many bits is this really using and can I get some speed if I rearrange these 4 integers to instead be a smaller set of bytes I can perform parallel instructions with?”. Unfortunately, all of that has been stuck fairly fundamentally in the land of “special magic C users cannot hope to touch”.
Until now.
_BitInt(N) makes C suitable for hardware and embedded work, as it provides something that BitVec Author and Embedded Badass myrrlyn explains succinctly:
Какое битоебство )))
Интересно, в кресты это перенесут потом?
bormand 15.11.2021 08:52 # 0
j123123 15.11.2021 12:00 # +2
ropuJIJIa 04.12.2021 02:11 # +1
j123123 04.12.2021 01:37 # +1
https://habr.com/ru/post/592233/comments/#comment_23781835
Вот зацените че пишут:
> Паскаль всегда был и остается языком высокого уровня, поэтому размер типа Integer там не указан намеренно.
bormand 04.12.2021 01:38 # +1
j123123 04.12.2021 01:40 # +3
bormand 04.12.2021 01:42 # +1
CHayT 04.12.2021 01:42 # +3
- Хабрапидор! - в один голос заорали все 3 пользователя ГК.
- Хабрапидор! Хабрапидор! Хабрапидор!
Кто-то включил сирену. Над дверьми замигали красные лампочки тревоги. На окнах мгновенно сомкнулись плотные жалюзи. На сайте одновременно бывает полтора человека. На обеде вся эта толпа собирается на первом этаже, где яблоку негде упасть. А поэтому, как страйкер ни пытался вырвать хабрапидора из рук разъяренной толпы, ему это не удалось. По всему говнокоду стоял сплошной рев:
- Хабрапидор!
bormand 04.12.2021 02:02 # 0
guest6 04.12.2021 02:25 # 0
В современном си есть uint_t всякие, стало быть это язык низкого уровня.
Desktop 04.12.2021 02:26 # 0
guest6 04.12.2021 02:29 # 0
Desktop 04.12.2021 02:31 # +1
но вообще к obj c без защитного костюма приближаться не советую, можно подхватить что-то эдакое, низкоуровневое
guest6 04.12.2021 03:03 # 0
Низкоуровневая хуита была вроде в районе KeyChain. Там вдруг торчал CoreFoundation и сишечный API. Возможно потом починили
Desktop 04.12.2021 03:07 # 0
3oJIoTou_xyu 04.12.2021 06:34 # +3
ObeseYoung 04.12.2021 15:28 # 0
Desktop 04.12.2021 15:32 # 0
OMuKPOH 05.12.2021 01:06 # 0