- 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". Мы могли бы сделать вывод, что результат работы данного фрагмента кода зависит от
// того, для какой аппаратной платформы мы его скомпилировали. Но на самом деле это не так.
// В действительности данный фрагмент кода может быть обработан компилятором любым возможным
// и невозможным образом. Причина в следующем: согласно тексту стандарта языка Си битовый
// сдвиг на величину, большую или равную размеру выражения в битах, является неопределённым
// поведением. Получается, нет никакой гарантии, что этот кусок кода вообще будет работать.
Follow us!
> Вполне вероятно, что среди разработчиков компилятора gcc были непревзойденные мастера софистики. В любом случае способности компилятора к оптимизациям явно превосходят все доступные человеческому разуму пределы.
Какой багор )))
об этом кстати есть баг: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
memcpy implementation optimized as a call to memcpy
Можно memcpy на ассемблере написать, тогда нихуя уже не заоптимизируется
С этим багом я столкнулся ещё когда спамил на gaycity.ru.
Какой багор )))
При мне кое-кому приходилось вычислять, сколько процентов от одного большого числа составляет другое (потенциально не влезающее в 4 байта при умножении на 100). И они там нагородили что-то плавающее.
Кстати, у каких-нибудь компиляторов языков уровня выше ассемблера есть гарантия, что при умножении 4-байтовых чисел и использовании результата как 8-байтового задействуются вышеупомянутые инструкции?
ЗЫ при чём здесь zx spectrum, если ROR, ROL и даже RCR с RCL есть и в x86?
лалки проявили свою анскильность. Ведь CHAR_BIT есть:
и он не везде 8
Сударыня-барыня,
Если баринъ при цепочке,
Значит, баринъ безъ часовъ.
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:
Какое битоебство )))
Интересно, в кресты это перенесут потом?
https://habr.com/ru/post/592233/comments/#comment_23781835
Вот зацените че пишут:
> Паскаль всегда был и остается языком высокого уровня, поэтому размер типа Integer там не указан намеренно.
- Хабрапидор! - в один голос заорали все 3 пользователя ГК.
- Хабрапидор! Хабрапидор! Хабрапидор!
Кто-то включил сирену. Над дверьми замигали красные лампочки тревоги. На окнах мгновенно сомкнулись плотные жалюзи. На сайте одновременно бывает полтора человека. На обеде вся эта толпа собирается на первом этаже, где яблоку негде упасть. А поэтому, как страйкер ни пытался вырвать хабрапидора из рук разъяренной толпы, ему это не удалось. По всему говнокоду стоял сплошной рев:
- Хабрапидор!
В современном си есть uint_t всякие, стало быть это язык низкого уровня.
но вообще к obj c без защитного костюма приближаться не советую, можно подхватить что-то эдакое, низкоуровневое
Низкоуровневая хуита была вроде в районе KeyChain. Там вдруг торчал CoreFoundation и сишечный API. Возможно потом починили