Ну так это и раньше было понятно, и не только для открытого мира. Первый Half Life был крут не столько графонием и экшонием, сколько интересным сюжетом и вообще игровым миром, в т.ч. в вещах, остававшихся где-то за кадром и лишь подразумеваемых по ходу действия, -- т.е., по сути, не "шутерной", а "литературной" частью.
Не из-за этого. У Линуха (как и у многих Унихов) сильно хуже родной API ядра (в частности, нет асинхронного ввода-вывода и потоков; вместо последних -- костыли с отображением нескольких процессов на общую память; в стандарте POSIX предусмотрено и то, и другое, но Линух ни разу этому стандарту не следует). Что ещё важней, у Линуха постоянно ломают внутренние механизмы ядра, из-за чего драйверы от старых версий не годятся для новых -- а переписывать старые, естественно, никто не спешит. Из-за этого, в частности, под всякое древнее встраиваемое железо зачастую используют жутко древние версии линуховых ядер: обновиться невозможно из-за необходимости переписывать чуть ли не все драйверы.
В Винде, за исключением видеодрайверов (чья драйверная модель была полностью переделана при переходе на Висту), совместимость сохраняется, поэтому корректно написанный драйвер для Вин2000 можно перетранслировать и использовать в современной Винде. (Правда, не все они корректно написаны, но это уже второй вопрос: сама система совместимость на очень неплохом уровне сохраняет).
Ну, у меня символы не запаздывают. Правда, всякие автодополнения, автозакрытия скобок и т.д. и т.п. у меня выключены: я терпеть не могу, когда среда разработки что-то делает за меня.
А ещё влияние архитектуры. В частности, декодировать команды ARM многократно проще, чем AMD64/Intel64, из-за чего соответствующие железные блоки при прочих равных будут существенно компактнее, а значит, и жрать намного меньше. (Вот потребление и размеры кэшей или там АЛУ от архитектуры уже практически не зависит).
Точней, не кладут, не реализуют зачастую весьма и весьма криво, а это влечёт за собой всякие разные проблемы.
Вообще, списки ошибок в железе (так называемые Errata) для сложных микросхем могут содержать сотни страниц; про программные ошибки и говорить нечего -- там зачастую ещё хуже (правда, в отличие от "железных" ошибок, их можно, хотя бы в теории, исправить перепрошивкой BIOS или его аналога на конкретной платформе). Так что Эпл, имея дело с крайне ограниченным кругом железа, находится в заведомо выигрышной позиции по сравнению с Линухом или Виндой -- что, естественно, не отменяет того факта, что означенные системы написаны далеко не так хорошо, как хотелось бы.
Во-первых, архитектура не меняется уже порядка 20 лет -- и называется AMD64/Intel 64; меняются же микроархитектуры.
А во-вторых, i9 -- топовые процы, а прирост производительности на одно ядро стагнирует примерно те же самые 20 лет (грубо говоря, мощнейшее ядро 2025-го года не факт что будет хотя бы вдвое производительней на "коде общего назначения" по сравнению с мощнейшим ядром 2005 года; вот на специальных задачах с помощью новых команд -- это да). Так что даже на старом i9 всё должно работать быстро, а вот на новейшем i3 -- очччень не факт.
Только фотку уместнее Дэвида Катлера, который наиболее известен как архитектор Win NT, но и до этого разработал несколько систем. В частности, RSX-11, которая была многозадачной многопользовательской, но под себя жрала меньше 100 Кбайт памяти, включая драйверы (т.е. реально меньше, чем абсолютно убогая МС ДОС).
С поддержкой собственно достаточно нового стандарта (C++20, если в данном случае) со стороны компилятора проблем нет -- это ж Clang, подпиленный ARMом (вероятно, путём прицепления проверки лицензии -- вряд ли они что серьёзное меняли). Вот со стороны отладчика, а это уже ARM (Keil) -- там да. Судя по всему, он не способен корректно интерпретировать новую отладочную инфу, причём до такой степени, что теряет способность адекватно воспринимать и "классическую" (не может, например, правильно сопоставлять номера строк С++ с адресами кода).
Ну а переносимость сейчас... не особо важна, так скажем. Почти везде компилятор -- либо GCC, либо Clang, а они вполне себе следуют новым стандартам. Поэтому использовать стандартные фишки пятилетней давности, как по мне, уже вполне себе можно, если говорить именно о переносимости, а не о качестве поддержки дополнительными инструментами, а не собственно компилятором.
Да. Полностью асинхронный (а не чисто синхронный, как FatFs -- собсно, потому и написал свой). Причём использовал сопрограммы C++20 -- собсно, потренировался на кошечках :) Правда, сейчас перепишу на обычные процедуры обратного вызова, поскольку Кейловскому отладчику наличие сопрограмм начисто срывает крышу -- отлаживать можно только на уровне дизассемблера, причём не только сами сопрограммы, но и код более высокого уровня.
А я вот никогда не использую "HAL от вендора" -- у меня самописное всё, от GPIO до USB. Ну, это если про нижний уровень, работающий прямо с железом, говорить. На среднем уже возможны варианты (скажем, использую LVGL, а если потребуется прикрутить сеть, возьму lwIP).
На 1035 (а она микроархитектурно содрана с 370/145) была индикация одиночных ошибок ОП или УП (там контроль и коррекция по Хэммингу). Вот она на моей памяти сбоила довольно часто. В то же время на 1130 не помню, чтоб были сбои проца/памяти, так что, если они и возникали, то реально редко.
Будут работать и штатные IBMовские системы, если их сгенерировать под модель, где не вставляется ДИАГНОСТИКА. "У них" она, например, использовалась в модели 85 (как раз ща ковыряю исходники OS/360 21.8, ну и узрел сие в диспетчере -- а там это какой-то костыль для RMS), у нас -- для ЕС-1045. Но диагностикой включают/выключают всякие дополнительные фишки, без которых машина может нормально работать.
Хоть на ПЛИС, хоть на микроконтроллерах :) Скорости там такие, что какая-нить там STM32 на 100+ МГц вполне чисто программно будет успевать прикидываться любой периферией.
А если её ещё и завести удастся... Правда, подозреваю, без создания эмуляторов дисков обойтись не удастся: найти кучу исправных пакетов, кучу запасных деталей (прежде всего головок) для приводов, а ещё и спецов, которые смогут их привести к годное для использования состояние...
А я сделал асинхронный ввод-вывод на микроконтроллерах без всяких задач и т.д. -- на голом железе, в общем. Но делал больше для того, чтоб самому разобраться, как оно работает и с чем его едят. Для практического использования в KEIL, как я тут выше упоминал, сопрограммы не годятся из-за невозможности отлаживать и их, и код вокруг них штатными средствами. А жаль: используя их, можно делать асинхронщину без сплошных подпрограмм обратного вызова и 100500 мелких функций.
Это основная среда разработки под микроконтроллеры и классические микропроцессоры (которые ARMv6 и более ранние -- до ядер серии Cortex, в общем) от ARM. У них есть ещё DS-5 на основе Эклипсы, но оно уж очень платное, громоздкое и всё такое прочее, и для микроконтроллеров смысл его использования стремится к нулю (а вот для современных микропроцессоров ARM ничего другого не предлагает -- но за бешеные деньги). Ну а главный конкурент на МК -- IAR, но он не ARMовский.
Увы, по ряду причин мне нужен именно KEIL. Но, если бы я полностью был свободен в выборе, то смотрел бы в сторону VS Code: к Эклипсе в любых её проявлениях у меня стойкая нелюбовь, скажем так. Впрочем, в данном случае это уже вторично.
А ещё сопрограммы могут быть весьма сложны при отладке. Вплоть до такой степени, что нормальная отладка не только их самих, но и окружающего кода становится невозможной: у меня такое было в KEIL. Сам компилятор (ARMCLANG) генерирует нормальный код, но у отладчика наличие сопрограмм начисто срывает крышу, из-за чего отладка возможна исключительно на уровне дизассемблированного кода. Похоже, KEIL не способен корректно интерпретировать отладочную информацию -- и вряд ли будет способен в будущем; скорей, ARM полностью переведёт разработку в VS Code, фактически свалив заботу об инструментах на "сообщество".
Ну так это и раньше было понятно, и не только для открытого мира. Первый Half Life был крут не столько графонием и экшонием, сколько интересным сюжетом и вообще игровым миром, в т.ч. в вещах, остававшихся где-то за кадром и лишь подразумеваемых по ходу действия, -- т.е., по сути, не "шутерной", а "литературной" частью.
Не из-за этого. У Линуха (как и у многих Унихов) сильно хуже родной API ядра (в частности, нет асинхронного ввода-вывода и потоков; вместо последних -- костыли с отображением нескольких процессов на общую память; в стандарте POSIX предусмотрено и то, и другое, но Линух ни разу этому стандарту не следует). Что ещё важней, у Линуха постоянно ломают внутренние механизмы ядра, из-за чего драйверы от старых версий не годятся для новых -- а переписывать старые, естественно, никто не спешит. Из-за этого, в частности, под всякое древнее встраиваемое железо зачастую используют жутко древние версии линуховых ядер: обновиться невозможно из-за необходимости переписывать чуть ли не все драйверы.
В Винде, за исключением видеодрайверов (чья драйверная модель была полностью переделана при переходе на Висту), совместимость сохраняется, поэтому корректно написанный драйвер для Вин2000 можно перетранслировать и использовать в современной Винде. (Правда, не все они корректно написаны, но это уже второй вопрос: сама система совместимость на очень неплохом уровне сохраняет).
Ну, у меня символы не запаздывают. Правда, всякие автодополнения, автозакрытия скобок и т.д. и т.п. у меня выключены: я терпеть не могу, когда среда разработки что-то делает за меня.
А ещё влияние архитектуры. В частности, декодировать команды ARM многократно проще, чем AMD64/Intel64, из-за чего соответствующие железные блоки при прочих равных будут существенно компактнее, а значит, и жрать намного меньше. (Вот потребление и размеры кэшей или там АЛУ от архитектуры уже практически не зависит).
Точней, не кладут, не реализуют зачастую весьма и весьма криво, а это влечёт за собой всякие разные проблемы.
Вообще, списки ошибок в железе (так называемые Errata) для сложных микросхем могут содержать сотни страниц; про программные ошибки и говорить нечего -- там зачастую ещё хуже (правда, в отличие от "железных" ошибок, их можно, хотя бы в теории, исправить перепрошивкой BIOS или его аналога на конкретной платформе). Так что Эпл, имея дело с крайне ограниченным кругом железа, находится в заведомо выигрышной позиции по сравнению с Линухом или Виндой -- что, естественно, не отменяет того факта, что означенные системы написаны далеко не так хорошо, как хотелось бы.
Во-первых, архитектура не меняется уже порядка 20 лет -- и называется AMD64/Intel 64; меняются же микроархитектуры.
А во-вторых, i9 -- топовые процы, а прирост производительности на одно ядро стагнирует примерно те же самые 20 лет (грубо говоря, мощнейшее ядро 2025-го года не факт что будет хотя бы вдвое производительней на "коде общего назначения" по сравнению с мощнейшим ядром 2005 года; вот на специальных задачах с помощью новых команд -- это да). Так что даже на старом i9 всё должно работать быстро, а вот на новейшем i3 -- очччень не факт.
Только фотку уместнее Дэвида Катлера, который наиболее известен как архитектор Win NT, но и до этого разработал несколько систем. В частности, RSX-11, которая была многозадачной многопользовательской, но под себя жрала меньше 100 Кбайт памяти, включая драйверы (т.е. реально меньше, чем абсолютно убогая МС ДОС).
С поддержкой собственно достаточно нового стандарта (C++20, если в данном случае) со стороны компилятора проблем нет -- это ж Clang, подпиленный ARMом (вероятно, путём прицепления проверки лицензии -- вряд ли они что серьёзное меняли). Вот со стороны отладчика, а это уже ARM (Keil) -- там да. Судя по всему, он не способен корректно интерпретировать новую отладочную инфу, причём до такой степени, что теряет способность адекватно воспринимать и "классическую" (не может, например, правильно сопоставлять номера строк С++ с адресами кода).
Ну а переносимость сейчас... не особо важна, так скажем. Почти везде компилятор -- либо GCC, либо Clang, а они вполне себе следуют новым стандартам. Поэтому использовать стандартные фишки пятилетней давности, как по мне, уже вполне себе можно, если говорить именно о переносимости, а не о качестве поддержки дополнительными инструментами, а не собственно компилятором.
Да. Полностью асинхронный (а не чисто синхронный, как FatFs -- собсно, потому и написал свой). Причём использовал сопрограммы C++20 -- собсно, потренировался на кошечках :) Правда, сейчас перепишу на обычные процедуры обратного вызова, поскольку Кейловскому отладчику наличие сопрограмм начисто срывает крышу -- отлаживать можно только на уровне дизассемблера, причём не только сами сопрограммы, но и код более высокого уровня.
А я вот никогда не использую "HAL от вендора" -- у меня самописное всё, от GPIO до USB. Ну, это если про нижний уровень, работающий прямо с железом, говорить. На среднем уже возможны варианты (скажем, использую LVGL, а если потребуется прикрутить сеть, возьму lwIP).
На 1035 (а она микроархитектурно содрана с 370/145) была индикация одиночных ошибок ОП или УП (там контроль и коррекция по Хэммингу). Вот она на моей памяти сбоила довольно часто. В то же время на 1130 не помню, чтоб были сбои проца/памяти, так что, если они и возникали, то реально редко.
К чему вернусь, как только покончу полуреплику проца от СМ-1420 :)
Дык далеко не все машины сбоили нещадно, так что тут как повезёт :)
Будут работать и штатные IBMовские системы, если их сгенерировать под модель, где не вставляется ДИАГНОСТИКА. "У них" она, например, использовалась в модели 85 (как раз ща ковыряю исходники OS/360 21.8, ну и узрел сие в диспетчере -- а там это какой-то костыль для RMS), у нас -- для ЕС-1045. Но диагностикой включают/выключают всякие дополнительные фишки, без которых машина может нормально работать.
Хоть на ПЛИС, хоть на микроконтроллерах :) Скорости там такие, что какая-нить там STM32 на 100+ МГц вполне чисто программно будет успевать прикидываться любой периферией.
А если её ещё и завести удастся... Правда, подозреваю, без создания эмуляторов дисков обойтись не удастся: найти кучу исправных пакетов, кучу запасных деталей (прежде всего головок) для приводов, а ещё и спецов, которые смогут их привести к годное для использования состояние...
А я сделал асинхронный ввод-вывод на микроконтроллерах без всяких задач и т.д. -- на голом железе, в общем. Но делал больше для того, чтоб самому разобраться, как оно работает и с чем его едят. Для практического использования в KEIL, как я тут выше упоминал, сопрограммы не годятся из-за невозможности отлаживать и их, и код вокруг них штатными средствами. А жаль: используя их, можно делать асинхронщину без сплошных подпрограмм обратного вызова и 100500 мелких функций.
Это основная среда разработки под микроконтроллеры и классические микропроцессоры (которые ARMv6 и более ранние -- до ядер серии Cortex, в общем) от ARM. У них есть ещё DS-5 на основе Эклипсы, но оно уж очень платное, громоздкое и всё такое прочее, и для микроконтроллеров смысл его использования стремится к нулю (а вот для современных микропроцессоров ARM ничего другого не предлагает -- но за бешеные деньги). Ну а главный конкурент на МК -- IAR, но он не ARMовский.
Увы, по ряду причин мне нужен именно KEIL. Но, если бы я полностью был свободен в выборе, то смотрел бы в сторону VS Code: к Эклипсе в любых её проявлениях у меня стойкая нелюбовь, скажем так. Впрочем, в данном случае это уже вторично.
А ещё сопрограммы могут быть весьма сложны при отладке. Вплоть до такой степени, что нормальная отладка не только их самих, но и окружающего кода становится невозможной: у меня такое было в KEIL. Сам компилятор (ARMCLANG) генерирует нормальный код, но у отладчика наличие сопрограмм начисто срывает крышу, из-за чего отладка возможна исключительно на уровне дизассемблированного кода. Похоже, KEIL не способен корректно интерпретировать отладочную информацию -- и вряд ли будет способен в будущем; скорей, ARM полностью переведёт разработку в VS Code, фактически свалив заботу об инструментах на "сообщество".