Встраивание с D (язык программирования)

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

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

Однако:

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

Ответ 2

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

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

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

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

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

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

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

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

Ответ 3

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

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

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

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

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

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

Вы можете написать бесплатный код коллекции мусора. (Основа D, похоже, нацелена на стандартную библиотеку Phoos, совместимую с GC GC, но это незавершенная работа.)

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

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

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

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

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

Подстановочное окружение DD D нацелено во встроенном домене.