Нету отдельного не-спекулятивного исполнения, оно всё спекулятивное. Посмотрите на схему. А вот флаг в кэш, теоретически, можно добавить, только он должен означать «первое использование», и при отмене операции надо выкидывать из кэша только те строки, которые были затронуты этой операцией и у которых есть этот флаг. Но и это, наверняка, не панацея.
На сколько я понимаю, корректность доступа проверяется в самом конце, на стадии retirement. И это имеет смысл, если большая часть инструкций валидна — меньше будет тормозить пайплайн. Но это уже мои домыслы, насколько глубоко документацию на процессоры я не копал.
Нет, данных в кэше не будет. В кэше будет 1 строчка, которая соответствует байту по недоступному адресу. То есть, если по адресу 0xdeadbeef было записано 42, и мы его хотим узнать — то в результате этой атаки в кэше будет строка, которая соответствует индексу 42*4096 в массиве.
Механизм атаки spectre я сам ещё не на столько хорошо понял, чтобы статью писать.
Точнее, про отравление предсказателя переходов понятно, а вот с его эксплуатацией для повышения привелегий — пока не до конца разобрался.
В оригинальной статье про meltdown утверждается следующее:
However, for both ARM and AMD, the toy
example as described in Section 3 works reliably, indicating
that out-of-order execution generally occurs and
instructions past illegal memory accesses are also performed.
Как уже заметили выше, выгорание -оно из-за горения. А горят программисты потому, что не могут выключиться из работы. Когда ты переходишь со стадии "набирать код" в стадию программирования, то для создания программы или поиска бага код уже не так сильно нужен. И вечером, когда закрываешь ноутбук на работе, это не означает конец работы, в отличие от слесаря, например. И ты продолжаешь думать, как завтра ты поменяешь код, или почему же еще может случаться вот эта фигня.
И все это очень сильно усугубляется тем, что у многих разработчиков и хобби тоже писать код, ну или там ардуинки всякие. А надо бы регулярно заниматься такой деятельностью, при которой работает та часть мозга, которая отвечает за реальный мир, за движение, желательно на свежем воздухе, и тоже требует концентрации. Танцы, горные лыжи/сноуборд (но чтоб не на автомате ехать), да почти любой спорт на результат. Отлично заставляет мозги отключиться от программирования.
А если вдруг есть проблема с тем, что некуда девать деньги — автоспорт ждет вас, там можно разумно потратить любое количество денег :)
Возможно, это слова из древности, или из гэльского/ирландского/etc языков. Вот отличный ролик про ирландские имена: www.youtube.com/watch?v=Hwstj9FJHGg.
Но по СНС вы измеряете путевую скорость, а реакция на отклонение управляющих поверхностей зависит от воздушной скорости. На моделях вашего масштаба это очень заметно, ведь они легко могут лететь со скоростью в 5-10 м/с, что сравнимо со скоростью ветра.
Можете попробовать вместо гальванометров использовать bldc inrunner автомодельные моторчики, там как раз вся конструкция — это ось с цилиндрическим магнитом да 3 обмотки, соединённые в треугольник (или звезду, не принципиально). ШИМ на полюса обмоток позволит напрямую задавать положение, такая схема используется в широко используемых нынче стабилизаторах для камер.
По поводу развёртки и МК.
Я правильно понимаю, что у вас в планах 1млн измерений сделать (1024х1024)? Тогда с вашим вариантом управления будет достаточно медленно работать. Попробуйте что нибудь на ядре ARM, с DAC и ADC работать через DMA. Т.е. для каждой строки сначала задаёте положение луча по Y через DAC, затем запускаете DMA, который будет выплёвывать некий паттерн в DAC на канале X, обеспечивая линейное передвижение луча, ну или какое вам необходимо. Параллельно запускаете, опять же через DMA, считывание показаний с ADC. На компьютер данные отсылать через нативный USB интерфейс, на ходу можно ещё сжать, если вдруг поток окажется слишком толстым.
Потому что процессор "случайно" выполнил это, ведь на самом то деле исключение уже произошло и весь результат работы надо выкинуть. И он выкидывает.
Вы же, когда на код смотрите, сами видите, что исключение будет выкинуто на строке
и, с точки зрения даже ассемблерного кода, не говоря уж про С, никакой результат в tmp не попадёт.
Точнее, про отравление предсказателя переходов понятно, а вот с его эксплуатацией для повышения привелегий — пока не до конца разобрался.
Как уже заметили выше, выгорание -оно из-за горения. А горят программисты потому, что не могут выключиться из работы. Когда ты переходишь со стадии "набирать код" в стадию программирования, то для создания программы или поиска бага код уже не так сильно нужен. И вечером, когда закрываешь ноутбук на работе, это не означает конец работы, в отличие от слесаря, например. И ты продолжаешь думать, как завтра ты поменяешь код, или почему же еще может случаться вот эта фигня.
И все это очень сильно усугубляется тем, что у многих разработчиков и хобби тоже писать код, ну или там ардуинки всякие. А надо бы регулярно заниматься такой деятельностью, при которой работает та часть мозга, которая отвечает за реальный мир, за движение, желательно на свежем воздухе, и тоже требует концентрации. Танцы, горные лыжи/сноуборд (но чтоб не на автомате ехать), да почти любой спорт на результат. Отлично заставляет мозги отключиться от программирования.
А если вдруг есть проблема с тем, что некуда девать деньги — автоспорт ждет вас, там можно разумно потратить любое количество денег :)
Если посмотреть на эту фотографию, то неудивительно, что он мог покусать:
Я правильно понимаю, что у вас в планах 1млн измерений сделать (1024х1024)? Тогда с вашим вариантом управления будет достаточно медленно работать. Попробуйте что нибудь на ядре ARM, с DAC и ADC работать через DMA. Т.е. для каждой строки сначала задаёте положение луча по Y через DAC, затем запускаете DMA, который будет выплёвывать некий паттерн в DAC на канале X, обеспечивая линейное передвижение луча, ну или какое вам необходимо. Параллельно запускаете, опять же через DMA, считывание показаний с ADC. На компьютер данные отсылать через нативный USB интерфейс, на ходу можно ещё сжать, если вдруг поток окажется слишком толстым.