Mise en place avec D (le langage de programmation)

Question

J'aime beaucoup ce que j'ai lu à propos de D.

• Documentation unifiée (cela permettrait rendre mon travail beaucoup plus facile.)
• Capacité de test intégrée à la langue.
• Prise en charge du code de débogage dans la langue.
• Déclarations avancées. (Je toujours pensait qu'il était stupide de déclarer le deux fois la même fonction.)
• Fonctions intégrées pour remplacer le Préprocesseur.
• Modules
• Typedef utilisé pour la vérification de type appropriée au lieu d'aliasing.
• Fonctions imbriquées. ( Toux PASCAL Toux )
• Paramètres In et Out. (Comme c'est évident!)
• Prend en charge la programmation de bas niveau - Systèmes embarqués, ah oui!

Cependant:

• D peut-il prendre en charge un système intégré ne va pas exécuter un système d'exploitation?
• La déclinaison pure et simple qui il ne supporte pas les processeurs 16 bits annulez-le entièrement de applications fonctionnant sur de telles machines? Parfois, vous n'avez pas besoin d'un marteau pour résoudre votre problème.
• La récupération de place est excellente sous Windows ou Linux, mais, malheureusement, les applications intégrées doivent parfois gérer explicitement la mémoire.
• Array vérifie les limites, vous l’aimez, vous le détestez. Idéal pour l’assurance de la conception, mais pas toujours acceptable pour des problèmes de performances.
• Quelles sont les implications pour un système embarqué ne prenant pas en charge un système d’exploitation (multithreading)? Nous avons un client qui n'aime même pas les interruptions. Beaucoup moins OS / multithreading.
• Existe-t-il un D-Lite pour les systèmes embarqués?

En gros, D convient donc aux systèmes embarqués de quelques mégaoctets (parfois inférieurs à un magaoctet), ne fonctionnant pas sous un système d’exploitation, où l’utilisation maximale de la mémoire doit être connue au moment de la compilation (Par exigences.) et éventuellement inférieure à un processeur 32 bits?

Certaines fonctionnalités m'intéressent beaucoup, mais j'ai l'impression qu'elles sont destinées aux développeurs d'applications de bureau.

Qu'est-ce qui le rend particulièrement inapproprié pour une implémentation 16 bits? (En supposant que l'architecture 16 bits puisse gérer suffisamment de mémoire pour contenir les durées d'exécution, en mémoire flash ou en mémoire vive.) Les valeurs en 32 bits peuvent toujours être calculées, bien que moins rapide que 16 bits et nécessitant davantage d'opérations à l'aide du code de bibliothèque.

Answer 1

Je dois dire que la réponse courte à cette question est "Non".

• Si vos machines sont en 16 bits, vous aurez de gros problèmes pour y insérer D: elle n’a pas été explicitement conçue.
• D n'est pas un langage léger en soi, il génère de nombreuses informations de type à l'exécution qui sont normalement liées à votre application et qui sont également nécessaires pour les variadics typesafe (et donc les fonctionnalités de formatage standard, qu'il s'agisse de Tango ou de Phobos). Cela signifie que même les plus petites applications ont une taille étonnamment grande et peuvent donc disqualifier D des systèmes à faible RAM. De plus, D avec une exécution sous forme de bibliothèque partagée (ce qui pourrait atténuer certains de ces problèmes) a été peu testé.
• Toutes les bibliothèques D actuelles nécessitent une bibliothèque C standard en dessous, et donc généralement aussi un système d’exploitation, donc cela ne fonctionne même pas avec D. Cependant, il existe des noyaux expérimentaux en D, ce qui n’est donc pas impossible en soi. Il n’existera aucune bibliothèque pour cela, à partir d’aujourd’hui.

J'aimerais personnellement vous voir réussir, mais je doute que ce soit un travail facile.

Answer 2

Tout d'abord, lisez la réponse de larsivi . Il a travaillé sur le runtime D et sait de quoi il parle.

Je voulais juste ajouter: Une partie de ce que vous avez demandé est déjà possible. Cela ne vous mènera pas jusqu'au bout, et une demoiselle vaut un mille ici, mais quand même, FYI:

  

La récupération de place est excellente sous Windoze ou Linux, mais, malheureusement, les applications intégrées doivent parfois gérer explicitement la mémoire.

Vous pouvez désactiver le ramassage des ordures. Les divers D OS expérimentaux le font. Voir le module std.gc , en particulier std. gc.disable . Notez également qu'il n'est pas nécessaire d'allouer de la mémoire avec nouveau : vous pouvez utiliser malloc et free . Même les tableaux peuvent être alloués avec ce dernier, il vous suffit d’attacher un tableau D autour de la mémoire allouée à l’aide d’une tranche.

  

Array vérifie les limites, vous l’aimez, vous le détestez. Idéal pour l’assurance de la conception, mais pas toujours acceptable pour des problèmes de performances.

La spécification des tableaux exige spécifiquement que les compilateurs autorisent la vérification des limites de être désactivé (voir la "Note d'implémentation"). gdc fournit -fno-bounds-check et dans dmd , l'utilisation de -release devrait le désactiver.

  

Quelles sont les implications pour un système embarqué ne prenant pas en charge un système d’exploitation, en ce qui concerne la prise en charge multithreading? Nous avons un client qui n'aime même pas les interruptions. Beaucoup moins d'OS / multithreading.

Cela me semble moins clair, mais étant donné que la plupart des applications en C permettent de désactiver le multithreading, il semble probable que le D runtime pour le désactiver également. Que ce soit facile ou possible en ce moment même si je ne peux pas vous le dire.

Answer 3

Les réponses à cette question sont obsolètes:

  

D peut-il prendre en charge un système intégré qui n’exécutera pas de système d’exploitation?

D peut être compilé de manière croisée pour ARM Linux et pour ARM Cortex-M . Certains projets visent à créer des bibliothèques pour les architectures Cortex-M comme MiniLibD pour le STM32 ou ce projet qui utilise une bibliothèque générique pour STM32 . (Vous pouvez implémenter votre propre système d’exploitation minimaliste en D sur ARM Cortex-M.)

  

Est-ce que la déclaration de non-conformité qui ne prend pas en charge les processeurs 16 bits la supprime entièrement des applications intégrées exécutées sur de telles machines? Parfois, vous n'avez pas besoin d'un marteau pour résoudre votre problème.

Non, voir la réponse ci-dessus ... (Mais je ne m'attendrais pas à ce que des architectures "plus petites" que Cortex-M soient prises en charge dans un proche avenir.)

  

La récupération de place est excellente sous Windows ou Linux, mais, malheureusement, les applications intégrées doivent parfois gérer explicitement la mémoire.

Vous pouvez écrire code libre Garbage Collection . (La fondation D semble viser une bibliothèque standard Phobos "conforme à GC free", mais c’est un travail en cours.)

  

Array vérifie les limites, vous l’aimez, vous le détestez. Idéal pour l’assurance de la conception, mais pas toujours acceptable pour des problèmes de performances.

(Comme vous l'avez dit, cela dépend de vos "goûts personnels" et de vos décisions de conception. Mais je supposerais un surcoût de performance acceptable pour la vérification liée en raison des antécédents des développeurs du compilateur D et des objectifs de conception de D.

  

Quelles sont les implications pour un système embarqué ne prenant pas en charge un système d’exploitation, en ce qui concerne la prise en charge multithreading? Nous avons un client qui n'aime même pas les interruptions. Beaucoup moins d'OS / multithreading.

(Quelle est la question? On pourrait implémenter la lecture multiple en utilisant les capacités linguistiques de D, par exemple, comme expliqué dans cette question . BTW: Si vous souhaitez utiliser des interruptions, considérez ce "bonjour le monde" pour un Cortex-M3 . )

  

Existe-t-il un D-Lite pour les systèmes embarqués?

Le sous-ensemble SafeD de D cibles sur le domaine incorporé.