2013-10-03 1 views
0

Если я использую язык ассемблера для кода для встроенных систем. Могу ли я использовать RTOS и язык сборщика данных? Обычно rtos используется, когда задействовано сложное программное обеспечение. Есть ли какие-либо технические или теоретические ограничения?Использование RTOS при программировании в сборке?

+3

Учитывая, что все языки более высокого уровня в конечном итоге превращаются в сборку; нет, конечно, нет причин, по которым вы не могли бы написать свое приложение в сборке и написать RTOS в сборке. Некоторые процедуры планировщика RTOS фактически записываются в сборку. Теперь вопрос, который вам нужно задать самому себе: «Мне нужна RTOS для достижения целей моего программного обеспечения». То, что мы не можем ответить за вас ... – Ross

+0

Я бы не стал приравнивать RTOS к сложному программному обеспечению. Существует много сложного программного обеспечения, которое не имеет потребности в реальном времени. –

+0

@Knoblauch Итак, вы хотите сказать, что RTOS будет использоваться только в тех случаях, когда требуются требования реального времени? – fahim

ответ

-1

Это действительно зависит от ОС. Наиболее известные ОС позволяют использовать ассемблерное программирование, но некоторые из них делают его очень неудобным (например, Mac OS X, что ставит очень странные требования к выравниванию стека при вызовах API).

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

Итак, правило: если ОС позволяет запускать скомпилированные двоичные файлы, то это позволяет программировать на языке ассемблера.

Это совершенно другой разговор, насколько легко создавать такие программы. Хорошая документация API необходима.

+0

Вопрос был о RTOS, а не ОС общего назначения. Большинство RTOS - это просто статические библиотеки ссылок, которые связаны с кодом приложения для формирования монолитного изображения приложения. В этом смысле сравнение с OSX действительно не применяется. – Clifford

+0

@Clifford - если что-то называется ОС, оно должно иметь большинство свойств ОС, независимо от двоичного формата. Таким образом, каждая ОС предоставляет некоторые API с некоторыми соглашениями о вызовах. Я не могу знать все ОС (в реальном времени или нет), но все, что я написал в ответ, касается всех типов ОС. Ответ на этот вопрос, естественно, был удовлетворен. – johnfound

+0

Я думаю, что ответ не достаточно конкретный, учитывая, что вопрос был * очень * конкретным. В этом случае это просто случай построения вызова, который соответствует вызывающему соглашению API OS, который всегда является соглашением о вызове C в библиотеке RTOS. Простой ответ заключается в том, что вы вызываете RTOS с ассемблера так же, как игрушка вызывает любой код языка C от ассемблера. В любом случае это никогда не будет «зависит от ОС» - если вы не можете сделать это на ассемблере, то вы не сможете это сделать на машине, поскольку выполнение инструкций на уровне машины - это все, что может сделать компьютер. – Clifford

0

Конечно, да. Как это сделать, может зависеть от выбранной архитектуры и конкретной RTOS.

Большинство ядер RTOS предоставляются в виде статических библиотек ссылок, на которые вы связываете код приложения, чтобы сформировать монолитный образ нагрузки. Некоторые из них, такие как QNX, представляют собой полные операционные системы, которые динамически загружают и выполняют приложения во время выполнения. В последнем случае обращение OS-вызовов с ассемблера должно быть рассмотрено в документации по ОС. В случае статически связанной библиотеки RTOS интерфейс ассемблера обычно будет соответствовать ABI и вызывающему соглашению целевой архитектуры, и это будет документировано для архитектуры и, возможно, самой ОСРВ.

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


С учетом всего сказанного, аргумент для использования ассемблера, как правило, поддерживать жесткий контроль над размером кода и производительности, но и с помощью большой (МОГ) библиотеки третьей стороной, то в какой-то степени потерять этот контроль, и, возможно, возможно, просто использовать C или C++.

По правде говоря, в большинстве случаев вам нужно быть очень хорошо осведомленным о конкретном наборе команд для избиения оптимизирующего компилятора C как по размеру производительности, так и по размеру кода, и даже если у вас есть это знание, вручную оптимизируйте большие тела ассемблера редко стоит усилий с точки зрения производительности. В больших сборных кодовых основах обычно по причинам производительности используется большое количество котельной плиты и макросгенерированного кода - это часто будет неоптимальным для конкретного использования, в то время как оптимизатор компилятора может рассмотреть реализацию каждой части код во время перевода. См. this article на embedded.com от Colin Walls (также читайте комментарии, в том числе мои - для баланса, и просто для удовольствия встроенных выродков в несогласии).