caxapa.ru :: Изначально мудацкая идея: давайте ширше использовать всякие комбинации значков *%<+ в одной команде и будет офигенная экономия! Ты, ссуко, пишешь проект на стотыщ строк и экономишь на символах. Потом появляются имена переменных, больше похожие на

Крок (17.01.2017 23:19, просмотров: 123) ответил Evgeny_CD на +1

Изначально мудацкая идея: давайте ширше использовать всякие комбинации значков *%<+ в одной команде и будет офигенная экономия! Ты, ссуко, пишешь проект на стотыщ строк и экономишь на символах. Потом появляются имена переменных, больше похожие на названия средневековых романов "Легенда_о_рыцаре_Айвенго_короле_Арктуре_и_прекрасной принцессе", потом взаимодействие нескольких файлов в проекте: многочисленные IFDEF, спрашивается, ну и на хрена та экономия?

Ответить

- Идея компилятора с кувалдой, которой тот лупасил бы ~~программиста~~ кодера по голове, давно будоражит умы. Но это осознанная особенность языка, никто не заставляет писать именно так. - Скрипач(17.01.2017 23:47 - 18.01.2017 00:05)
  - Человек слаб. Никто не заставляет людей ездить на лифте. В результате болезни порно-двигательного аппарата вторые после сердечных. - Крок(18.01.2017 00:21)
    - Про порно это ты хорошо задвинул ;) - Гудвин(18.01.2017 00:23)
      - :)) - MBedder(18.01.2017 00:39)
        
        Я вот уже полчаса пытаюсь представить себе такой аппарат - и не могу. Порно-упорный еще куда ни шло, но двигательный - это это выше моих сил :) - Evgeny_CD(18.01.2017 00:46)
  - +1 - Evgeny_CD(17.01.2017 23:54)
- С++, пространства имен, шаблоны, классы, грамотное наследование - не? - Evgeny_CD(17.01.2017 23:39)
  - От яблони не родится апельсин. Буква С в названии должна насторожить. - Крок(17.01.2017 23:45)
    - Или обрадовать - улучшили хороший язык :) - Evgeny_CD(18.01.2017 00:12)
      - Цены там отчасти разумные, но я не пробовал покупать. - Evgeny_CD(18.01.2017 00:27)
      - Понемногу прихожу к выводу, что мы с Вами решаем разные задачи в приборах, отсюда разные требования к языкам. Я-то преимущественно щщитаю. А Си-шная тусовка просто вытоптала поляну - других языков для микропроциков и нету. Отсюда моё раздражение Крок(22 знак., 18.01.2017 00:17)
        
        Ваше замечание справедливо. Но уже есть микроконтроллерный Oberon -> Хороший кандидат для желающих попробовать хардкорную альтернативу. - Evgeny_CD(18.01.2017 00:24, ссылка)
        
        Продают? - Крок(18.01.2017 00:26)
  - И описание языка на over9000 страниц. В следующей версии будет 100500 страниц. - SciFi(17.01.2017 23:45)
    - Рано или поздно я разрисую граф сущностей С++. Уверен - на А0 в читабельном варианте поместится. - Evgeny_CD(17.01.2017 23:58)
- Ну, сия концепция доведена до абсолюта в Перле :-) А про Си авторы сразу говорили "высокоуровневый ассемблер". То есть обосраться можно чуть менее, чем везде, и значки тут мало что меняют. - SciFi(17.01.2017 23:25)
  - Ага. "Код на 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, ссылка)
      - Да написать-то можно. Но во что это превращается в машинном коде, не приходилось глянуть? - Крок(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)
        
        Кстати, Моника Левински в узких кругах известна тем, что говнокодит, списывает свои огрехи на язык программирования, плюёт и идёт дальше. Такшта я бы не спешил с выводами... - SciFi(18.01.2017 00:25)
        
        архитектура какая? есть ли в ней 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)
        
        Что-то мне подсказывает, что встроенная функция - самопал? Ну и это, второе слово результата куда складывается? Я бы написал z+2 - Крок(18.01.2017 09:24)
        
        Второе слово и складывается в z+2, просто в окне дизассемблера это выглядит как @0x802. А встроенная функция - не самопал, а штатная, полностью документированная как в С30, так и в ХС16 - MBedder(18.01.2017 11:13)
        
        Повинен ли С в кривом микрочипеговском компилере? - 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)
        
        Только что прошлась отладчиком - там только лишний jmp на входе. Т.е. сперва CALL (это раз), затем JMP в Kernel32.dll (это два), далее там выполняется код функции и на RET (это три) возвращается назад. По нынешнему времени процессоры Intel Ксения(603 знак., 18.01.2017 02:01)
        
        Это не из 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)
        
        Какой ужас... - 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)
        
        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)
        
        чаще всего в то, что требуется. и что возможно на текущей архитектуре. - Mahagam(17.01.2017 23:50)

Средства и методы разработки