Можно писать безопасный код на чём угодно, и небезопасный тоже можно на чём угодно написать. Вопрос лишь в том, насколько просто или сложно это сделать на том или ином языке.
В некоторых случаях не нужна, да. Скажем, массив (в частности, вектор) может хранить, например, указатели на какие-то структуры, которые формирует один поток, а обрабатывает другой. Для выборки и изменения отдельного элемента массива, т.е. одного указателя, достаточно атомарной операции сравнения с обменом или чего-то подобного без какой-либо явной межпоточной синхронизации. Но, понятно, такой номер проходит, если обработка поэлементная, не требующая блокировки всего вектора.
Ну, полноценных шахмат на МК-61 не было и быть не могло. Кажется, сделали эндшпиль, когда на доске по паре-тройке фигур, но за давностью лет не помню. А вообще, шахматные программы достаточно давно появились, см, например, https://ru.wikipedia.org/wiki/Каисса_(программа)
Потенциально долгая вставка элемента -- всегда, а не только при превышении вместимости. Просто превышение вместимости в обязательном порядке требует нового выделения памяти и копирования в неё всего старого содержимого вектора вкупе со вставляемым элементом, в то время как просто вставка может быть и "мгновенной" (если новый элемент будет последним в векторе) -- хотя может быть и долгой, вплоть до полного копирования всех элементов, но без перераспределения памяти. Поэтому само по себе выделение сразу всего требуемого объёма памяти не гарантирует быстрой вставки -- оно лишь гарантирует, что память не придётся выделять повторно.
Ну а с ОС и кэшами и другие проблемы могут быть -- зависит от особенностей работы ОС (в мире не только Винда с Линухом существуют) и архитектуры процессора.
Вот в таких задачах ручное программирование на ассемблере (ну или использование специфичных для конкретного компилятора и архитектуры расширений языка, сводящихся к ассемблеру) и даёт иногда колоссальный прирост производительности. Конечно, ценой непереносимости кода, но всегда ли она нужна, не говоря о том, что ничто не мешает предлагать как переносимую реализацию, так и специфичные для конкретных платформ?
Вообще-то, UE5 -- прямое продолжение UE4, и 95% кода у них идентичны. Номер версии UE меняют больше из маркетинговых, а не технических соображений, и между UE 4.1 и 4.26 разницы куда больше, чем между 4.26 и 5.0.
Ну и русский язык стоит подтянуть. "Не желе" -- это в каком смысле, "не желе, а холодец"?
Драйвер -- это, вообще говоря, либо простая железяка, которая "качает" другую железяку (скажем, драйвер двигателя), либо программа, реализующая логику управления чем-либо. Здесь, думается, корректней было бы говорить о контроллере семисегментника и т.д., а не о драйвере. Но это так, придирки :)
Судя по приведённым картинкам, речь про какой-то ATSAMx7? Если так, то использовать SDRAM, по сути, невозможно: контроллер столь забагован, что его официально признали непригодным:
Ну и вообще, перед серьёзным использованием всегда надо Еррату смотреть. Правда, для новейших МК это не всегда помогает. Скажем, мой коллега стал в своё время, по сути, "автором" половины Ерраты для STM32L1 -- мы использовали эти МК, как только они появились, и, естественно, натыкались на кучу ошибок.
Вы отрицаете, что старший бит целого числа, представленного в дополнительном коде, является битом знака? Вы отрицаете, что нулевое значение знакового бита соответствует знаку "плюс", а единичное -- знаку "минус"? Вы отрицаете, что число, имеющее значение 0, имеет знаковый бит, равный нулю, что означает знак "плюс"? Наконец, Вы отрицаете, что нуль как вещественное число имеет знак? И как последнее согласуется с Вашим утверждением, что "Ноль он и в Африке ноль", когда это прямо противоречит математике?
А переход -- по знаку "плюс" (BPL), и нуль рассматривается как имеющий знак "плюс". Неотрицательное не значит положительное только в математике -- напоминаю про существование положительного и отрицательного нуля в вещественных числах. Ну и в целых числах знаковый бит тоже есть, и он сброшен ("плюс") для нулевого значения числа.
А, например, в PDP-11 и ARM этот бит называется N (понятное дело, от negative), а для обозначения условия перехода используется сочетание PL -- от plus, естественно:
Как видите, в этом отрывке (из описания архитектуры ARMv7-M) специально подчёркивается, что "плюс" -- это положительное число или нуль, а не только "настоящее" положительное число.
В общем, компьютерный мир намного шире, чем Ваше (и моё, да) представление о нём, и абстрактно-математическим концепциям он иногда не соответствует.
В MIPS, кажется, тоже. А в IBM System/360 система переходов другая, поэтому там целочисленного знакового нуля, с точки зрения программиста, тоже нет: там ещё не четыре традиционных флажка, а двухбитовый код условия, правила установки которого зависят от типа выполняющейся команды. Поэтому тамошняя система команд имеет отдельные команды сложения-вычитания для знаковых чисел и для беззнаковых: сам результат, понятно дело, идентичен, отличается лишь установка кода условия. Но появились эти машинки ещё в середине 1960-х, у основной массы более современных -- те самые четыре флажка, что оказалось наиболее удобным для программиста.
В общем, утверждать категорически, что нуль в вычислительной технике не имеет знака, нельзя -- особенно если пишешь на ассемблере, так как там зачастую надо сей факт учитывать (скажем, анализировать на нулевой результат до того, как проверять на плюс -- естественно, где система команд это предусматривает). Плюс, как уже говорил, у вещественных нуль имеет знак -- в определённых ситуациях тоже может добавить проблем, если это игнорировать (хотя там куда чаще имеют проблемы из-за ограниченной точности и правил округления: складывают, скажем, два числа, а результат остаётся таким же, как большее по абсолютной величине из этих чисел).
И, кстати, если уж касаться "усложнения разработки процессоров", то неплохо было бы спуститься на уровень схемотехники и показать, чем так хорош дополнительный код (а он действительно хорош, иначе б его не использовали). Правда, сразу возникает вопрос: а почему в вещественных числах используют прямой код (и имеют положительный и отрицательный нули)? В общем, улучшать есть куда.
Потому что с результатом операции (в том числе сравнения или проверки значения) связаны, как правило, четыре пары атрибутов: нуль/не нуль, плюс/минус, перенос/нет переноса, переполнение/нет переполнения. Скажем, если сравниваются два одинаковых числа, будут получены признаки "нуль" (он же равно: сравнение выполняется путём вычитания, только результат собственно вычитания теряется, остаются лишь признаки результата) и "плюс" (поскольку старший бит результата равен нулю). Если сразу после сравнения выполнить команду "переход, если результат положительный", переход произойдёт -- т.е. равенство (нулевой результат вычитания) будет воспринято как положительное число. Это хорошо видно, если писать на ассемблере (см., например, регистр флагов в архитектуре IA-32, она же x86, или регистр состояния процессора в архитектуре ARM).
9-й бит в каждом байте -- это именно что контрольный бит. Есть применения, где надо защищаться от возможных сбоев информации в памяти -- и там контрольные разряды необходимы. Это не обязательно контроль по чётности; скажем, если использовать слово данных шириной 64 бита, т.е. 8 байтов, имеем 8 контрольных разрядов -- и этого достаточно, чтобы реализовать код Хэмминга и иметь возможность обнаруживать любые двойные ошибки и корректировать одиночные.
Но, поскольку это ПЛИС, никто не заставляет использовать "лишние" биты для контроля. Скажем, в PicoBlaze (мелкий-мелкий проц от Хилинха) команда кодируется 18 битами, если память не изменяет -- разработчик как раз использует особенность блочной памяти, где у каждого байта предусмотрен дополнительный бит.
У нас трудовик, в частности, терпеть не мог, когда отверстия называли дырками :) Ну, как-то я так назвал, он типа наехал, а я ему говорю: мол, сами гляньте: края рваные, форма не пойми какая... (отверстие я действительно жутко кривое тогда сделал). Он подошёл, посмотрел и говорит: "Да, ты, прав, это не отверстие, это дырка" :)
Ну а насчёт оценки стиля статьи полностью согласен. Писать надо серьёзно, а не just for lulz (серьёзно -- не значит занудно).
Ну, для общего развития и для понимания того, как оно работает, неплохо уметь немного работать на голом API, без использования сторонних библиотек и т.п. Но вряд ли это оправдано для реальной разработки, конечно.
Можно писать безопасный код на чём угодно, и небезопасный тоже можно на чём угодно написать. Вопрос лишь в том, насколько просто или сложно это сделать на том или ином языке.
В некоторых случаях не нужна, да. Скажем, массив (в частности, вектор) может хранить, например, указатели на какие-то структуры, которые формирует один поток, а обрабатывает другой. Для выборки и изменения отдельного элемента массива, т.е. одного указателя, достаточно атомарной операции сравнения с обменом или чего-то подобного без какой-либо явной межпоточной синхронизации. Но, понятно, такой номер проходит, если обработка поэлементная, не требующая блокировки всего вектора.
Ну, полноценных шахмат на МК-61 не было и быть не могло. Кажется, сделали эндшпиль, когда на доске по паре-тройке фигур, но за давностью лет не помню. А вообще, шахматные программы достаточно давно появились, см, например, https://ru.wikipedia.org/wiki/Каисса_(программа)
Потенциально долгая вставка элемента -- всегда, а не только при превышении вместимости. Просто превышение вместимости в обязательном порядке требует нового выделения памяти и копирования в неё всего старого содержимого вектора вкупе со вставляемым элементом, в то время как просто вставка может быть и "мгновенной" (если новый элемент будет последним в векторе) -- хотя может быть и долгой, вплоть до полного копирования всех элементов, но без перераспределения памяти. Поэтому само по себе выделение сразу всего требуемого объёма памяти не гарантирует быстрой вставки -- оно лишь гарантирует, что память не придётся выделять повторно.
Ну а с ОС и кэшами и другие проблемы могут быть -- зависит от особенностей работы ОС (в мире не только Винда с Линухом существуют) и архитектуры процессора.
Вот в таких задачах ручное программирование на ассемблере (ну или использование специфичных для конкретного компилятора и архитектуры расширений языка, сводящихся к ассемблеру) и даёт иногда колоссальный прирост производительности. Конечно, ценой непереносимости кода, но всегда ли она нужна, не говоря о том, что ничто не мешает предлагать как переносимую реализацию, так и специфичные для конкретных платформ?
Вообще-то, UE5 -- прямое продолжение UE4, и 95% кода у них идентичны. Номер версии UE меняют больше из маркетинговых, а не технических соображений, и между UE 4.1 и 4.26 разницы куда больше, чем между 4.26 и 5.0.
Ну и русский язык стоит подтянуть. "Не желе" -- это в каком смысле, "не желе, а холодец"?
Драйвер -- это, вообще говоря, либо простая железяка, которая "качает" другую железяку (скажем, драйвер двигателя), либо программа, реализующая логику управления чем-либо. Здесь, думается, корректней было бы говорить о контроллере семисегментника и т.д., а не о драйвере. Но это так, придирки :)
Судя по приведённым картинкам, речь про какой-то ATSAMx7? Если так, то использовать SDRAM, по сути, невозможно: контроллер столь забагован, что его официально признали непригодным:
Ну и вообще, перед серьёзным использованием всегда надо Еррату смотреть. Правда, для новейших МК это не всегда помогает. Скажем, мой коллега стал в своё время, по сути, "автором" половины Ерраты для STM32L1 -- мы использовали эти МК, как только они появились, и, естественно, натыкались на кучу ошибок.
Вы отрицаете, что старший бит целого числа, представленного в дополнительном коде, является битом знака? Вы отрицаете, что нулевое значение знакового бита соответствует знаку "плюс", а единичное -- знаку "минус"? Вы отрицаете, что число, имеющее значение 0, имеет знаковый бит, равный нулю, что означает знак "плюс"? Наконец, Вы отрицаете, что нуль как вещественное число имеет знак? И как последнее согласуется с Вашим утверждением, что "Ноль он и в Африке ноль", когда это прямо противоречит математике?
А переход -- по знаку "плюс" (BPL), и нуль рассматривается как имеющий знак "плюс". Неотрицательное не значит положительное только в математике -- напоминаю про существование положительного и отрицательного нуля в вещественных числах. Ну и в целых числах знаковый бит тоже есть, и он сброшен ("плюс") для нулевого значения числа.
А, например, в PDP-11 и ARM этот бит называется N (понятное дело, от negative), а для обозначения условия перехода используется сочетание PL -- от plus, естественно:
Как видите, в этом отрывке (из описания архитектуры ARMv7-M) специально подчёркивается, что "плюс" -- это положительное число или нуль, а не только "настоящее" положительное число.
В общем, компьютерный мир намного шире, чем Ваше (и моё, да) представление о нём, и абстрактно-математическим концепциям он иногда не соответствует.
В MIPS, кажется, тоже. А в IBM System/360 система переходов другая, поэтому там целочисленного знакового нуля, с точки зрения программиста, тоже нет: там ещё не четыре традиционных флажка, а двухбитовый код условия, правила установки которого зависят от типа выполняющейся команды. Поэтому тамошняя система команд имеет отдельные команды сложения-вычитания для знаковых чисел и для беззнаковых: сам результат, понятно дело, идентичен, отличается лишь установка кода условия. Но появились эти машинки ещё в середине 1960-х, у основной массы более современных -- те самые четыре флажка, что оказалось наиболее удобным для программиста.
В общем, утверждать категорически, что нуль в вычислительной технике не имеет знака, нельзя -- особенно если пишешь на ассемблере, так как там зачастую надо сей факт учитывать (скажем, анализировать на нулевой результат до того, как проверять на плюс -- естественно, где система команд это предусматривает). Плюс, как уже говорил, у вещественных нуль имеет знак -- в определённых ситуациях тоже может добавить проблем, если это игнорировать (хотя там куда чаще имеют проблемы из-за ограниченной точности и правил округления: складывают, скажем, два числа, а результат остаётся таким же, как большее по абсолютной величине из этих чисел).
Вообще, в большинстве архитектур так, включая IA-32 (x86) и ARM. Ну а вещественный нуль вообще везде знак имеет, похоже.
И, кстати, если уж касаться "усложнения разработки процессоров", то неплохо было бы спуститься на уровень схемотехники и показать, чем так хорош дополнительный код (а он действительно хорош, иначе б его не использовали). Правда, сразу возникает вопрос: а почему в вещественных числах используют прямой код (и имеют положительный и отрицательный нули)? В общем, улучшать есть куда.
Потому что с результатом операции (в том числе сравнения или проверки значения) связаны, как правило, четыре пары атрибутов: нуль/не нуль, плюс/минус, перенос/нет переноса, переполнение/нет переполнения. Скажем, если сравниваются два одинаковых числа, будут получены признаки "нуль" (он же равно: сравнение выполняется путём вычитания, только результат собственно вычитания теряется, остаются лишь признаки результата) и "плюс" (поскольку старший бит результата равен нулю). Если сразу после сравнения выполнить команду "переход, если результат положительный", переход произойдёт -- т.е. равенство (нулевой результат вычитания) будет воспринято как положительное число. Это хорошо видно, если писать на ассемблере (см., например, регистр флагов в архитектуре IA-32, она же x86, или регистр состояния процессора в архитектуре ARM).
Не увидел, почему код называется дополнительным :)
Кроме того, нуль считается положительным числом. Это в математике у него нет знака, а в компутерах очень даже есть.
9-й бит в каждом байте -- это именно что контрольный бит. Есть применения, где надо защищаться от возможных сбоев информации в памяти -- и там контрольные разряды необходимы. Это не обязательно контроль по чётности; скажем, если использовать слово данных шириной 64 бита, т.е. 8 байтов, имеем 8 контрольных разрядов -- и этого достаточно, чтобы реализовать код Хэмминга и иметь возможность обнаруживать любые двойные ошибки и корректировать одиночные.
Но, поскольку это ПЛИС, никто не заставляет использовать "лишние" биты для контроля. Скажем, в PicoBlaze (мелкий-мелкий проц от Хилинха) команда кодируется 18 битами, если память не изменяет -- разработчик как раз использует особенность блочной памяти, где у каждого байта предусмотрен дополнительный бит.
С русским языком плохо. К счастью, с содержанием статьи всё намного лучше.
У нас трудовик, в частности, терпеть не мог, когда отверстия называли дырками :) Ну, как-то я так назвал, он типа наехал, а я ему говорю: мол, сами гляньте: края рваные, форма не пойми какая... (отверстие я действительно жутко кривое тогда сделал). Он подошёл, посмотрел и говорит: "Да, ты, прав, это не отверстие, это дырка" :)
Ну а насчёт оценки стиля статьи полностью согласен. Писать надо серьёзно, а не just for lulz (серьёзно -- не значит занудно).
Ну, для общего развития и для понимания того, как оно работает, неплохо уметь немного работать на голом API, без использования сторонних библиотек и т.п. Но вряд ли это оправдано для реальной разработки, конечно.