Domanda

Mi piace molto di ciò che ho letto su D.

  • Documentazione unificata (che sarebbe rendi il mio lavoro molto più semplice.)
  • Funzionalità di test integrata in lingua.
  • Supporto del codice di debug nella lingua.
  • Dichiarazioni a termine. (Io sempre ho pensato che fosse stupido dichiarare il stessa funzione due volte.)
  • Funzioni integrate per sostituire il Preprocessore.
  • Moduli
  • Typedef utilizzato per il corretto controllo del tipo invece di aliasing.
  • Funzioni nidificate. ( Tosse PASCAL Tosse )
  • Parametri In e Out. (Quanto è ovvio!)
  • Supporta la programmazione di basso livello - Sistemi integrati, oh sì!

Tuttavia:

  • Può D supportare un sistema integrato che non verrà eseguito un sistema operativo?
  • Lo dichiara chiaramente non supporta processori a 16 bit procluderlo interamente da incorporato applicazioni in esecuzione su tali macchine? A volte non hai bisogno di un martello per risolvere il tuo problema.
  • La garbage collection è ottima su Windows o Linux, ma, sfortunatamente, le applicazioni integrate a volte devono eseguire una gestione esplicita della memoria.
  • Controllo dei limiti dell'array, lo adori, lo odi. Ottimo per la sicurezza del design, ma non sempre consentito per problemi di prestazioni.
  • Quali sono le implicazioni su un sistema incorporato, che non esegue un sistema operativo, per il supporto del multithreading? Abbiamo un cliente a cui non piacciono nemmeno gli interrupt. Molto meno OS / multithreading.
  • Esiste un D-Lite per sistemi embedded?

Quindi sostanzialmente D è adatto per sistemi embedded con solo pochi megabyte (a volte meno di un magabyte), non in esecuzione un sistema operativo, dove l'utilizzo massimo della memoria deve essere noto al momento della compilazione (per requisiti.) e possibilmente su qualcosa di più piccolo di un processore a 32 bit?

Sono molto interessato ad alcune funzionalità, ma ho l'impressione che sia rivolto agli sviluppatori di applicazioni desktop.

Che cosa lo rende specificamente inadatto per un'implementazione a 16 bit? (Supponendo che l'architettura a 16 bit potrebbe indirizzare una quantità sufficiente di memoria per contenere i tempi di esecuzione, sia nella memoria flash che nella RAM.) I valori a 32 bit potrebbero ancora essere calcolati, anche se più lenti di 16 bit e richiedendo più operazioni, usando il codice della libreria.

È stato utile?

Soluzione

Devo dire che la risposta breve a questa domanda è "No".

  • Se le tue macchine sono a 16 bit, avrai grossi problemi ad inserirvi D - non è esplicitamente progettato per questo.
  • D non è un linguaggio leggero in sé, genera molte informazioni sul tipo di runtime che sono normalmente collegate all'app e che sono necessarie anche per i vari tipi di variabili (e quindi le funzionalità di formattazione standard siano Tango o Phobos). Ciò significa che anche le applicazioni più piccole hanno dimensioni sorprendentemente grandi e possono quindi squalificare D dai sistemi con RAM bassa. Anche D con un runtime come lib condivisa (che potrebbe alleviare alcuni di questi problemi), è stato poco testato.
  • Tutte le librerie D attuali richiedono una libreria standard C sottostante, e quindi in genere anche un sistema operativo, quindi anche se funziona contro l'utilizzo di D. Tuttavia, esistono kernel sperimentali in D, quindi non è impossibile di per sé. Ad oggi non ci sarebbero più biblioteche.

Vorrei personalmente vederti avere successo, ma dubito che sarà un lavoro facile.

Altri suggerimenti

Prima di tutto leggi la risposta di larsivi . Ha lavorato sul runtime D e sa di cosa sta parlando.

Volevo solo aggiungere: Alcuni di ciò che hai chiesto è già possibile. Non ti porterà fino in fondo, e una signorina vale quanto un miglio qui, ma comunque, FYI:

  

La garbage collection è ottima su Windoze o Linux, ma sfortunatamente le app integrate a volte devono rendere più esplicita la gestione della memoria.

Puoi disattivare la garbage collection. Lo fanno i vari D OS sperimentali. Vedi il std.gc , in particolare std. gc.disable . Si noti inoltre che non è necessario allocare memoria con new : è possibile utilizzare malloc e free . Anche gli array possono essere allocati con esso, devi solo collegare un array D attorno alla memoria allocata usando una slice.

  

Controllo dei limiti dell'array, lo adori, lo odi. Ottimo per la sicurezza del design, ma non sempre consentito per problemi di prestazioni.

La specifica per array richiede specificamente che i compilatori consentano il controllo dei limiti per essere disattivato (vedere la "Nota di implementazione"). gdc fornisce -fno-bounds-check e in dmd usando -release dovrebbe disabilitarlo.

  

Quali sono le implicazioni su un sistema incorporato, che non esegue un sistema operativo, per il supporto del multithreading? Abbiamo un cliente a cui non piacciono nemmeno gli interrupt. Molto meno sistema operativo / multithreading.

Questo sono meno chiaro, ma dato che la maggior parte dei runtime C consente di disattivare il multithreading, sembra probabile che si possa ottenere D runtime anche per disabilitarlo. Che sia facile o possibile adesso, anche se non posso dirtelo.

Le risposte a questa domanda sono obsolete:

  

D può supportare un sistema incorporato che non eseguirà un sistema operativo?

D può essere compilato in modo incrociato per ARM Linux e per ARM Cortex-M . Alcuni progetti mirano a creare librerie per architetture Cortex-M come MiniLibD per STM32 o questo progetto che utilizza una libreria generica per STM32 . (È possibile implementare il proprio sistema operativo minimalista in D su ARM Cortex-M.)

  

La chiara dichiarazione che non supporta processori a 16 bit lo proclama interamente da applicazioni integrate in esecuzione su tali macchine? A volte non hai bisogno di un martello per risolvere il tuo problema.

No, vedi la risposta sopra ... (Ma non mi aspetto che architetture "più piccole" di Cortex-M saranno supportate nel prossimo futuro.)

  

La garbage collection è ottima su Windows o Linux, ma, sfortunatamente, le applicazioni integrate a volte devono eseguire una gestione esplicita della memoria.

Puoi scrivere Codice gratuito Garbage Collection . (La fondazione D sembra mirare a una libreria standard Phobos conforme a "GC free compliant" ma che è in fase di elaborazione.)

  

Controllo dei limiti dell'array, lo adori, lo odi. Ottimo per la sicurezza del design, ma non sempre consentito per problemi di prestazioni.

(Come hai detto, questo dipende dal tuo "gusto personale" e dalle tue decisioni di progettazione. Ma presumo un sovraccarico di prestazioni accettabile per il controllo associato a causa dello sfondo degli sviluppatori del compilatore D e degli obiettivi di progettazione di D.)

  

Quali sono le implicazioni su un sistema incorporato, che non esegue un sistema operativo, per il supporto del multithreading? Abbiamo un cliente a cui non piacciono nemmeno gli interrupt. Molto meno sistema operativo / multithreading.

(Qual è la domanda? Si potrebbe implementare il mutlithreading usando le capacità del linguaggio D, ad es. come spiegato in questa domanda . BTW: Se si desidera utilizzare gli interrupt, considerare questo " hello world " project per un Cortex-M3 . )

  

Esiste un D-Lite per sistemi embedded?

Il sottoinsieme SafeD di D target nel dominio incorporato.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top