Primeros Embedded con D (el lenguaje de programación)

Question

me gusta mucho de lo que he leído sobre D.

• Documentación unificada (Eso hacer mi trabajo mucho más fácil.)
• capacidad de prueba construido en el idioma .
• Soporte de código de depuración en el idioma.
• Declaraciones a futuro. (Yo siempre pensé que era estúpido declarar la misma función dos veces.)
• Funciones incorporadas para reemplazar el preprocesador .
• Módulos
• Typedef se utiliza para comprobar el tipo correcto en lugar de aliasing.
• Funciones anidadas. (Tos PASCAL Tos)
• Parámetros de entrada y salida. (¡Qué obvio es eso!)
• Admite la programación de bajo nivel - Sistemas embebidos, ¡oh sí!

Sin embargo:

• Se puede d apoyar un sistema integrado que no va a estar ejecutando un sistema operativo?
• ¿La decleación directa que no admite procesadores de 16 bits la excluye por completo de las aplicaciones integradas que se ejecutan en tales máquinas? Algunas 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 gestión de memoria explícita.
• Array limita la comprobación, te encanta, lo odias. Ideal para garantizar el diseño, pero no siempre 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 OS/multihilo.
• ¿Hay un D-Lite para sistemas integrados?

Así que básicamente es D adecuado para sistemas embebidos con sólo unos pocos megabytes (a veces menos que un magabyte), que no ejecutan un sistema operativo, donde el uso de memoria máxima debe ser conocido en tiempo de compilación (por requisitos.) Y posiblemente en algo más pequeño que un procesador de 32 bits?

Estoy muy interesado en algunas de las características, pero me da la impresión de que está dirigido a desarrolladores de aplicaciones de escritorio.

¿Qué es específicamente lo que 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 contener los tiempos de ejecución, ya sea en memoria flash o RAM). Aún podrían calcularse valores de 32 bits, aunque más lentos de 16 bits y requiriendo más operaciones, utilizando el código de la biblioteca.

Answer 1

Debo decir que la respuesta breve a esta pregunta es "No".

• Si sus máquinas son de 16 bits, tendrá grandes problemas para colocar D en él - explícitamente no está diseñado para ello.
• D no es un lenguaje ligero en sí mismo, genera mucha 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 de tipo seguro (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 son sorprendentemente grandes en tamaño, y pueden descalificar 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 también un sistema operativo, por lo que incluso eso funciona en contra de usar D. Sin embargo, existen kernels experimentales en D, por lo que no es imposible per se. Simplemente no habría bibliotecas para eso, a partir de hoy.

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

Answer 2

En primer lugar, lea larsivi's answer. Ha trabajado en el tiempo de ejecución D y sabe de lo que está hablando.

Solo quería agregar: Algunos de los que ha preguntado ya son posibles. No te va a llegar hasta el final, y una señorita es tan buena como una milla de aquí, pero aún así, su información:

La recolección de basura es grande en Windoze o Linux, pero, por desgracia y aplicaciones embebidas en algún momento tiene que hacer explicite gestión de la memoria.

Puede desactivar la recolección de basura. Los diversos sistemas operativos experimentales 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 new: puede usar malloc y free. Incluso las matrices se pueden asignar con él, solo tiene que adjuntar una matriz D alrededor de la memoria asignada mediante un corte.

Array limita la comprobación, te encanta, lo odias. Ideal para garantizar el diseño, pero no siempre permitido por problemas de rendimiento.

El specification for arrays requiere específicamente que los compiladores permiten la comprobación de los límites de ser turned off (véase la "Nota de Aplicación"). gdc proporciona -fno-bounds-check, y en dmd usando -release debe 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 OS/multihilo.

Este soy menos clara, pero dado que la mayoría tiempos de ejecución C permiten apagar multihilo, parece probable que uno podría conseguir el D runtime para desactivarlo también. Si eso es fácil o posible en este momento, no puedo decírtelo.

Answer 3

Las respuestas a esta pregunta son anticuadas:

Se puede d apoyar un sistema embebido que no va a estar ejecutando un sistema operativo?

D puede ser cross-compiled for ARM Linux y ARM Cortex-M. Algunos proyectos tienen como objetivo crear bibliotecas para las arquitecturas Cortex-M like MiniLibD for the STM32 o project which uses a generic library for the STM32. (Se podría implementar su propio sistema operativo minimalista en D en ARM Cortex-M.)

¿El declearation abiertamente que no es compatible con procesadores de 16 bits proclude por completo de aplicaciones embebidas que se ejecutan en este tipo de máquinas? Algunas veces no necesitas un martillo para resolver tu problema.

No, véase la respuesta anterior ... (Pero yo no esperaría que las arquitecturas de "pequeños" que Cortex-M serán apoyados en un futuro próximo.)

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

Puede escribir Garbage Collection free code. (La fundación D parece apuntar a una "libre GC conforme" biblioteca estándar Fobos, sino que es un trabajo en progreso.)

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

(Como usted ha dicho esto depende de su "gusto personal" y las decisiones de diseño. Pero yo asumiría una sobrecarga de rendimiento aceptable para el control de límite debido a los antecedentes de los desarrolladores del compilador D y D's objetivos de diseño.)

¿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 OS/multihilo.

(¿Cuál es la pregunta Uno podría implementar mutlithreading utilizando las capacidades de lenguaje D's, por ejemplo, like explained in this question Por cierto:?. Si desea utilizar las interrupciones consideran este "hello world" project for a Cortex-M3.)

¿Existe un D-Lite para dispositivos integrados sistemas?

Objetivos del SafeD subset of D en el dominio incrustado.