tipos programación programacion lenguaje language embedded 32-bit d 16-bit

embedded - programación - lenguaje de programacion e



Consiguiendo Embedded con D(el lenguaje de programación) (3)

En primer lugar, lea larsivi . Ha trabajado en el tiempo de ejecución D y sabe de qué está hablando.

Solo quería agregar: algo 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í, FYI:

La recolección de basura es excelente en Windoze o Linux, pero, desafortunadamente, las aplicaciones incrustadas en algún momento deben realizar una gestión de memoria explícita.

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

Control de límites de matriz, lo amas, lo odias. Excelente para la garantía de diseño, pero no siempre permisible para problemas de rendimiento.

La especificación para matrices requiere específicamente que los compiladores permitan la desactivación de la verificación de límites (consulte la "Nota de implementación"). gdc proporciona -fno-bounds-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 al que ni siquiera le gustan las interrupciones. Mucho menos OS / multithreading.

Esto no lo tengo claro, pero dado que la mayoría de los tiempos de ejecución de C permiten desactivar el multihilo, parece probable que uno pueda hacer que el tiempo de ejecución de D también lo deshabilite. Si eso es fácil o posible ahora mismo, no puedo decírtelo.

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

  • Documentación unificada (Eso facilitaría mucho mi trabajo).
  • Capacidad de prueba incorporada al lenguaje.
  • Soporte de código de depuración en el idioma.
  • Declaraciones hacia adelante. (Siempre pensé que era estúpido declarar la misma función dos veces).
  • Funciones integradas para reemplazar el preprocesador.
  • Módulos
  • Typedef se usa para una correcta verificación de tipos en lugar de alias.
  • Funciones anidadas. ( Tos Tos PASCAL)
  • Parámetros de entrada y salida. (¡Qué obvio es eso!)
  • Soporta programación de bajo nivel - Sistemas embebidos, ¡oh sí!

Sin embargo:

  • ¿Puede D admitir un sistema integrado que no va a ejecutar un sistema operativo?
  • ¿La eliminación total de que no admite procesadores de 16 bits lo excluye completamente de las aplicaciones integradas que se ejecutan en dichas 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 incrustadas en algún momento deben realizar una administración de memoria explícita.
  • Control de límites de matriz, lo amas, lo odias. Excelente para la garantía de diseño, pero no siempre permisible para 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 al que ni siquiera le gustan las interrupciones. Mucho menos OS / multithreading.
  • ¿Hay un D-Lite para sistemas embebidos?

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

Estoy muy interesado en algunas de las características, 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 abordar cantidades suficientes de memoria para mantener los tiempos de ejecución, ya sea en memoria flash o RAM). Los valores de 32 bits aún podrían calcularse, aunque sean más lentos que 16 bits y requieren más operaciones, utilizando el código de la biblioteca.


Las respuestas a esta pregunta están desactualizadas:

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

D se puede compilar de forma cruzada para ARM Linux y para ARM Cortex-M . Algunos proyectos tienen como objetivo crear bibliotecas para arquitecturas Cortex-M como MiniLibD para STM32 o este proyecto que utiliza una biblioteca genérica para STM32 . (Podría implementar su propio sistema operativo minimalista en D en ARM Cortex-M).

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

No, vea la respuesta anterior ... (Pero no esperaría que las arquitecturas "más pequeñas" que Cortex-M sean compatibles en un futuro próximo).

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

Usted puede escribir el código libre de recolección de basura . (La fundación D parece apuntar a una biblioteca estándar Fobos "compatible con GC", pero eso es un trabajo en progreso).

Control de límites de matriz, lo amas, lo odias. Excelente para la garantía de diseño, pero no siempre permisible para problemas de rendimiento.

(Como ha dicho, esto depende de su "gusto personal" y de las decisiones de diseño. Pero supongo que se aceptará una sobrecarga de rendimiento aceptable para la verificación de límites debido a los antecedentes de los desarrolladores del compilador de 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 al que ni siquiera le gustan las interrupciones. Mucho menos OS / multithreading.

(¿Cuál es la pregunta? Uno podría implementar el mutlithreading utilizando las capacidades de lenguaje de D, por ejemplo, como se explica en esta pregunta . BTW: Si desea usar interrupciones, considere este proyecto "hola mundo" para un Cortex-M3 ).

¿Hay un D-Lite para sistemas embebidos?

El subconjunto SafeD de objetivos D en el dominio incorporado.


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

  • Si sus máquinas son de 16 bits, tendrá grandes problemas para encajar D: no está específicamente diseñado para ello.
  • 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 variadics seguros de tipo (y, por lo tanto, las características de formato estándar, ya sea Tango o Phobos). Esto significa que incluso las aplicaciones más pequeñas tienen un tamaño sorprendentemente grande y, por lo tanto, pueden descalificar a D de los sistemas con poca memoria RAM. También la D con un tiempo de ejecución como lib compartido (que podría aliviar algunos de estos problemas), ha sido poco probada.
  • Todas las bibliotecas actuales de D requieren una biblioteca estándar de C debajo de ella, y por lo tanto, también típicamente un sistema operativo, por lo que incluso 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 ninguna biblioteca para eso, a partir de hoy.

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