> Сделай в виде макро и #ifdef (да, так тоже можно – если
> кто спросит, то я разрешил) и будет тебе портабельность.Прости, 84701, но я со своей стороны считаю что:
1) ifdef делает код просто !!!ГАДКИМ!!!
2) Это ломает восприятие логики кода посторонними. Или мной через пару годков.
3) В целом это поле для лажи и багов, поскольку эффективно тестировать код с множеством вариантов сборки довольно проблематично.
4) Более того - если увлечься этими опциями, комбинаторный взрыв сделает 3) невозможным.
> Будто есть еще сотня альтернатив (а в кланге компатибельность с gcc старательно
> наращивали чисто из любви к процессу).
Я использую типы C99 + аккуратное понимание какие у меня данные, так чтобы UB просто не возникал. И, конечно, запустить под asan/ubsan и посмотреть чего они скажут. Я даже в случае МК стараюсь чтобы большая часть алгоритма кроме самой работы с железом работала и на PCшной стороне. Это как раз о плюсах портабельности - на PC можно использовать мощную инструментацию которую на МК поюзать не катит.
> Или я что-то пропустил и есть компиляторы, поддерживающие больше платформ, чем gcc
Есть платформы, где нет GCC, допустим. Не то чтобы я ими пользуюсь (для меня это таки no-go) но все же я предпочитаю не сжигать мосты, если есть такая возможность. Потому что случаи разно бывают, а переписывать код заново я почему-то не люблю, если бы любил, иначе был бы вебмакакой с бидоном или чем там.
> (или хотя бы clang/llvm)?
Ну например под ряд штук понимаемых sdcc? Правда будем честны, я не особо тестировал свои конструкции типа забавных macro. И все же, я ломаю совместимость только как неизбежное зло, если это абсолютно необходимо для очень жирного плюса или фичи, и это по другому не извлекается. Ну да, скажем, сказать компилеру в какую секцию положить мне вот это - априори нестандартно. Но даже так это сделано макро. Если я захочу сменить тулчейн, я переопределю 1 макро в 1 хидере и оно станет збс и там.
> Ну вообще, тогда только C89, только хардкор!
Таки я юзаю C99 и полагаю что относительно живые тулсы его должны более-менее уметь. Если даже tcc умеет - ну, гм...
> Или MS все же допилил поддержку C99?
Не знаю. Они для начала не допилили поддержку наборов команд которые меня могут интересовать.
> Угу, а без выравнивания, SIMD/векторизации/интринсиков и прочего "непортабельного" –
Вообще, теоретически, jit имеет шансы сгенерить аналог -march=native -mtune=native. Однако с учетом свойств JS и решительного нежелания юзерей ждать компила столько же сколько это gcc -Ofast будет делать - оно как-то так очень теоретически, а практически тяжелая математика в лушчем случае разика в 3 тормознее. А про предсказуемые тайминги можно забыть. И нафиг мне такой МК сдался? :)
> можно будет запустить на тостере. Профит, млин.
На тостере ресурсов не хватит. Как показал пример мозилской читалки, даташит на МК оно может рендерить в жыэс минут 5. А потом скончаться по OOM. На компе с 16 гигз оперативы. Потому что выполнить :D 900-страничный док конвертированный в js даже ему слабо oO.
> То-то проблем с компиляцией линукс клангом не было никогда (лишь "небольшие
> помехи") </ирония>
И таки пример - например автор LZ4, обтяпавший все на сях, без асма. Правда компилерспецифичные штуки постепенно навешал, да. И сделал код нечитаемым трэшом.
>> Обеспечена возможность сборки ядер Linux 4.4 и 4.9 при помощи Clang
>> 19.09.2017 22:01
В ядре Linux всегда ориентировались на GCC-only и юзали ряд фич. В том числе и позабавнее. Скажем, много кто догадывается про макро BIT(x) (1 << x). Это очевидно и любой вменяемый прогер это напишет. Однако ж эффективно "инвертировать" сие определение (т.е. получив число, определить какой номер бита выставлен) - явно труднее. Однако у gcc и для этого есть builtin. Проблема в том что вот как раз благодаря таким плюхам собрать его чем-то еще... гм :)
> Fallback никто не запрещал (но в демке выше, он, как бы, никуда не уперся).
Если это именно демка, и хрен с ней, а вот если это уже реальная прога.. расстреливать за его отсутствие, тухлыми помидорами, если не было реально сильных причин (как в примере с секциями).
> Да и с тем, что скорость и безопасность выполнения
> == "неизвестно ради чего", лично я категорически не согласен.
Не вижу ничего криминального обеспечивать безопасность путем due diligence. Если у меня например 12-битные сэмплы ADC, я могу быть уверен что суммировать их в uint16 и тем более 32 будет безопасно, даже worst case. До определенного предела. И это не переполнится (я делаю сэмплам & 0xFFF так что даже сбой железа ADC не сможет вызвать это).
> А речи про сферическо-вакуумную портабельность (и необходимые "жертвы") я уже лет 20
> слышу. Даже если софт имеет смысл запускать на 1½ платформах.
Проблемы начинаются когда захочется запустить это на соседней платформе и/или другом компилере. И ощущать себя как чуваки из колибри ОС мне почему-то совсем не хочется.
> "хорошо-отлично", вместо "ну .... зато оно работает на 100500
> платформах, вот!" (именно так оно почему-то в реальности обычно выходит).
Более того: на МК builtins может или не быть или они могут вести к нежелательным побочным эффектам. А когда я не могу реюзать код это все же голимо.
> Ну вон и там, выше -- такое performance critical место.
Это вообще абстрактный синтетический тест с 0-й полезностью в реальном мире.
> А в glibc их там "овердофига" только для IA – те же
> оптимизации mem*/str* отдельно для *86, MMX/SSE2/3/4/4.2/AVX очень даже внушают.
Между нами, я написал себе свои memcpy/memset/memmove для МК. Как разумный компромисс между скоростью и размером. Как небольшие, читаемые и понятные мне конструкции на си. А то что на асме оно могло бы быть лучше - гм, зато я могу использовать эти при early boot вообще всего чего я касаюсь. А на асме переписывать это для всех железок... хм...
> 1. можно цитату, где я запрещал делать fallback?
Нигде, но это сделает код более гадким и нечитаемым, и еще вопрос кто и сколько багов потом посадит неверно трактовав это и что оно делало.
> тебе "щастье". Просто пихать все это в демку на 15 строк,
> как бы, немного оверкилл.
Я видел к чему это может прийти - и предпочту чтобы такое счастье было от меня подальше :)
> 2. "на асм писать" было вообще-то предложением анонима - у мну этого
> нет даже в "векторизированном" варианте, хотя интринсики/SIMD туда так и просятся.
Я на асме обычно другому поводу. А как аналог "mov SP, R3" на сях сделать? Ну вот не mmaped SP и все тут, а загнать в него нужное - часть процедуры "handover" окружения для следующей части. И вот тут уже приходится смириться с asm().
> Т.е. когда доп. проверки исключали из-за того что "тормозят".
Для себя я предпочту исключить проверки в тугих местах
1) проверив входные данные
2) просчитав что поюзаным типам ОК даже краевые случаи.
Да, это требует немного не быть буратиной. Но мне кажется что си для таких подходов и делался. Если я буду буратиной в какой-нить фирмвари, мне достаточно просто тупануть в ее логике и все сгорит к чертям.
