почему RTOS кодируется только в c?

Question

Всегда ли нужно кодировать RTOS на языке Си? Почему это не может быть закодировано в Java или какой-то другой технологии? Это из-за отсутствия концепции указателя в Java?

Answer 1

Сборка мусора - главная причина того, что Java работает в режиме реального времени. JIT - это другое, но это можно преодолеть.

В целом, C - это эффективно переносимая сборка, которая обеспечивает очень предсказуемую производительность во время выполнения, и это важно для надежного выполнения в реальном времени.

Answer 2

Системы реального времени можно программировать и на других языках. Java имеет Java RTS System , например.

Вопреки другим ответам, существует разумный объем работы по сборке мусора в реальном времени. Однако они не входят в ваши стандартные дистрибутивы.

Проблема заключается в том, что другие языки обычно имеют функции, которые затрудняют достижение детерминизма и надежности, например, традиционную сборку мусора, JIT, оптимизацию времени выполнения и т. Д.

Answer 3

Вначале ОСРВ не просто кодируются на C. Они также могут кодироваться на других языках. Однако язык, используемый для ОСРВ, должен обеспечивать детерминированное поведение. Это означает, что задержка для конкретного действия всегда должна быть меньше определенного времени. Это исключает, например, сборку мусора, которая в большинстве реализаций останавливает выполнение всех потоков на неопределенное время.

Answer 4

Поскольку разработчики ОСРВ, скорее всего, недостаточно хорошо знают С ++.

C ++ во встроенных системах: миф и реальность

Некоторые считают, что в C ++ есть издержки и расходы, которые делают это как-то не подходит для встроенных систем программирование, что ему не хватает контроля и краткость C, или что, в то время как это может подойти для какой-то ниши приложения, он никогда не заменит C как язык выбора для встраиваемых системы.

Эти представления неверны. куда компиляторы и другие инструменты адекватный, C ++ всегда предпочтительнее C как язык реализации для встроенные системы. Делая все, что делает С, предлагает большие возможности для самовыражения, инкапсуляция, повторное использование, и это даже позволяет улучшить размер и скорость непрактичные в C.

> Почему же тогда такое восприятие сохраняются? Основная причина в том, что когда люди формируют свое мнение, они знают гораздо больше о C, чем о C ++. Они прочитали несколько книг, написали некоторый код, и компетентны в использовании возможности C ++, но им не хватает знание того, что происходит под капот, знакомство, которое позволяет один для визуализации разборки во время набрав источник или даже во время формулировка дизайна.

Рекомендации по использованию C ++ в качестве альтернативы C во встроенных проектах

Встроенные программные приложения чаще всего пишутся на C. На протяжении многих лет C ++ имеет был замечен как естественный преемник и нашел большее признание, но увеличение его использование было намного медленнее, чем ожидалось.

Есть несколько причин для этого. Во-первых, встроенные разработчики довольно консервативные и предпочитают использовать решения, которые доказали, а не новые "", если это не сломайся, не чини ".

Есть также урок опыта. Многие разработчики пытались использовать C ++ для встроенные приложения и не удалось. Такие неудачи иногда могут быть отнесены к недостатки в инструментах разработки, но чаще всего это нецелевое использование язык "относящийся к встроенной системе как к настольному компьютеру", который виноват.

ограничения C Хотя C широко используется, у него есть ограничения, так как он не предназначен для встроенных приложений или для проектов такого масштаба, что сейчас является обычным явлением. Основные ограничения включают в себя:

1) C чрезвычайно мощный и гибкий и поэтому может быть опасным (имеет низкий уровень возможности - которые полезны для встроенных ", но также представляют собой много подводных камней для неосторожный.)

2) Программисты должны быть очень методичными и дисциплинированными

3) Программисты должны понимать, как программа ведет себя на низком и высоком уровнях (большой проекты, таким образом, трудно поддерживать)

4) Программистам необходимы экспертные знания по приложению

Однако C ++ обладает мощными объектно-ориентированными возможностями, которые могут значительно помочь в устранение ограничений C:

1) он заключает в капсулу и скрывает области высокого опыта от неспециалистов в «объекты»; (A Тестовый пример продемонстрирует инкапсуляцию опыта позже в части 2 в этом серия).

2) Объекты могут интуитивно использоваться неспециалистами для реализации концептуальных проектов на высокий уровень

Answer 5

Не "необходимо", но гораздо более практично

В качестве языка может использоваться Java, и существуют различные причудливые случаи, когда это действительно происходит.

Но несколько крайних случаев и демонстраций действительно "исключение (я), которые подтверждают правило" .

В целом, Java - это большая сложная система, предназначенная для бизнес-логики, а не для ядер ОС.

Если бы у нас еще не было C , Java мог бы развиваться в другом направлении или в нескольких направлениях.

Но у нас есть C, который почти идеально подходит для ядра ОС и довольно сложен для бизнес-логики.

Аргументы в пользу того, что Java так же хороша, как C для ядра, примерно так же реалистичны, как аргументы в пользу того, что C столь же хорош, как Java для приложений. Опыт, за исключением нескольких незначительных примеров, в подавляющем большинстве случаев доказывает, для чего хорош каждый язык.

Answer 6

• Наличие высокооптимизированных c-компиляторов для всего оборудования, на котором обычно работают RTOS.
• Относительная легкость, с которой вы можете включить очень низкий уровень оптимизации в c-коде.
• Наличие c-кода для многих полезные системные инструменты низкого уровня, которые следовательно, могут быть легко включены.

Answer 7

По определению ОСРВ должна поддерживать детерминированное планирование и выполнение. Обычно низкая задержка прерывания и прямой доступ к оборудованию также являются желательным фактором. Технологии, используемые в Java, такие как сборка мусора, JIT-компиляция и выполнение байт-кода, затрудняют достижение этих целей.

Java может использоваться в системах реального времени, но обычно она запускает на ОСРВ вместо того, чтобы использоваться в ее реализации.

Все это говорит о том, что было бы неверно предположить, что ОСРВ всегда реализована на C. Подойдет любой язык системного уровня, включая ассемблер. В большинстве случаев, по крайней мере, некоторая часть ядра будет в ассемблере в любом случае. C ++ был бы подходящим языком (довольно очевидно, поскольку это по сути надмножество C), во многих коммерческих RTOS в любом случае есть обертки C ++; Я обычно разрабатываю уровни абстракции C ++ для RTOS для поддержки переносимости.

Другая причина, по которой обычно используется C, заключается в том, что компилятор C (часто C / C ++) обычно является первым и часто единственным языком (кроме ассемблера), доступным для новой архитектуры (часто в наши дни в форме Реализация компилятора GNU). Поэтому, если вы хотите иметь возможность портировать свою ОСРВ на самое большое количество платформ, имеет смысл использовать самый вездесущий язык.

Answer 8

Поскольку ОСРВ на основе С хорошо известны и используются в течение многих десятилетий. Их поведение предсказуемо для многих конкретных ситуаций, и вы можете найти много экспертов для разработки с этими системами.

Я не знаю ни одной ОСРВ на основе Java, которая достигла бы такого уровня, чтобы компания, занимающаяся разработкой критически важных для безопасности приложений реального времени, приняла бы ее.

Технически, нет никаких аргументов против ОСРВ на основе Java, но исследования, разработки и продукты по этому вопросу еще не созрели.

Answer 9

Я думаю, что самая большая проблема с Java для этой цели - автоматическая сборка мусора. Вот ссылка о создании систем реального времени в Java.

Answer 10

Всегда ли нужно кодировать RTOS на языке Си?

Нет. Вы можете закодировать RTOS также на ассемблере, в Ada и некоторых других.

Почему это не может быть закодировано в Java или какой-либо другой технологии .. ?? Это из-за отсутствия концепции указателя в Java?

Нет. Непредсказуемое время выполнения кода.