Получение Embedded с D (язык программирования)

Question

Мне нравится многое из того, что я прочитал о D.

• Единая документация (это облегчит мою работу.)
• Возможность тестирования, встроенная в язык.
• Поддержка отладочного кода на языке.
• Форвардные декларации. (Я всегда думал, что глупо объявлять одну и ту же функцию дважды.)
• Встроенные функции для замены препроцессора.
• Модули
• Typedef используется для правильной проверки типов вместо псевдонимов.
• Вложенные функции. (Кашель ПАСКАЛЬКашель)
• Параметры входа и выхода. (Насколько это очевидно!)
• Поддерживает низкоуровневое программирование - встроенные системы, о да!

Тем не мение:

• Может ли D поддерживать встроенную систему, которая не будет работать под управлением ОС?
• Неужели прямое заявление о том, что он не поддерживает 16-битные процессоры, полностью исключает его из встроенных приложений, работающих на таких машинах? Иногда вам не нужен молоток, чтобы решить вашу проблему.
• Сборка мусора хороша в Windows или Linux, но, к сожалению, когда-нибудь встроенные приложения должны явно управлять памятью.
• Проверка границ массива, вам это нравится, вы ненавидите это. Отлично подходит для обеспечения проектирования, но не всегда допустимо из-за проблем с производительностью.
• Каковы последствия для поддержки многопоточности во встроенной системе, не работающей под управлением ОС? У нас есть клиент, которому не нравятся прерывания. Гораздо меньше ОС / многопоточности.
• Есть ли D-Lite для встраиваемых систем?

Таким образом, D в основном подходит для встраиваемых систем, имеющих всего несколько мегабайт (иногда меньше, чем мегабайт), не работающих под управлением ОС, где необходимо знать максимальное использование памяти во время компиляции (согласно требованиям) и, возможно, для чего-то меньшего, чем 32-битный процессор?

Мне очень интересны некоторые функции, но у меня сложилось впечатление, что он нацелен на разработчиков настольных приложений.

Что конкретно делает его непригодным для 16-битной реализации? (Предполагая, что 16-битная архитектура может адресовать достаточные объемы памяти для хранения времени выполнения, как во флэш-памяти, так и в ОЗУ.) 32-битные значения все еще могут быть вычислены, хотя и медленнее, чем 16-битные и требуют большего количества операций, используя код библиотеки.

Answer 1

Я должен сказать, что короткий ответ на этот вопрос - "Нет".

• Если ваши машины 16-битные, у вас будут большие проблемы с встраиванием D в него - он явно не предназначен для этого.
• D сам по себе не является легким языком, он генерирует много информации о типах во время выполнения, которая обычно связана с вашим приложением, и которая также необходима для небезопасных вариантов (и, следовательно, стандартных функций форматирования, будь то Tango или Phobos). Это означает, что даже самые маленькие приложения имеют удивительно большой размер и, таким образом, могут дисквалифицировать D из систем с низким ОЗУ. Кроме того, D со средой выполнения в качестве совместно используемой библиотеки (которая может облегчить некоторые из этих проблем), был мало протестирован.
• Для всех текущих библиотек D требуется стандартная библиотека C, расположенная под ней, и, следовательно, обычно также ОС, так что даже это работает против использования D. Однако в D существуют экспериментальные ядра, так что это само по себе не является невозможным. На сегодня просто не было бы никаких библиотек для этого.

Я лично хотел бы, чтобы вы добились успеха, но сомневаюсь, что это будет легко работать.

Answer 2

Прежде всего, прочитайте larsivi. Он работал над средой исполнения D и знает, о чем говорит.

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

Сборка мусора отлично подходит для Windoze или Linux, но, к сожалению, когда-нибудь встроенные приложения должны обеспечивать точное управление памятью.

Вы можете отключить сборку мусора. Это делают различные экспериментальные ОС. Смотрите модуль std.gc, в частности std.gc.disable, Также обратите внимание, что вам не нужно выделять память new: ты можешь использовать malloc а также free, Даже массивы могут быть выделены с ним, вам просто нужно прикрепить массив D вокруг выделенной памяти, используя срез.

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

Спецификация для массивов, в частности, требует, чтобы компиляторы допускали отключение проверки границ (см. "Замечание по реализации"). gdc обеспечивает -fno-bounds-check, И в dmd с помощью -release должен отключить это.

Каковы последствия для поддержки многопоточности во встроенной системе, не работающей под управлением ОС? У нас есть клиент, которому не нравятся прерывания. Гораздо меньше ОС / многопоточности.

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

Answer 3

Ответы на этот вопрос устарели:

Может ли D поддерживать встроенную систему, которая не будет работать под управлением ОС?

D может быть кросс-скомпилирован для ARM Linux и для ARM Cortex-M. Некоторые проекты направлены на создание библиотек для архитектур Cortex-M, таких как MiniLibD для STM32 или этот проект, который использует универсальную библиотеку для STM32. (Вы можете реализовать свою собственную минималистичную ОС в D на ARM Cortex-M.)

Неужели прямое заявление о том, что он не поддерживает 16-битные процессоры, полностью исключает его из встроенных приложений, работающих на таких машинах? Иногда вам не нужен молоток, чтобы решить вашу проблему.

Нет, см. Ответ выше... (Но я не ожидал бы, что "меньшие" архитектуры, чем Cortex-M, будут поддерживаться в ближайшем будущем.)

Сборка мусора хороша в Windows или Linux, но, к сожалению, когда-нибудь встроенные приложения должны явно управлять памятью.

Вы можете написать бесплатный сборщик мусора. (Фонд D, похоже, нацелен на стандартную библиотеку "GC free совместимый" Phobos, но это в стадии разработки.)

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

(Как вы сказали, это зависит от вашего "личного вкуса" и дизайнерских решений. Но я бы предположил, что допустимая нагрузка на производительность будет связана с проверкой границ из-за опыта разработчиков компилятора D и целей разработки D).

Каковы последствия для поддержки многопоточности во встроенной системе, не работающей под управлением ОС? У нас есть клиент, которому не нравятся прерывания. Гораздо меньше ОС / многопоточности.

(В чем вопрос? Можно реализовать многопоточность, используя возможности языка D, например, как описано в этом вопросе. Кстати: если вы хотите использовать прерывания, рассмотрите этот проект "hello world" для Cortex-M3.)

Есть ли D-Lite для встраиваемых систем?

Подмножество SafeD D предназначено для встроенного домена.