Perché C non ha concorrenti in roba di basso livello? [duplicare]

È interessante notare che ho fatto programmazione embedded per 13 anni: 6 in Ada e 7 in C ++.

In ogni caso, ci sono una serie di fattori che rendono la C particolarmente adatta per questo tipo di programmazione:

• Il runtime / libreria standard richiesta è molto piccola.
• La gestione manuale della memoria è molto utile quando la memoria è limitata.
• Facile da rendere deterministico / in tempo reale perché non devi preoccuparti di quando verrà eseguito un garbage collector o quando verrà generata un'eccezione.
• Facile assegnare una variabile a uno specifico indirizzo di memoria, che è fondamentale per scrivere i driver.
• Un sacco di codice esistente disponibile.

Allo stesso modo oggi si potrebbe pensare alla portabilità / compatibilità del browser (questo codice verrà eseguito in Opera !?) le persone di quel giorno si sono preoccupate della portabilità della CPU / architettura (questo codice verrà eseguito su VAX !?).

Quindi ogni produttore di CPU ha finito per spedire i propri sistemi con un compilatore C. È stato relativamente semplice da implementare, molte persone conoscevano C, ha funzionato bene e non hai dovuto forzare gli sviluppatori della tua piattaforma a scavare nell'assembly sottostante.

A differenza di Javascript, tuttavia, questo slancio non è stato "infuso" nell'architettura. C ha finito per guadagnare slancio grazie alla sua relazione con Unix e agli sforzi che sono stati fatti per rendere Unix e C portatili attraverso le CPU. Puoi leggere molto su questo argomento nella pagina di Wikipedia su C . In breve: Unix è stato uno dei primi OS scritti non in assembly, ma in un linguaggio di livello superiore, C. Inoltre C ha sviluppato esplicitamente i tentativi di portare Unix ad altre architetture. Quindi, quelle lezioni apprese hanno contribuito a rendere C un sistema portatile. Bell Labs ha creato il compilatore C portatile o pcc che ha reso molto più semplice il supporto di molte architetture di CPU.

A causa degli sforzi espliciti per portare Unix ovunque - C è stato portato ovunque. Quindi il linguaggio è stato uno dei primi ad avere una portabilità di basso livello cotta nelle sue ossa e la popolarità e lo slancio sono cresciuti da lì.

Perché C è il linguaggio portatile di livello più basso che esiste ed è ampiamente supportato.

Ricordo che secoli fa in alcune demo era un commento:

C is just asm with more macros.

Ed è vero. C è di livello abbastanza alto da consentire la scrittura di codice portatile, ma di livello abbastanza basso da poter vedere cosa succede esattamente a livello di byte in memoria quando ne hai bisogno e quindi può facilmente collegarlo ai pochi bit di assemblaggio di cui ha assolutamente bisogno essere piattaforma specifica E assolutamente nulla accade implicitamente quando non scrivi nulla, non ci vorranno cicli, il che è importante quando stai scrivendo cose critiche sul rendimento in interni del sistema operativo, libreria di threading e simili.

Tutti gli altri linguaggi di programmazione tranne l'assemblaggio sono di livello superiore. Che è fantastico per scrivere applicazioni, ma per il codice di sistema essere in grado di giudicare che aspetto ha il codice compilato è più importante.

C è anche il minimo comune denominatore. Puoi chiamare la libreria C da qualsiasi altra lingua. Altre lingue hanno vari requisiti che rendono difficile il missaggio.

Per integrare altre risposte, non dimenticare che C è stato scritto da Bell Labs, in gran parte per il progetto Unix. Unix stesso è stato riscritto in C l'anno in cui è stata rilasciata la lingua. Gli strumenti e le librerie del sistema Unix erano basati su C e seguivano le convenzioni C. In breve, C è il linguaggio ufficiale dei sistemi Unix e oggi usiamo tutti i derivati Unix (ad eccezione delle persone Windows).

Inoltre, qualsiasi cosa più di alto livello di C inizia a sacrificare efficienza e libertà di programmazione per l'obiettivo, spesso lodevole, della sicurezza. Ad esempio, prova ad assegnare un blocco di memoria heap di dimensioni dinamiche in Go. Mentre Go è considerato un linguaggio di sistema, è difficile eseguire tali manipolazioni di basso livello; spesso non puoi senza trucchi o sovraccarichi significativi. I bravi programmatori C sono fiduciosi nella loro capacità di usare correttamente il linguaggio e non vogliono rinunciare a tale potenza completa e controllo a grana fine.

1) ..C è di gran lunga la lingua più utilizzata per i bassi livelli .. perché?

È così ampiamente usato a causa della sua età. Secondo Wikipedia - C (linguaggio di programmazione) è 42 anni . Significa 42 * numero_di_programmatori man-years del lavoro svolto. Dato che la C è inclusa nei corsi di programmazione di base in qualsiasi scuola di programmazione seria, il numero di programmatori che possono parlare in tutto il mondo è enorme e la quantità di codice C ora disponibile è molto grande.

2) .. perché C non ha concorrenti nello sviluppo di basso livello? ..

il tuo reclamo "non ha concorrenti" non è vero, quindi non ha alcun motivo per cui la risposta sia disponibile.

VHDL (inizia da link ) è un linguaggio di basso livello molto più efficiente per basso livello cose. per esempio. per esprimere il parallelismo che può essere compilato direttamente nel design del circuito hardware o visualizzato e "interpretato" con altissima velocità ed efficienza su Campo -programmable gate array (FPGA) chip hardware.

Questo linguaggio non è così diffuso in quanto non è così vecchio, di solito non viene insegnato in corsi di programmazione generica, richiede processori speciali (anche se economici) per funzionare. È più impegnativo per la disciplina del programmatore e non è un linguaggio per scrivere applicazioni "ciao mondo" che lampeggia solo con pochi LED collegati alla porta COM o per stampare alcuni fantasiosi tavoli artistici ASCII.

VHDL è un concorrente C serio e molto strong per lo sviluppo di basso livello. Non è "solo un altro assemblatore". È un spostamento di paradigma

3)

Nella categoria dei linguaggi "minimo comune denominatore" che potrebbero sostituire C qualcosa che sarebbe in grado di esprimere / compilare in modo efficiente in MMIX ( pronunciato em-mix) è un'architettura RISC a 64 bit progettata da Donald Knuth potrebbe diventare un concorrente.

Ma!

Chi al giorno d'oggi investe il tempo e gli sforzi per inventare un nuovo linguaggio efficiente con strumenti, ecc. scrivendo un compilatore per questo ecc. Chi ha bisogno di uno sforzo così tremendo oggi? Quali problemi risolverebbe ? Anche i programmatori vogliono crescere figli, vogliono avere vite. Per far sì che un tale nuovo linguaggio sia diffuso, non è più risolvibile come un progetto di hobby per un solo pezzo. Basta confrontare le basi del codice di vari compilatori / IDE con qualcosa che conosci, qualcosa che scrivi tu stesso e vedrai un'altra risposta al perché

Ci sono linguaggi in competizione con C (per programmi di basso livello o di sistema): Ruggine, Ciclone, ... e forse Go (che è probabilmente un livello leggermente più alto).

E ci sono più lingue accademiche in competizione con C.

Bene, la domanda è ciò che definisci come incorporato ...

Un Raspberry Pi è ancora un sistema embedded? Se è così, allora c'è competizione ... È possibile installare Node.JS su di esso ed eseguire JavaScript su di esso, è performante? Un po? Ti importa di ogni cerchio? (Per 10 utenti (non proprio) (

Quindi diciamo che abbiamo solo 33Mhz Ti importa delle cerchie? sì Probabilmente potresti scrivere un Rust o un Go-Code. Ma ti darebbe un po 'di compromesso di cicli .. (Controlli di sicurezza, garbage collection (etc))

Dovremmo preoccuparci dei cicli GHz o MHz tutto il tempo? Sì e No:)

(Fonte: sviluppatore incorporato.)

Prima di tutto, è necessario un linguaggio che compili le istruzioni della macchina, non alcune istruzioni intermedie (ad esempio, Python, Java). Se il compilatore si basa su bytecode Java, cosa esegue i bytecode?

Il requisito del codice macchina compilato elimina molti, molti linguaggi di alto livello.

In secondo luogo, il tuo linguaggio deve essere compilato per formulare le istruzioni di più piattaforme. OK, così Haskell può compilare x86 e ARM. Che ne dici delle altre decine di CPU là fuori?

Il linker di C mi dà una quantità pazzesca di potere. Posso inserire il codice in una posizione specifica. Dire che la mia CPU si avvia a 0x08000. Posso dire al linker di memorizzare il codice in quella posizione. Posso dire al linker di memorizzare determinati codici in determinati segmenti. Il caricatore inserirà questi segmenti in una posizione specifica. Questo è utile se ho il codice che voglio esaurire il flash rispetto al codice per esaurire la RAM. Il kernel di Linux mette il codice di avvio in un blocco di memoria che viene successivamente liberato, recuperando così la memoria dal codice che viene eseguito una volta sola, sempre.

Posso chiamare assembly da C e C dall'assemblaggio. L'avvio della CPU è tutto in assembly. Le cose di livello basso basso vengono eseguite in assembly perché l'ambiente C potrebbe non essere ancora inizializzato! (Qualcosa deve chiamare main ()). I costrutti di sincronizzazione CPU molto bassi (semafori, mutex, ecc.) Sono di solito in assembly perché richiedono specifiche istruzioni della CPU. Cache, MMU e così via sono solitamente configurati in piccoli pezzi di assemblaggio. (ARM è caricato con istruzioni specifiche per configurare la cache, MMU.)

C è uno strato sottile sul montaggio. C è più veloce dell'assemblaggio. Quindi C vince per cose di basso livello. C vince perché nessun altro ha inventato un concorrente.