Комментарии 13
Спасибо за статью! Тема очень интересная. Я какое-то время назад разбирался с программированием гибридных ЦП/ЦСП OMAP3 от TI. Там тоже загрузчику Linux указывают зарезервированные под DSP/BIOS операционку области памяти.
Не увидел в Вашей статье описание межпроцессорного взаимодействия. Как передавать сообщения туда-обратно? Можете про это поподробнее рассказать?
Не увидел в Вашей статье описание межпроцессорного взаимодействия. Как передавать сообщения туда-обратно? Можете про это поподробнее рассказать?
Я вот утверждаю, что запросто можно на 64-битном многоядерном процессоре в 64-битной ОС запускать программы в режиме virtual 8086. Ну очевидно же, вот у нас например четыре ядра, три из них — в long mode, а одно — в 32bit protected mode, в котором выполняется v86-код.
Короче, вполне реально, а то, что MS выпилили из 64-битной винды поддержку совместимости с 16-битными приложениями — это может быть вопрос экономической целесообразности или их лени, но никак не невозможности реализации.
Короче, вполне реально, а то, что MS выпилили из 64-битной винды поддержку совместимости с 16-битными приложениями — это может быть вопрос экономической целесообразности или их лени, но никак не невозможности реализации.
Я не могу сказать про x86, т.к. сама идея ОСРВ под x86 мне не очень понятна… Но под ARM давно работает вот такая связка: паравиртуализованный Линукс, как процесс ОСРВ Iguana L4.
Iguana L4 идет как ядро ОС, pistachios — userspace для процессов L4. Wombat идет как набор патчей линукса для запуска ядра. Если я ничего не попутал, потому как очень давно работал с этим проектом.
Пользователь линукс со своей стороны разницы не видит, только имеет дополнительный набор драйверов для общения с L4.
К сожалению, со смертью автора проект заглох. Как минимум, опенсорсная его часть. Именно на форке iguana OS построены смартфоны от quallcomm.
Другое увы, что iguana плохо документирована и также плохо портируется — достаточно большая часть кода написана на ассемблере.
Iguana L4 идет как ядро ОС, pistachios — userspace для процессов L4. Wombat идет как набор патчей линукса для запуска ядра. Если я ничего не попутал, потому как очень давно работал с этим проектом.
Пользователь линукс со своей стороны разницы не видит, только имеет дополнительный набор драйверов для общения с L4.
К сожалению, со смертью автора проект заглох. Как минимум, опенсорсная его часть. Именно на форке iguana OS построены смартфоны от quallcomm.
Другое увы, что iguana плохо документирована и также плохо портируется — достаточно большая часть кода написана на ассемблере.
Да, на ARM я тоже видел такую связку, только с threadX.
Если реализации новых ARM будут догонять x86 по производительности, им придется идти на те же самые компромиссы, которые усложняют реализацию ОСРВ на x86.
Если реализации новых ARM будут догонять x86 по производительности, им придется идти на те же самые компромиссы, которые усложняют реализацию ОСРВ на x86.
> Если реализации новых ARM будут догонять x86 по производительности, им придется идти на те же самые компромиссы, которые усложняют реализацию ОСРВ на x86.
Тут мы рискуем вступить на тропу холиваров и разругаться :)
Тут мы рискуем вступить на тропу холиваров и разругаться :)
Холивар — тоже может быть хорошим делом, если при этом стороны узнают что-то новое. Я неплохо знаю, как устроены x86 платформы, но совсем не глубоко знаю ARM. Поэтому мне было бы интересно понять, как можно решать проблемы с плохой совместимостью SMT, power management, deep OOO pipilenes, shared cache(фич, которые хорошо помогают производительности) и предсказуемость времени выполнения кода, необходимого ОСРВ.
Что касается межядерного взаимодействия, я туда особо не лез — больше на микроконтроллерах специализируюсь. В теории — с ARMv7 есть аппаратная поддержка мьютексов, есть инструкции вроде VFE — остановить ядром выполнение задач, пока не будет сигнала от другого ядра. Про кеш статья недавно на хабре пробегала.
Основная эффективность в системе команд. Это очень хорошо продуманная архитектура с очень емким ассемблером. RISC — в идеале один такт на команду (если, конечно, отбросить mem latency и кеш). Это прямая адресация памяти без всяких страниц, сегментов и смещений. Никаких портов ввода/вывода — только зарезервированные адреса памяти. Для RTOS можно использовать MPU — это быстро и защищенно. Для не реалтаймовых ОС — MMU. С помощью него же можно делать виртуализацию любой степени вложенности. Аппаратная поддержка USER/SYSTEM стеков. Реализация вложенных прерываний с минимальным сохранением контекста.
Что касается power management — это возможность подключения/отключения питания на любой блок периферии отдельно. Возможность выключение тактования ядра процессора с, практически, полным отключением питания, программирование событий на просыпание, гибкое наращивание мощности на каждую шину и блок периферии отдельно, естественно, программно.
Основная эффективность в системе команд. Это очень хорошо продуманная архитектура с очень емким ассемблером. RISC — в идеале один такт на команду (если, конечно, отбросить mem latency и кеш). Это прямая адресация памяти без всяких страниц, сегментов и смещений. Никаких портов ввода/вывода — только зарезервированные адреса памяти. Для RTOS можно использовать MPU — это быстро и защищенно. Для не реалтаймовых ОС — MMU. С помощью него же можно делать виртуализацию любой степени вложенности. Аппаратная поддержка USER/SYSTEM стеков. Реализация вложенных прерываний с минимальным сохранением контекста.
Что касается power management — это возможность подключения/отключения питания на любой блок периферии отдельно. Возможность выключение тактования ядра процессора с, практически, полным отключением питания, программирование событий на просыпание, гибкое наращивание мощности на каждую шину и блок периферии отдельно, естественно, программно.
>если, конечно, отбросить mem latency и кеш
Так и в x86 mem latency и cache — причина 90% jitter. Я согласен, что оставшиеся 10% — тоже важно, и у ARM этих проблем нет, но считать циклы инструкций на АРМ конечно гораздо удобнее, но учитывая память и кэш — примерно так же бессмысленно, как и на x86.
Порта ввода-вывода на x86 — легаси.
Так и в x86 mem latency и cache — причина 90% jitter. Я согласен, что оставшиеся 10% — тоже важно, и у ARM этих проблем нет, но считать циклы инструкций на АРМ конечно гораздо удобнее, но учитывая память и кэш — примерно так же бессмысленно, как и на x86.
Порта ввода-вывода на x86 — легаси.
Очень важная деталь: если мы говорим про идеальную изолированную от помех от чужого кода среду, то следует учитывать существование SMM, который без ведома вашей программы может отъедать произвольное количество ресурсов во благо USB-мышки и ANB.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Совместный запуск Linux и baremetal OS