Вы сами себе противоречите. Сначала говорите, что BSOD в драйвере случается только на старте системы, а через пару предложений - что падает, если нажать хитрую кнопочку в хитром приложении и виноваты в этом драйвера. Не срастаются как-то эти высказывания.
Если система падает на старте, то это что-то сломалось очень сильно, это какая-то хитрая и необычная комбинация чего-то установленного. Обычно же проблемы вылезают именно в процессе работы. В случае железа - например, разогретая видеокарта начала выдавать сбои в памяти. В случае драйвера - либо ошибка, вызываемая каким-нибудь редким рейсом, или, скажем, фрагментацией памяти, или какой-нибудь off-by-one, например, который раз в год попадает "точно в цель".
Только они, емнип, должны были выпускаться где-то на Тайване. Все бы хорошо, но Миландр попал под санкции и все пролетело. Поэтому я не уверен, что "серийная поставка с 2024 г" будет. А микроновский Амур, видимо, производится в России.
Так это презентация ядра SCR1 самого Syntacore. Конечно, они там заявили IPIC, и поставляют IPIC. А Микрон этот IPIC решили не использовать, а вместо него прикрутили какое-то другое (самопальное?) решение.
Как младший представитель линейки пойдет. Будем надеяться, что дальше будет и что-то большее для тех, кому надо - типа 64 кБ RAM, 64 кБ EEPROM, USB, CAN, Ethernet, SRAM/EXTMEM кому 64 кб не хватает... И что-то более вменяемое в прерываниях, а то 8 (восемь!!!) каналов прерывания назначено на 8 катастрофических события PCC (выход за границы по напряжению/частоте/температуре), зато все 8 каналов прерываний от GPIO заведены на единственное прерывание.
В этой функции все прекрасно... примерно такие шедевры получаются, если писать код, не приходя в сознание (как оно и рассказано в статье):
(b << 2) | (c & 0xC0) >> 2 -- явная ошибка со сдвигом >>2, должно быть >>6, иначе биты друг на друга накладываются.
А если это исправить, то получается, что a b c суть части 24-битного значения, которое делится на 18-битную целую и 6-битную дробную часть (в обеих ветках кода, ибо / 64.0 суть intPart + fracPart/64.0
Под вопросом деление fracPart/63.0 в _isFracture части. Может и так быть, конечно, ибо мы не знаем спецификацию входных данных, но я не вижу смысла в таком представлении данных (получается, что целые значения в таком варианте представлены двумя различными вариантами с 0 и 63 в fracPart, и это еще и приводит к уменьшению разрешения представимых данных)
Чую, что что-то не так и с negativeSign. Опять же, без спецификации не понятно, но сочетание ~ и - меня сильно смущает (с учетом того, что такое binary complement), и отдельные танцы с бубнами с fracPart. Я бы в такой функции обязательно оставил комментарий о том, как именно выглядят исходные данные, чтобы можно было разобраться потом.
EDIT: заморочился нашел документацию на FreeD. Видимо, это парсинг вот этого:
"The value is expressed in millimetres as a 24-bit twos-complement signed number, where the most-significant bit (bit 23) is the sign bit, the next 17 bits (bits 22 to 6) are the integer part and the remaining bits (bits 5 to 0) are the fractional part; alternatively, this may be thought of as a signed integer value in units of 1/64 mm. The range of values is from -131,072.0 mm (800000 hex) to nearly +131,072.0 mm (7FFFFF hex)"
То есть авто заморочился и написал оба подхода к решению одной и той же задачи и обе ветки кода должны всегда возвращать одинаковый результат. По факту - в ветке с fracPart - баг с делением на 63 (привносится небольшая ошибка на практически всех значениях) и случайно правильный результат на отрицательных значениях (из серии "ответ правильный, а решение нет"), а в "целочисленной" ветке - ошибка на 1/64 мм на всей отрицательной половине входных значений, включая даже и 0x800000 из документации.
Автомобиль - источник повышенной опасности. Оставим за скобкой злоумышленников - они при желании все равно угонят тачку, пусть она и заперта. А вот пьяная шпана, просто проходящая мимо, может воспринять открытую машину как приглашение покататься - и покататься с "кегельбаном" как результат.
Проведите параллель не в сторону полуголых девиц, а в сторону забытого в кафешке огнестрельного оружия. Логика та же.
Именно про танки (WoT) я не в курсе, я больше warthunder предпочитаю; там скорее сама компания угробит свою игру, чем читы (меня вымораживает регулярно случающийся дикий дизбаланс команд, когда буквально за полминуты, с первого соприкосновения, полкоманды сливается в нули и все, проигрыш обеспечен). Одиночный читер в таких играх имхо меньше проблем может натворить, чем в шутерах.
Но про то, что заморачиваться не будут - не верю. Ребята из Escape from Tarkov в своем античите блокировали Hyper-V, потому что были читы, которые в отдельной виртуалке что-то там химичили с сетевым обменом между игрой и сервером - так любители заводили отдельный компьютер для MitM! Если будет спрос на читы - найдутся замороты, которые обучат сетку на предмет помощи игроку, и найдутся умники, которые это все обернут в красивую конфетку, которую одним кликом можно запустить и наслаждаться.
Читы всегда будут. Просто перехватом вызовов D3D, не трогая приложения вообще, можно натворить немало дел. Убрать траву/дым, подсветить цели (в том числе сквозь препятствия), дать оценку по дальности/скорости/упреждению и т.п.
Даже если сам рендеринг выгрузить на сервер в стиле GeForce NOW, то все равно найдутся любители пообучать нейросеточки на предмет убрать ненужное и дорисовать нужное.
В целом поддерживаю посыл, но в данном конкретном случае это был не "одноразовый баг", а тотальный блокер. Нельзя поставлять потребителю СХД, которая под нагрузкой по нескольку раз в час вешает хост-системе операцию I/O на 10 секунд. Это будет обнаружено заказчиком, прослежено до СХД и заказчик сразу выкатит претензию (и вообще любой нормальный заказчик, получив неизвестную ему модель СХД, сначала проведет те же нагрузочные тесты, чтобы понять, какую нагрузку туда можно давать в продакшне и на что рассчитывать - и сразу же наткнется на эти выбросы).
Обман в том, что искусственно повышается процент локализации. Они могут, например, налепить на плату не 1, а 99 российских чипов, которые будут друг другу по SPI данные гонять. И 1 чип Realtek, который будет делать собственно полезную работу. И честно заявить, что у них 99% чипов - российские.
Если надо работать чисто с шиной PCI, как у автора, то поможет и виртуалка (там виртуальная шина PCI ничем не хуже, чем настоящая), и, например, qemu. Если надо отладить драйвер работы с простым устройством, то можно взять qemu и туда добавить стаб-версию этого устройства (что может быть полезно само по себе для вещей типа автотестов). Если надо работать с реальным железом, то конечно лучше отдельный подопытный комп, независимо от того, есть там DMA, проецируемая память, прерывания или нет.
В 2023 году жить с процессором без поддержки SSE2 довольно грустно (это значит Vista или XP, старинные браузеры, и тд и тп). Но я могу себе представить кого-то, кто сидит на Athlon XP 20-летней давности.
В 2023 жить с процессором без поддержки SSE - это мазохизм (для понимания - это Pentium II или более старые процессоры). Я думаю, что разработчик игрушки в 2023 может спокойно позволить себе пренебречь этим сегментом рынка.
Именно. Все 64-битные процессоры имеют как минимум поддержку SSE2, и для FP вычислений используются "нормальные" регистры FP и нормальные команды SSE, а не стековая машина и сопроцессор x87.
В связи с этим мне непонятно, почему автор посчитал нормальным решением покалечить собственный код volatile-ами (и надеяться, что это единственное такое место и что он или кто-то другой потом вспомнит об этой баге, когда будет делать еще какое-нибудь такое сравнение), вместо того, чтобы просто добавить один флажок компилятору и компилировать 32-битную версию с использованием SSE вместо x87.
А что по этому поводу думают производители "профессиональных" DRO для всяких станков? Наверняка они все дружной толпой уже обеими ногами в 21 веке и у них у всех в качестве решения предлагаются суть iPadы? Или все же в почете все еще физические кнопки?
Все так, но им надо было держать семплы при -80 С в течение 20+ лет, и от этого зависит какое-то супер-пупер-прорывное достижение. Притом потеря электропитания на несколько часов полностью размораживает холодильник.
Если им так важны эти образцы, то, наверное, MTTF у холодильника в районе 100 лет (то, что холодильник вышел в абнормальный режим работы, намекает, что это не так), бесперебойность электричества обеспечена на уровне 99.9999% и тд и тп. Это же не так... Что бы они делали, если бы холодильник не запищал, а тупо помер?
Ну почему же? Сompound literals, array designators и отдельные препроцессорные извращения (в частности, описанное в статье - вариация широко известного паттерна X-macro) убийственно полезны в отдельных случаях, сокращая копипасту и улучшая читабельность кода.
Вы сами себе противоречите. Сначала говорите, что BSOD в драйвере случается только на старте системы, а через пару предложений - что падает, если нажать хитрую кнопочку в хитром приложении и виноваты в этом драйвера. Не срастаются как-то эти высказывания.
Если система падает на старте, то это что-то сломалось очень сильно, это какая-то хитрая и необычная комбинация чего-то установленного. Обычно же проблемы вылезают именно в процессе работы. В случае железа - например, разогретая видеокарта начала выдавать сбои в памяти. В случае драйвера - либо ошибка, вызываемая каким-нибудь редким рейсом, или, скажем, фрагментацией памяти, или какой-нибудь off-by-one, например, который раз в год попадает "точно в цель".
Только они, емнип, должны были выпускаться где-то на Тайване. Все бы хорошо, но Миландр попал под санкции и все пролетело. Поэтому я не уверен, что "серийная поставка с 2024 г" будет. А микроновский Амур, видимо, производится в России.
Так это презентация ядра SCR1 самого Syntacore. Конечно, они там заявили IPIC, и поставляют IPIC. А Микрон этот IPIC решили не использовать, а вместо него прикрутили какое-то другое (самопальное?) решение.
Как младший представитель линейки пойдет. Будем надеяться, что дальше будет и что-то большее для тех, кому надо - типа 64 кБ RAM, 64 кБ EEPROM, USB, CAN, Ethernet, SRAM/EXTMEM кому 64 кб не хватает... И что-то более вменяемое в прерываниях, а то 8 (восемь!!!) каналов прерывания назначено на 8 катастрофических события PCC (выход за границы по напряжению/частоте/температуре), зато все 8 каналов прерываний от GPIO заведены на единственное прерывание.
Просто не убрались в 16 линий встроенного синтакоровского IPIC, поэтому вместо него поставили какой-то EPIC на 32 линии.
В этой функции все прекрасно... примерно такие шедевры получаются, если писать код, не приходя в сознание (как оно и рассказано в статье):
(b << 2) | (c & 0xC0) >> 2 -- явная ошибка со сдвигом >>2, должно быть >>6, иначе биты друг на друга накладываются.
А если это исправить, то получается, что a b c суть части 24-битного значения, которое делится на 18-битную целую и 6-битную дробную часть (в обеих ветках кода, ибо / 64.0 суть intPart + fracPart/64.0
Под вопросом деление fracPart/63.0 в _isFracture части. Может и так быть, конечно, ибо мы не знаем спецификацию входных данных, но я не вижу смысла в таком представлении данных (получается, что целые значения в таком варианте представлены двумя различными вариантами с 0 и 63 в fracPart, и это еще и приводит к уменьшению разрешения представимых данных)
Чую, что что-то не так и с negativeSign. Опять же, без спецификации не понятно, но сочетание ~ и - меня сильно смущает (с учетом того, что такое binary complement), и отдельные танцы с бубнами с fracPart. Я бы в такой функции обязательно оставил комментарий о том, как именно выглядят исходные данные, чтобы можно было разобраться потом.
EDIT: заморочился нашел документацию на FreeD. Видимо, это парсинг вот этого:
"The value is expressed in millimetres as a 24-bit twos-complement signed number, where the most-significant bit (bit 23) is the sign bit, the next 17 bits (bits 22 to 6) are the integer part and the remaining bits (bits 5 to 0) are the fractional part; alternatively, this may be thought of as a signed integer value in units of 1/64 mm. The range of values is from -131,072.0 mm (800000 hex) to nearly +131,072.0 mm (7FFFFF hex)"
То есть авто заморочился и написал оба подхода к решению одной и той же задачи и обе ветки кода должны всегда возвращать одинаковый результат. По факту - в ветке с fracPart - баг с делением на 63 (привносится небольшая ошибка на практически всех значениях) и случайно правильный результат на отрицательных значениях (из серии "ответ правильный, а решение нет"), а в "целочисленной" ветке - ошибка на 1/64 мм на всей отрицательной половине входных значений, включая даже и 0x800000 из документации.
Автомобиль - источник повышенной опасности. Оставим за скобкой злоумышленников - они при желании все равно угонят тачку, пусть она и заперта. А вот пьяная шпана, просто проходящая мимо, может воспринять открытую машину как приглашение покататься - и покататься с "кегельбаном" как результат.
Проведите параллель не в сторону полуголых девиц, а в сторону забытого в кафешке огнестрельного оружия. Логика та же.
Я подозреваю, что даже несильный обдув газом рабочей области приведет к красивому разлетанию металлической пыли из этой области во все стороны.
Именно про танки (WoT) я не в курсе, я больше warthunder предпочитаю; там скорее сама компания угробит свою игру, чем читы (меня вымораживает регулярно случающийся дикий дизбаланс команд, когда буквально за полминуты, с первого соприкосновения, полкоманды сливается в нули и все, проигрыш обеспечен). Одиночный читер в таких играх имхо меньше проблем может натворить, чем в шутерах.
Но про то, что заморачиваться не будут - не верю. Ребята из Escape from Tarkov в своем античите блокировали Hyper-V, потому что были читы, которые в отдельной виртуалке что-то там химичили с сетевым обменом между игрой и сервером - так любители заводили отдельный компьютер для MitM! Если будет спрос на читы - найдутся замороты, которые обучат сетку на предмет помощи игроку, и найдутся умники, которые это все обернут в красивую конфетку, которую одним кликом можно запустить и наслаждаться.
Читы всегда будут. Просто перехватом вызовов D3D, не трогая приложения вообще, можно натворить немало дел. Убрать траву/дым, подсветить цели (в том числе сквозь препятствия), дать оценку по дальности/скорости/упреждению и т.п.
Даже если сам рендеринг выгрузить на сервер в стиле GeForce NOW, то все равно найдутся любители пообучать нейросеточки на предмет убрать ненужное и дорисовать нужное.
В целом поддерживаю посыл, но в данном конкретном случае это был не "одноразовый баг", а тотальный блокер. Нельзя поставлять потребителю СХД, которая под нагрузкой по нескольку раз в час вешает хост-системе операцию I/O на 10 секунд. Это будет обнаружено заказчиком, прослежено до СХД и заказчик сразу выкатит претензию (и вообще любой нормальный заказчик, получив неизвестную ему модель СХД, сначала проведет те же нагрузочные тесты, чтобы понять, какую нагрузку туда можно давать в продакшне и на что рассчитывать - и сразу же наткнется на эти выбросы).
Обман в том, что искусственно повышается процент локализации. Они могут, например, налепить на плату не 1, а 99 российских чипов, которые будут друг другу по SPI данные гонять. И 1 чип Realtek, который будет делать собственно полезную работу. И честно заявить, что у них 99% чипов - российские.
Если надо работать чисто с шиной PCI, как у автора, то поможет и виртуалка (там виртуальная шина PCI ничем не хуже, чем настоящая), и, например, qemu. Если надо отладить драйвер работы с простым устройством, то можно взять qemu и туда добавить стаб-версию этого устройства (что может быть полезно само по себе для вещей типа автотестов). Если надо работать с реальным железом, то конечно лучше отдельный подопытный комп, независимо от того, есть там DMA, проецируемая память, прерывания или нет.
В 2023 году жить с процессором без поддержки SSE2 довольно грустно (это значит Vista или XP, старинные браузеры, и тд и тп). Но я могу себе представить кого-то, кто сидит на Athlon XP 20-летней давности.
В 2023 жить с процессором без поддержки SSE - это мазохизм (для понимания - это Pentium II или более старые процессоры). Я думаю, что разработчик игрушки в 2023 может спокойно позволить себе пренебречь этим сегментом рынка.
Именно. Все 64-битные процессоры имеют как минимум поддержку SSE2, и для FP вычислений используются "нормальные" регистры FP и нормальные команды SSE, а не стековая машина и сопроцессор x87.
В связи с этим мне непонятно, почему автор посчитал нормальным решением покалечить собственный код volatile-ами (и надеяться, что это единственное такое место и что он или кто-то другой потом вспомнит об этой баге, когда будет делать еще какое-нибудь такое сравнение), вместо того, чтобы просто добавить один флажок компилятору и компилировать 32-битную версию с использованием SSE вместо x87.
Адекватном виде? В нижнем меню "Топ", "Нижний", "Оставил", "Правильно". Такое вот управление курсором, "Топ и два раза оставь".
А что по этому поводу думают производители "профессиональных" DRO для всяких станков? Наверняка они все дружной толпой уже обеими ногами в 21 веке и у них у всех в качестве решения предлагаются суть iPadы? Или все же в почете все еще физические кнопки?
Поинтересуйтесь на досуге.
за тюрьму - платят (см. pay-to-stay)
Все так, но им надо было держать семплы при -80 С в течение 20+ лет, и от этого зависит какое-то супер-пупер-прорывное достижение. Притом потеря электропитания на несколько часов полностью размораживает холодильник.
Если им так важны эти образцы, то, наверное, MTTF у холодильника в районе 100 лет (то, что холодильник вышел в абнормальный режим работы, намекает, что это не так), бесперебойность электричества обеспечена на уровне 99.9999% и тд и тп. Это же не так... Что бы они делали, если бы холодильник не запищал, а тупо помер?
Ну почему же? Сompound literals, array designators и отдельные препроцессорные извращения (в частности, описанное в статье - вариация широко известного паттерна X-macro) убийственно полезны в отдельных случаях, сокращая копипасту и улучшая читабельность кода.