Procedure for Runtime Microcode Update
To load an update during runtime, software should synchronize all logical processors within the system (perform a rendezvous) to load the update in a coordinated manner.
Once all logical processors have been synchronized, one logical processor in each core should load the update while sibling logical processors wait in a spin loop of only basic instructions. Some guidelines are:
The spin loop should not contain MWAIT or HLT. PAUSE or LFENCE may be used to throttle the loop.
Software may load microcode on each core in parallel.
To help improve performance, software should check that the microcode is newer than what is already loaded immediately prior to doing the write. This may avoid redundant microcode updates, especially on processors where a microcode update also updates microcode on other cores.
You can see an example of the microcode update procedure below:
microcode_update_sync() {
primary_thread_done = 0
check in to MCU_GO barrier
wait for MCU_GO barrier
if (primary_thread_of_core) { // always true if no HT
cpuid
rev_id = rdmsr(0x8b).edx
if (update_id < 0 || update_id > rev_id) {
load_update()
}
primary_thread_done = 1
} else { // other HW threads (if they exist)
while (primary_thread_done == 0) {
pause //lfence is also acceptable
}
cpuid
rev_id = rdmsr(0x8b).edx
if (update_id != rev_id &&
(update_id < 0 || update_id > rev_id)) {
load_update()
}
}
check in to MCU_DONE barrier
wait for MCU_DONE barrier
}
Непонятно, зачем он нужен, этот наблюдаемый сайд-эффект? И кому именно? Если счастье приносит процесс прорешивания и чтения — нет причин бороться с этим.
У не-фигни-не-ерунды нет толком определения, и если таковая хоть каким-то критериям научности удовлетворяет — можно смело заниматься. Нельзя предсказать, что в будущем понадобится, и возможно какое-то ерундовое решение простой вроде бы задачи станет через 300 лет основанием новой научной дисциплины «на стыке кибернетики и математики».
В общем, я за то, чтобы писать просто потому, что не можешь не писать, и заниматься ресерчем и распространением его результатов просто потому, что не можешь не заниматься. Назвать это наукой или ерундой — пофиг вообще, лишь бы радость приносило.
Успехи нормально, никто пока не жаловался. Опять же непонятно, что именно считать мерилом успеха: известность, количество публикаций, количество цитирований, количество приглашений на конференции, попадание в учебники, признание от коллег, получение премий, еще что-то? Главное, чтобы человеку этому самому было сухо и комфортно, потому что он там в науке свое призвание реализует, а все эти внешние атрибуты успеха — кому они нужны, на самом деле?
Я считаю, что это все уже давно наука была и есть, и языки все эти хитрые, которые вы сейчас разрабатываете — это тоже наука практически чистая.
Навскидку из педивикии: George Green, Alexandre Théophile Vandermonde, Marjorie Rice и прочие adult late bloomers. Ситуацию, когда человек проработал в индустрии, уперся там в личный потолок, взял паузу и пошел получать PhD, а затем полностью ушел в науку и больше в индустрию не возвращался — наблюдал несколько раз уже лично.
Не обязательно входить сразу в профессиональный балет, или сразу хотеть в Nature печататься. Мы видимо, под занятиями «наукой» разные вещи понимаем…
Фаундеры и все такое — это вообще разговор отдельный и очень часто не про деньги. Мне самому непонятна до конца их мотивация, поэтому рассуждать о них не готов.
Не думаю, что 35-40 — это приговор, и мозги все еще работают (мне сейчас 33, жалобы есть, но не принципиальные). Многие ученые начинали значительно позже, и добились вполне себе успехов, да и без успехов тоже не так плохо, потому что наукой эти люди все равно занимаются для себя в первую очередь.
Потому что хозяевам балагана не хочется в другой штат, наверное, их и в Калифорнии неплохо кормят, а простые рабочие дроны стерпят все, в том числе и 60-80-100 часов абьюза в неделю, которые требуются для этой вот работы под миллион. Ну его в жопу, я считаю, лучше спокойно работать 10+ лет, чем сгореть дотла за 3-5, и дальше все деньги тратить на терапию.
Пару сложно заработать, потому что налоги 40%+, т.е. заработал два миллиона за 5 лет, а остался один, но даже на один можно вполне сносно жить практически вечно (если не смущает жизнь в дешевой глуши и хранение миллиона на фондовом рынке), и дальше двигать хоть науку, хоть опенсорс, хоть еще что. Еще и на всякий консалтинг и DIY время останется.
Ну вот тут у нас и остается один шаг до собственного SDK, раз уж мы решили так яростно вмешиваться в работу юзерспейса, что запускаемся там init'ом, контролируем сокеты и т.п. «Так долго боролся с драконами, что сам им стал».
Китайские ODMы ничего не могут сделать с проблемами безопасности, потому что у них нет профильных специалистов, поэтому отдать туда разработку — гарантировать себе наличие проблем безопасности и\или бэкдоров.
Еще один пример UINT24 — это UEFI Firmware File System v2, где Intel не хватило одного байта в заголовке размером 24 байта, и чтобы не поплыло все выравнивание его решили откусить от размера файла, потому что 16 мегабайт (0xFFFFFF) должно хватить всем. В результате, понятно, не хватило, и пришлось выдумывать FFSv3, править все заголовки, обновлять все парсеры, и до сих пор еще встречаются прошивки, которые тома с v3 толком прожевать не могут и зависают в случайных местах.
Короче, если у вас там не прямо жесть-жесть, то экономить один байт, чтобы потом иметь геморрой и новый заголовок на восемь — это плохая негодная стратегия, не рекомендую.
Разгребание false-positive улучшает и кодовую базу, и самих разработчиков даже в Урюпинске. Понятно, что если вас код плюс-минус устраивает, и он сам по себе не является целью или ценностью, а только средством решения каких-то других проблем, тратить ресурсы на внедрение статического анализа нужно с умом.
Правда же сермяжная состоит в том, что чем раньше ошибку настоящую удалось заметить, тем дешевле ее починить, и в Урюпинске это не чуть ни менее верно, чем в Зеленограде, Берлине, Тель-Авиве, или Сан-Франциско.
Анализатор в существующий CI/CD-пайплайн добавляется без существенных затрат, и сам он стоит далеко не как самолет (а с разработчиками еще и на скидку можно договориться гораздо чаще, чем нет), и при этом он снижает нагрузку на все последующие этапы производства ПО, потому что ловит тупые ошибки программирования вроде копи-пасты неудачной прямо на излете, еще до попадания их в репозиторий или основную ветку.
Если действительно учли сроки и бюджет, изучили количество ложных срабатываний на своем коде, и выяснили, что для вас лично анализатор не нужен или даже вреден — честь вам и хвала, снимаю шляпу.
И в таких условиях говорить разработчику «чувак, у тебя здесь ошибка» вместо «чувак, а ты точно уверен, что здесь нужна проверка, т.к. локальных модификаций я здесь не вижу» — это (как по мне) введение разработчика в заблуждение.
Мне кажется, мы с вами принципиально по разному подходим к интерпретации сообщений анализатора. Для меня они всегда указывают не на реальные ошибки, а на потенциальные, и все равно человек в итоге принимает решение, ошибка это или нет. Уже писал, что для меня ложные срабатывания анализатора — это уже сигнал, что с кодом что-то не так, и стоило бы посмотреть на него внимательнее, и возможно улучшить так, чтобы у анализатора не было претензий, но и блокировать релиз для всего этого я тоже не стану.
Этого «должен НЕ учесть» в вашем оригинальном комментарии не было. Наоборот, он это учтет, и выкинет все дальнейшие проверки как always false. PVS-Studio, кстати, в compiler explorer'е есть тоже, и она действительно выдает неверное предупреждение 11:1: error: V547 Expression 'flag == 0' is always true на вторую проверку.
Вот хороший пример того, что data-flow-анализ у компилятора оказался лучше, чем у анализатора, и вот это предупреждение — действительно ложное срабатывание.
Не приведи рандом добиваться этого. Хотите считать это «сперва добейся» — ваше право, я делюсь тем опытом, который имею, и теми условиями, в которых приходится работать, если у вас другие условия — отлично, это не значит что вам нужно стремиться к моим, или мне — к вашим. В моем мире не просто «с анализатором лучше», а давно уже «без анализатора полный конец обеда», если у вас не так — я реально рад.
Приведенный код корректен и будет работать как задумано пока побочный эффект функции func_with_side_effects() приводит к невозможности применения компилятором sequential read/compare elimination. Вот этот инвариант, и подобные ему, чаще всего существует только в голове у автора кода, и только пока он не забыл его. Дальнейшее сохраниение этого инварианта в условиях постоянной работы над этим кодом людьми, которые не знают о нем ничего — дело исключительно случая, и потому целесообразно с точки зрения безопасника считать что он не выполняется уже сейчас. Поэтому и «скорее всего». Если у вас код пишется одним программистом и не изменяется потом вообще никогда, и все инварианты этот отличный программист поддерживает своими силами — смело считайте срабатывание статического анализатора на этом коде ложным. Я же со своей стороны так сделать не могу и не стану, прошу искреннего пардона.
Ваша позиция тоже понятная, вопросов больше не имею. Меня спросили почему код воняет — я ответил так, как я сам это понимаю. Меня в детстве безопасники покусали, и теперь я предпочитаю дуть на воду, чем обжигаться на молоке, особенно в проектах, над которыми работает больше сотни людей каждый день, а баги в нем стоят миллионы настоящих долларов.
Вы понимаете выражение «сама по себе»? У вас в вопросе дихотомия ложная, потому что это одновременно и «скорее всего будет работать» и «проверка сама по себе не меняет состояние», потому что состояние меняет не проверка, а другая функция.
У не-фигни-не-ерунды нет толком определения, и если таковая хоть каким-то критериям научности удовлетворяет — можно смело заниматься. Нельзя предсказать, что в будущем понадобится, и возможно какое-то ерундовое решение простой вроде бы задачи станет через 300 лет основанием новой научной дисциплины «на стыке кибернетики и математики».
В общем, я за то, чтобы писать просто потому, что не можешь не писать, и заниматься ресерчем и распространением его результатов просто потому, что не можешь не заниматься. Назвать это наукой или ерундой — пофиг вообще, лишь бы радость приносило.
Я считаю, что это все уже давно наука была и есть, и языки все эти хитрые, которые вы сейчас разрабатываете — это тоже наука практически чистая.
Не обязательно входить сразу в профессиональный балет, или сразу хотеть в Nature печататься. Мы видимо, под занятиями «наукой» разные вещи понимаем…
Не думаю, что 35-40 — это приговор, и мозги все еще работают (мне сейчас 33, жалобы есть, но не принципиальные). Многие ученые начинали значительно позже, и добились вполне себе успехов, да и без успехов тоже не так плохо, потому что наукой эти люди все равно занимаются для себя в первую очередь.
Короче, если у вас там не прямо жесть-жесть, то экономить один байт, чтобы потом иметь геморрой и новый заголовок на восемь — это плохая негодная стратегия, не рекомендую.
Правда же сермяжная состоит в том, что чем раньше ошибку настоящую удалось заметить, тем дешевле ее починить, и в Урюпинске это не чуть ни менее верно, чем в Зеленограде, Берлине, Тель-Авиве, или Сан-Франциско.
Анализатор в существующий CI/CD-пайплайн добавляется без существенных затрат, и сам он стоит далеко не как самолет (а с разработчиками еще и на скидку можно договориться гораздо чаще, чем нет), и при этом он снижает нагрузку на все последующие этапы производства ПО, потому что ловит тупые ошибки программирования вроде копи-пасты неудачной прямо на излете, еще до попадания их в репозиторий или основную ветку.
Если действительно учли сроки и бюджет, изучили количество ложных срабатываний на своем коде, и выяснили, что для вас лично анализатор не нужен или даже вреден — честь вам и хвала, снимаю шляпу.
11:1: error: V547 Expression 'flag == 0' is always trueна вторую проверку.Вот хороший пример того, что data-flow-анализ у компилятора оказался лучше, чем у анализатора, и вот это предупреждение — действительно ложное срабатывание.