Теперь дальше можно рассказать о взаимодействии с прошивкой и выполнении основных операций - чтение/запись диска, ввод с клавиатуры, может работа с экраном. В общем то, что раньше обеспечивали всякие int 10h, 15h и т.д.
Да, "поведение не определено" именно стандартом, скомпилированные программы обычно ведут себя предсказуемо. Если не вмешивать ASLR, многопоточность и хотя бы гонки по данным, иначе там могут возникать неожиданные спецэффекты из-за отсутствия расставленных барьеров памяти процессора и барьеров оптимизации компилятора.
Мой коммент был больше вот к этому утверждению. И я хотел сказать, что даже без всяких нюансов, связанных с многозадачностью возможно непредсказуемое поведение.
Извините, но B (поведение) скомпилированного кода очень даже определено — архитектурой целевой платформы и средой исполнения.
Да, определено, но, беря тот же пример с залезанием за пределы массива, мы, запуская бинарь, не можем предсказать, что он выведет к примеру. В моем понимании именно это и есть неопределенное поведение (Undefined Behavior). А то, что вы говорите это как раз Unspecified Behavior. Обращаясь к примеру с порядком вычисления аргументов функции, мы на момент написания кода не можем знать каким он будет. Собирая разными компиляторами мы будем получать разный порядок. Но в уже скомпилированном бинаре порядок будет определен и сколько его не запускай, он не изменится.
Но ведь действительно никто не знает как будет себя вести код, который лезет за пределы массива. Т.к. никто не знает, что там лежит. Или я не так понимаю то, что вы хотите сказать?
Посмотрел что за asm генерится при этом. И ага получается, что пока условие i < 3 компилятор может просчитать где надо остановиться. А вот когда уже i < 4 и так далее, все ломается и компилятор не кладет в выхлоп проверку на конец цикла. Но что меня заинтересовало это то, что если проделать тоже самое с исходником на C (заменив вывод на printf("%d\n", i) конечно), то все норм. Выдается тот же варнинг, но компилятор просчитывает какое значение получится в финале после N итераций (с учетом переполнений) и сравнивает с ним.
А может кто-то объяснить, либо ткнуть носом если уже все давно объяснено, как должна реагировать релейная защита, если пакет SV потерялся (не дошел то есть по той или иной причине, помеха прошла например, пакет дропнулся ибо чексумма не совпала)? Ведь выпадает отсчет синусоиды, что должны делать алгоритмы, восстанавливать его по следующему отсчету, который дойдет?
А почему не Edit?
На его базе была сделана IDE для QBasic (ну если можно это назвать IDE))))
В свое время юзал его.
Хотя не помню что было раньше он или NC?
Мне кажется, или два примера (с pthread и с паттерном) несколько разные по сути?
В примере с pthread как уже говорили мы явно ждем завершения потока.
А что понимается под синхронизацией во втором примере? Мы просто используя барьеры гарантируем, что к моменту, когда произойдет
message = &a;
в a.x гарантированно будет 1, как-бы требуя и от компилятора и от проца, что-бы с учетом переупорядочивания это условие было соблюдено. И если каким-то чудом поток 2 в этот момент прочитает message (как сказано никакого ожидания в потоке 2 нет) и он будет не равен NULL, то гарантированно message->a будет равен 1.
Поправьте если не прав…
Недавно зарегался на www.mips.com и запросил доступ к MIPSfpga Getting Started Guide v2.0. Недели две назад. Ни ответа ни привета. На почту ничего не пришло, а повторно отправить запрос нельзя ибо там пишут типа ждите в течении трех дней. А уже две недели прошли. В общем непонятно.
Но думаю не закрыли, ибо позволяют запросить доступ-то
Ага, а еще пики бывало проще достать, чем авр-ки. Если не в Москве, выбирать не приходилось. Начал где-то в середине нулевых. Наслушался про AVR, прихожу в магаз говорю ATmega есть — неа, ATtiny есть — неа, а что есть — а вот PIC16F628. ну я такой — давайте чо уж) С тех пор почти нет опыта с AVR. С пиков перешел на АРМы
Скажите, а есть что-то подобное этому циклу лекций в текстовой форме? У меня всегда очень плохо заходили видео уроки. А тут неплохо как я вижу все это изложено.
Насчет контролируется или нет не отвечу, но когда мне нужно было проводить приемо-сдаточные испытания и отдавать протоколы на подпись представителю заказчика (военная приемка), там нужно было писать какие приборы использовал и даты поверки/аттестации
А меня все свербит вопрос, а почему была необходимость использовать Си для работы с этим мк? Я конечно давненько с ним дело имел, году так в 2008-2009, тогда CC7A был убог до невозможности. Генерировал какой-то дикий говномашинный код и ругался на вполне себе сишные выражения. Выбешивало какое-то нелогичное расположение переменных и постоянное переключение банков, что убивало и так небольшую производительность. В общем на тот момент пришло понимание, что с ним каши не сваришь.
Особенно он не любил умножение 16x16. Это треш вообще был. В результате проект было решено делать на асме.
Интересно, как сейчас ситуация?
Если из protected mode то да, только через v8086. Я поэтому в свое время остановился на этом.
А вот насчет efi не помню, там приложения, которые запускаются, они в каком режиме? Protected или реальном?
Круто! Начало положено.
Теперь дальше можно рассказать о взаимодействии с прошивкой и выполнении основных операций - чтение/запись диска, ввод с клавиатуры, может работа с экраном. В общем то, что раньше обеспечивали всякие int 10h, 15h и т.д.
Набрел на проксю недавно, для установки qt с официальных репозиториев
https://quterussia.ru/download/
Может пригодится
Мой коммент был больше вот к этому утверждению. И я хотел сказать, что даже без всяких нюансов, связанных с многозадачностью возможно непредсказуемое поведение.
Да, определено, но, беря тот же пример с залезанием за пределы массива, мы, запуская бинарь, не можем предсказать, что он выведет к примеру. В моем понимании именно это и есть неопределенное поведение (Undefined Behavior).
А то, что вы говорите это как раз Unspecified Behavior.
Обращаясь к примеру с порядком вычисления аргументов функции, мы на момент написания кода не можем знать каким он будет. Собирая разными компиляторами мы будем получать разный порядок. Но в уже скомпилированном бинаре порядок будет определен и сколько его не запускай, он не изменится.
Но ведь действительно никто не знает как будет себя вести код, который лезет за пределы массива. Т.к. никто не знает, что там лежит. Или я не так понимаю то, что вы хотите сказать?
Посмотрел что за asm генерится при этом. И ага получается, что пока условие i < 3 компилятор может просчитать где надо остановиться. А вот когда уже i < 4 и так далее, все ломается и компилятор не кладет в выхлоп проверку на конец цикла.
Но что меня заинтересовало это то, что если проделать тоже самое с исходником на C (заменив вывод на printf("%d\n", i) конечно), то все норм. Выдается тот же варнинг, но компилятор просчитывает какое значение получится в финале после N итераций (с учетом переполнений) и сравнивает с ним.
Ошибочка в коде
Надо
А может кто-то объяснить, либо ткнуть носом если уже все давно объяснено, как должна реагировать релейная защита, если пакет SV потерялся (не дошел то есть по той или иной причине, помеха прошла например, пакет дропнулся ибо чексумма не совпала)? Ведь выпадает отсчет синусоиды, что должны делать алгоритмы,
восстанавливать его по следующему отсчету, который дойдет?Ну вот собственно я и не помню, появился он раньше NC или нет. Если раньше, тогда смысл был, если позже, тогда я с вами согласен полностью.
На его базе была сделана IDE для QBasic (ну если можно это назвать IDE))))
В свое время юзал его.
Хотя не помню что было раньше он или NC?
В примере с pthread как уже говорили мы явно ждем завершения потока.
А что понимается под синхронизацией во втором примере? Мы просто используя барьеры гарантируем, что к моменту, когда произойдет
в a.x гарантированно будет 1, как-бы требуя и от компилятора и от проца, что-бы с учетом переупорядочивания это условие было соблюдено. И если каким-то чудом поток 2 в этот момент прочитает message (как сказано никакого ожидания в потоке 2 нет) и он будет не равен NULL, то гарантированно message->a будет равен 1.
Поправьте если не прав…
Но думаю не закрыли, ибо позволяют запросить доступ-то
Соберу их в кучку:
Предлагаю в этой ветке собрать еще ссылок на такие же крупные рекоммендации, которые вам известны
Который просто на весь файл распространяется.
Особенно он не любил умножение 16x16. Это треш вообще был. В результате проект было решено делать на асме.
Интересно, как сейчас ситуация?