-
- Ага. "Код на Perl выглядит одинаково до и после RSA шифрования" :) - Evgeny_CD(17.01.2017 23:38)
- Умножьте мне этим "ассемблером", прости господи, два 16-разрядных целых, чтоб получилось 32-разрядное целое. Вот там где действительно надо, этот ассемблер начинает косить под взрослого. - Крок(17.01.2017 23:31)
- Ой блин, разобраться в правилах приведения типов сложно. "c32 = (uint32_t)a16 * b16;" Это же не "окей гугл", надо и в учебник и/или справочник заглянуть для приличия. - SciFi(17.01.2017 23:43 - 23:47)
- +1 - Evgeny_CD(17.01.2017 23:56)
- На С++ можете записать так: "c32 = uint32_t(a16) * b16;", оно уже понятнее и недвусмысленно. - Ксения(17.01.2017 23:51)
- Я усматриваю тут офигенную иронию. Типа, язык Си не осилили (ну, оператор приведения типа просто за пределами понимания). Поэтому переходим к языку Си++, который на порядок сложнее. Где логика?!! :-) - SciFi(17.01.2017 23:55 - 23:57)
- Нет иронии. Если в проекте есть С++ - то почему бы его не использовать на всю катушку? Но перехолдить на С++ только ради приведения типов, вероятно, не стоит. - Evgeny_CD(17.01.2017 23:57)
- "Использовать Си++ на всю катушку" - это, как говорит вероятный противник, "recipe for disaster" :-) - SciFi(17.01.2017 23:59)
- -> Мне добавить нечего. - Evgeny_CD(18.01.2017 00:02, ссылка)
- "Использовать Си++ на всю катушку" - это, как говорит вероятный противник, "recipe for disaster" :-) - SciFi(17.01.2017 23:59)
- Нет иронии. Если в проекте есть С++ - то почему бы его не использовать на всю катушку? Но перехолдить на С++ только ради приведения типов, вероятно, не стоит. - Evgeny_CD(17.01.2017 23:57)
- Я усматриваю тут офигенную иронию. Типа, язык Си не осилили (ну, оператор приведения типа просто за пределами понимания). Поэтому переходим к языку Си++, который на порядок сложнее. Где логика?!! :-) - SciFi(17.01.2017 23:55 - 23:57)
- Да написать-то можно. Но во что это превращается в машинном коде, не приходилось глянуть? - Крок(17.01.2017 23:49)
- Приходилось - всё там хорошо. Но зачем туда смотреть? У вас нездоровая привычка подглядывать? - SciFi(17.01.2017 23:51)
- Грешен. Он выдёргивает оба числа, делает их 32-разрядными, потом производит умножение 32х32,( а это совсем не то же самое, что 16х16), потом из 64-разрядного результата делает 32-разрядный. - Крок(18.01.2017 00:14)
- Код - в студию! И что за компилятор? Опять же, даже если так, грозит ли проекту крах? Видимо, нет. Тогда что это, если не греховные поползновения? - SciFi(18.01.2017 00:16)
- Я что, Моника Левински - говно всякое хранить? Посмотрел, плюнул, дальше пошёл. - Крок(18.01.2017 00:19)
- архитектура какая? есть ли в ней 16*16 вообще? - Mahagam(18.01.2017 00:16)
- ДСПИК, разумеется - Крок(18.01.2017 00:18)
- Пжалста - unsigned int x = 0x1234, y = 0x5678; static unsigned long z; z = __builtin_muluu(x,y); MBedder(523 знак., 18.01.2017 03:11 - 03:15)
- Дык они придумали этот билтин не от хорошей жизни. Просто компилятор сделан
через жокривыми руками, вот и не умеет сам генерить хорошие инструкции - приходится давать пенделя. - SciFi(18.01.2017 11:19)- Вот без такого билтина/интринсика компиляторы для получения 32-битного результата от 16х16 и вынуждены выполнять сначала расширение 16 в 32, а затем умножение 32х32=32, дабы следовать стандарту. Подобный интринсик сгодился бы и в Кейлах/ИАРах - MBedder(18.01.2017 11:29)
- Полная фигня, ничего они не вынуждены. Если твой кривой компилятор расширяет 16 в 32 там, где это не требуется из семантики, это не значит, что все остальные компиляторы столь же убоги. Вот тебе пример --> - SciFi(18.01.2017 11:33, ссылка)
- угу - MBedder(18.01.2017 12:29)
- Вот ещё пример (-->). Яр для стм8 убог. А Ксения повторяет там всё то же заблуждение в тщетной попытке оправдать свой любимый яр :-) - SciFi(18.01.2017 12:36, ссылка)
- Это STM8 убог :) - Ксения(18.01.2017 14:40)
- :-) Не возьмусь судить, но он няшный :-) - SciFi(18.01.2017 14:47)
- и ещё HCS08 убожество. )) - Mahagam(18.01.2017 14:43)
- Это STM8 убог :) - Ксения(18.01.2017 14:40)
- Вот ещё пример (-->). Яр для стм8 убог. А Ксения повторяет там всё то же заблуждение в тщетной попытке оправдать свой любимый яр :-) - SciFi(18.01.2017 12:36, ссылка)
- угу - MBedder(18.01.2017 12:29)
- Полная фигня, ничего они не вынуждены. Если твой кривой компилятор расширяет 16 в 32 там, где это не требуется из семантики, это не значит, что все остальные компиляторы столь же убоги. Вот тебе пример --> - SciFi(18.01.2017 11:33, ссылка)
- Вот без такого билтина/интринсика компиляторы для получения 32-битного результата от 16х16 и вынуждены выполнять сначала расширение 16 в 32, а затем умножение 32х32=32, дабы следовать стандарту. Подобный интринсик сгодился бы и в Кейлах/ИАРах - MBedder(18.01.2017 11:29)
- Что-то мне подсказывает, что встроенная функция - самопал? Ну и это, второе слово результата куда складывается? Я бы написал z+2 - Крок(18.01.2017 09:24)
- Дык они придумали этот билтин не от хорошей жизни. Просто компилятор сделан
- Повинен ли С в кривом микрочипеговском компилере? - Evgeny_CD(18.01.2017 00:21)
- когда я увижу, что на пяти других семействах этот фрагмент решается по-людски, я смогу дать аргументированный ответ. Ну и да, для АРМ-машин прошу масштабировать пример до С64=а32*b32 - Крок(18.01.2017 00:34)
- Все подобного рода случаи решаются с помощью вызова функций, а не насилованием языка. Скажем в Windows API есть функция Int32x32To64(a, b), а в IAR EWAVR есть int __multiply_signed(signed char, signed char). А если сделать так, как хотите вы Ксения(129 знак., 18.01.2017 01:00)
- Согласен. Но тогда не надо называть этот язык "ассемблером", с чего собственно базар и начался. Крок(310 знак., 18.01.2017 01:25)
- Это не из IAR intrinsics? -> - Evgeny_CD(18.01.2017 01:10, ссылка)
- Он самый, ассемблерная подстановка. Так всегда обычно поступают, когда в инструкциях процессора команда есть, а в языке нет ее аналога. Скажем, в том же IAR EWAVR есть функция для обмена местами тетрад в байте - swap_nibbles(unsigned char), Ксения(195 знак., 18.01.2017 01:18)
- intrinsics - это хороший механизм, но он компилерозависим. Надо быть готовым перелопатить эти места при смене компилера. Evgeny_CD(101 знак., 18.01.2017 01:23 - 01:29)
- Смотрите шире. Скажем в C/C++ нет циклического сдвига, а он частенько бывает нужен, или риверс битов для того же FFT. Причем, выход из таких ситуаций именно таков, как я сказала - даруют intrinsics-функции, если процессор на эти действия способен. Ксения(551 знак., 18.01.2017 01:36)
- Интересно, как ведут себя компилеры, если разрядность операндов отличается от той разрядности, под которую заточена конкретная команда, закодированная intrinsic? Они выдают ошибку, пытаются приводить типы? - Evgeny_CD(18.01.2017 01:55)
- Приводятся типы. - Ксения(18.01.2017 02:06)
- Интересно, как ведут себя компилеры, если разрядность операндов отличается от той разрядности, под которую заточена конкретная команда, закодированная intrinsic? Они выдают ошибку, пытаются приводить типы? - Evgeny_CD(18.01.2017 01:55)
- Смотрите шире. Скажем в C/C++ нет циклического сдвига, а он частенько бывает нужен, или риверс битов для того же FFT. Причем, выход из таких ситуаций именно таков, как я сказала - даруют intrinsics-функции, если процессор на эти действия способен. Ксения(551 знак., 18.01.2017 01:36)
- intrinsics - это хороший механизм, но он компилерозависим. Надо быть готовым перелопатить эти места при смене компилера. Evgeny_CD(101 знак., 18.01.2017 01:23 - 01:29)
- Он самый, ассемблерная подстановка. Так всегда обычно поступают, когда в инструкциях процессора команда есть, а в языке нет ее аналога. Скажем, в том же IAR EWAVR есть функция для обмена местами тетрад в байте - swap_nibbles(unsigned char), Ксения(195 знак., 18.01.2017 01:18)
- Какой ужас... - SciFi(18.01.2017 01:06)
- Не ужас, а вполне рациональное требование, чтобы по умолчанию операнды были одинаковой разрядности. А для тех, кого это не устраивает, пишутся специальные функции. - Ксения(18.01.2017 01:10)
- Вы не поверите, но уже лет тридцать во всех АЛУ разрядность результата больше разрядности операндов. Особенно, когда речь идёт об умножении. И если язык упорно игнорирует этот факт, есть смысл задуматься. - Крок(18.01.2017 01:45)
- Это мелкое неудобство. Всего лишь иногда нужно добавлять явное приведение типа. Я не пытался анализировать, как можно было бы исправить правила приведения типов в Си под это дело, но есть сильное подозрение, что получилось бы полное безобразие. SciFi(35 знак., 18.01.2017 11:31)
- Так только у целых, а у флоатов этого нет. Поэтому выходит так, что только одно лишь умножение int на int стоит особняком. Следовательно, именно этот случай является исключительным, а потому и не должен быть принят как правило по умолчанию. - Ксения(18.01.2017 02:11)
- Ну здрасьте. Сложите два флота с разными порядкаи. - Крок(18.01.2017 09:30)
- Вы не поверите, но уже лет тридцать во всех АЛУ разрядность результата больше разрядности операндов. Особенно, когда речь идёт об умножении. И если язык упорно игнорирует этот факт, есть смысл задуматься. - Крок(18.01.2017 01:45)
- Не ужас, а вполне рациональное требование, чтобы по умолчанию операнды были одинаковой разрядности. А для тех, кого это не устраивает, пишутся специальные функции. - Ксения(18.01.2017 01:10)
- Cortex-M* - это, наверное, тысяча семейств микроконтроллеров, и GCC 4.9, например, генерит для них неплохой код. - Evgeny_CD(18.01.2017 00:36)
- Вам я даже на слово поверю - эта процедура действительно выполняется в четыре команды? Ну и это, каждый Кортех - это всё-таки одно семейство, а не тысяча. - Крок(18.01.2017 00:40)
- Пусть коллеги с развернутым GCC подтвердят. - Evgeny_CD(18.01.2017 00:47)
- Я бы подтвердил, но поциент уходит в несознанку и почему-то ссылается на мисс Левински. - SciFi(18.01.2017 00:49)
- Жду подтверждения. - Крок(18.01.2017 00:51)
- Я тоже жду. Кода. - SciFi(18.01.2017 00:53)
- с64=a32*b32 - Крок(18.01.2017 00:57)
- Контекста не хватает. Я предполагаю, что это 3 переменные. Извольте показать код с объявлениями их типов. Если это не затруднит Ваше Высочество, конечно. - SciFi(18.01.2017 00:59)
- var Крок(257 знак., 18.01.2017 01:16)
- Вот (исправлено, я там сначала перепутал уровень оптимизации): SciFi(470 знак., 18.01.2017 09:57 - 11:15)
- ОК. Был неправ. - Крок(18.01.2017 12:43)
- Скорее всего такой код компилятор свернет до единственной загрузки константы. - Lightelf(18.01.2017 02:07)
- Волатилями/статиками/глобалами припудрить - и не свернет - MBedder(18.01.2017 11:32)
- Ответ принят. В копилку. - Крок(18.01.2017 09:31)
- :) - Evgeny_CD(18.01.2017 02:11)
- Вот (исправлено, я там сначала перепутал уровень оптимизации): SciFi(470 знак., 18.01.2017 09:57 - 11:15)
- var Крок(257 знак., 18.01.2017 01:16)
- Контекста не хватает. Я предполагаю, что это 3 переменные. Извольте показать код с объявлениями их типов. Если это не затруднит Ваше Высочество, конечно. - SciFi(18.01.2017 00:59)
- с64=a32*b32 - Крок(18.01.2017 00:57)
- Я тоже жду. Кода. - SciFi(18.01.2017 00:53)
- Жду подтверждения. - Крок(18.01.2017 00:51)
- Я бы подтвердил, но поциент уходит в несознанку и почему-то ссылается на мисс Левински. - SciFi(18.01.2017 00:49)
- Пусть коллеги с развернутым GCC подтвердят. - Evgeny_CD(18.01.2017 00:47)
- Вам я даже на слово поверю - эта процедура действительно выполняется в четыре команды? Ну и это, каждый Кортех - это всё-таки одно семейство, а не тысяча. - Крок(18.01.2017 00:40)
- Все подобного рода случаи решаются с помощью вызова функций, а не насилованием языка. Скажем в Windows API есть функция Int32x32To64(a, b), а в IAR EWAVR есть int __multiply_signed(signed char, signed char). А если сделать так, как хотите вы Ксения(129 знак., 18.01.2017 01:00)
- когда я увижу, что на пяти других семействах этот фрагмент решается по-людски, я смогу дать аргументированный ответ. Ну и да, для АРМ-машин прошу масштабировать пример до С64=а32*b32 - Крок(18.01.2017 00:34)
- Пжалста - unsigned int x = 0x1234, y = 0x5678; static unsigned long z; z = __builtin_muluu(x,y); MBedder(523 знак., 18.01.2017 03:11 - 03:15)
- ДСПИК, разумеется - Крок(18.01.2017 00:18)
- Код - в студию! И что за компилятор? Опять же, даже если так, грозит ли проекту крах? Видимо, нет. Тогда что это, если не греховные поползновения? - SciFi(18.01.2017 00:16)
- Грешен. Он выдёргивает оба числа, делает их 32-разрядными, потом производит умножение 32х32,( а это совсем не то же самое, что 16х16), потом из 64-разрядного результата делает 32-разрядный. - Крок(18.01.2017 00:14)
- чаще всего в то, что требуется. и что возможно на текущей архитектуре. - Mahagam(17.01.2017 23:50)
- Приходилось - всё там хорошо. Но зачем туда смотреть? У вас нездоровая привычка подглядывать? - SciFi(17.01.2017 23:51)
- Ой блин, разобраться в правилах приведения типов сложно. "c32 = (uint32_t)a16 * b16;" Это же не "окей гугл", надо и в учебник и/или справочник заглянуть для приличия. - SciFi(17.01.2017 23:43 - 23:47)