Incrustado con D (el lenguaje de programación)

Question

Me gusta mucho lo que he leído sobre D.

• Documentación unificada (eso sería hacer mi trabajo mucho más fácil).
• Capacidad de prueba integrada en el idioma.
• Soporte de código de depuración en el idioma.
• Reenviar declaraciones. (Yo siempre pensé que era estúpido declarar el misma función dos veces.)
• Funciones incorporadas para reemplazar el Preprocesador.
• Módulos
• Typedef se utiliza para una verificación de tipo adecuada en lugar de aliasing.
• Funciones anidadas. ( Tos PASCAL Tos )
• Parámetros de entrada y salida. (¡Qué obvio es eso!)
• Admite programación de bajo nivel - Sistemas integrados, ¡oh sí!

Sin embargo:

• ¿Puede D soportar un sistema embebido que no va a ejecutar un sistema operativo?
• ¿La rotunda declinación que no admite procesadores de 16 bits procluirlo completamente desde incrustado aplicaciones que se ejecutan en tales máquinas? A veces no necesitas un martillo para resolver tu problema.
• La recolección de basura es excelente en Windows o Linux, pero, desafortunadamente, las aplicaciones integradas en algún momento deben hacer una administración de memoria explícita.
• Comprobación de límites de matriz, lo amas, lo odias. Excelente para garantizar el diseño, pero no siempre está permitido por problemas de rendimiento.
• ¿Cuáles son las implicaciones en un sistema integrado, que no ejecuta un sistema operativo, para el soporte de subprocesos múltiples? Tenemos un cliente que ni siquiera le gustan las interrupciones. Mucho menos sistema operativo / subprocesamiento múltiple.
• ¿Existe un D-Lite para sistemas integrados?

Entonces, básicamente, D es adecuado para sistemas integrados con solo unos pocos megabytes (a veces menos de un magabyte), que no ejecutan un sistema operativo, donde el uso máximo de memoria debe conocerse en el momento de la compilación (según los requisitos) y posiblemente en algo más pequeño que un procesador de 32 bits?

Estoy muy interesado en algunas de las funciones, pero tengo la impresión de que está dirigido a desarrolladores de aplicaciones de escritorio.

¿Qué es lo que específicamente lo hace inadecuado para una implementación de 16 bits? (Suponiendo que la arquitectura de 16 bits podría direccionar cantidades suficientes de memoria para mantener los tiempos de ejecución, ya sea en memoria flash o RAM.) Todavía se podrían calcular valores de 32 bits, aunque más lentos que 16 bits y que requieren más operaciones, utilizando el código de la biblioteca.

Answer 1

Tengo que decir que la respuesta corta a esta pregunta es "No".

• Si sus máquinas son de 16 bits, tendrá grandes problemas para instalar D en ellas, explícitamente no está diseñado para eso.
• D no es un lenguaje ligero en sí mismo, genera una gran cantidad de información de tipo de tiempo de ejecución que normalmente está vinculada a su aplicación, y que también es necesaria para las variaciones de tipo seguro (y, por lo tanto, las características de formato estándar sean Tango o Phobos). Esto significa que incluso las aplicaciones más pequeñas son sorprendentemente grandes y, por lo tanto, pueden descalificar a D de los sistemas con poca RAM. También D con un tiempo de ejecución como lib compartido (que podría aliviar algunos de estos problemas), ha sido poco probado.
• Todas las bibliotecas D actuales requieren una biblioteca estándar C debajo de ella y, por lo tanto, generalmente también un sistema operativo, por lo que incluso eso funciona contra el uso de D. Sin embargo, existen núcleos experimentales en D, por lo que no es imposible per se. Simplemente no habría bibliotecas para él, a partir de hoy.

Personalmente me gustaría verte triunfar, pero dudo que sea un trabajo fácil.

Answer 2

Primero, lea la respuesta de larsivi . Ha trabajado en el tiempo de ejecución D y sabe de lo que está hablando.

Solo quería agregar: Algunos de lo que preguntaste ya es posible. No te llevará hasta el final, y una falla es tan buena como una milla aquí, pero aún así, para tu información:

  

La recolección de basura es excelente en Windoze o Linux, pero desafortunadamente las aplicaciones integradas en algún momento deben hacer explícita la administración de memoria.

Puede desactivar la recolección de basura. Los diversos sistemas operativos D experimentales lo hacen. Consulte el std.gc , en particular el std. gc.disable . Tenga en cuenta también que no necesita asignar memoria con new : puede usar malloc y free . Incluso se pueden asignar matrices con él, solo necesita adjuntar una matriz D alrededor de la memoria asignada usando un segmento.

  

Comprobación de límites de matriz, lo amas, lo odias. Excelente para garantizar el diseño, pero no siempre está permitido por problemas de rendimiento.

La especificación para matrices requiere específicamente que los compiladores permitan la verificación de límites a desactivado (consulte la " Nota de implementación "). gdc proporciona -fno-limits-check , y en dmd usando -release debería deshabilitarlo.

  

¿Cuáles son las implicaciones en un sistema integrado, que no ejecuta un sistema operativo, para el soporte de subprocesos múltiples? Tenemos un cliente que ni siquiera le gustan las interrupciones. Mucho menos sistema operativo / subprocesamiento múltiple.

Esto lo tengo menos claro, pero dado que la mayoría de los tiempos de ejecución de C permiten desactivar el subprocesamiento múltiple, parece probable que uno pueda obtener el D runtime para deshabilitarlo también. Si eso es fácil o posible en este momento, aunque no puedo decírtelo.

Answer 3

Las respuestas a esta pregunta están desactualizadas:

  

¿Puede D admitir un sistema integrado que no va a ejecutar un sistema operativo?

D puede ser compilado cruzado para ARM Linux y para ARM Cortex-M . Algunos proyectos apuntan a crear bibliotecas para arquitecturas Cortex-M como MiniLibD para STM32 o esto proyecto que utiliza una biblioteca genérica para STM32 . (Puede implementar su propio sistema operativo minimalista en D en ARM Cortex-M.)

  

¿La declaración directa de que no admite procesadores de 16 bits lo excluye completamente de las aplicaciones integradas que se ejecutan en tales máquinas? A veces no necesitas un martillo para resolver tu problema.

No, vea la respuesta anterior ... (Pero no esperaría que arquitecturas '' más pequeñas '' que Cortex-M sean compatibles en el futuro cercano).

  

La recolección de basura es excelente en Windows o Linux, pero, desafortunadamente, las aplicaciones integradas en algún momento deben hacer una administración de memoria explícita.

Puede escribir código gratuito de recolección de basura . (La base D parece apuntar a una biblioteca estándar Phobos que no cumple con los requisitos de GC, pero eso es un trabajo en progreso).

  

Comprobación de límites de matriz, lo amas, lo odias. Excelente para garantizar el diseño, pero no siempre está permitido por problemas de rendimiento.

(Como dijiste, esto depende de tu "gusto personal" y decisiones de diseño. Pero supondría una sobrecarga de rendimiento aceptable para la verificación encuadernada debido a los antecedentes de los desarrolladores del compilador D y los objetivos de diseño de D).

  

¿Cuáles son las implicaciones en un sistema integrado, que no ejecuta un sistema operativo, para el soporte de subprocesos múltiples? Tenemos un cliente que ni siquiera le gustan las interrupciones. Mucho menos sistema operativo / subprocesamiento múltiple.

(¿Cuál es la pregunta? Uno podría implementar mutlithreading usando las capacidades de lenguaje de D, por ejemplo, como se explica en esta pregunta . BTW: Si desea utilizar interrupciones, considere este " hello world & project; proyecto para un Cortex-M3 . )

  

¿Existe un D-Lite para sistemas integrados?

El subconjunto SafeD de D se dirige al dominio incrustado.