Qual è la differenza tra due programmi main {} vuoti con e senza OS?

Question

Qual è la differenza tra due programmi vuoti main {} quando compilato utilizzando un compilatore c/C++ per destinazione con sistema operativo (ad esempio linux) e senza un sistema operativo (per esempio per un target DSP incorporato)? Sono specificamente interessato a sapere cosa fa il compilatore in modo diverso quando c'è un sistema operativo e altro. In che modo il compilatore/language runtime differisce in due casi?

Answer 1

In realtà è il che fa un lavoro diverso quando si impacchetta un programma da eseguire su un sistema operativo rispetto alla creazione di un programma che gira solo sull'hardware nudo. Il compilatore produce semplicemente file oggetto costituiti da istruzioni mirate per l'architettura host e questi blocchi vengono successivamente combinati e impacchettati dal linker.

Un programma che si intende eseguire su un sistema operativo deve avere una certa struttura binaria: è qui che entrano in gioco i formati eseguibili. Un tale formato potrebbe indicare che il programma dovrebbe avere alcune sezioni di intestazione all'inizio e quindi il codice dovrebbe seguire, per esempio. È compito del caricatore del sistema operativo interpretare questa struttura e quindi alimentare la CPU con il flusso di istruzioni contenuto nella sezione del codice.

Al contrario, un programma che si intende eseguire sull'hardware nudo di solito non ha una struttura speciale e può essere alimentato direttamente alla CPU.

Answer 2

In realtà è il linker che fa un lavoro diverso quando il confezionamento di un programma per l'esecuzione su un sistema operativo contro la costruzione di un programma che viene eseguito su solo l'hardware nudo. Il compilatore produce semplicemente oggetti costituiti da istruzioni mirate per l'architettura host, e questi blocchi vengono successivamente combinati e impacchettati dal linker.

Un programma che si intende eseguire su un sistema operativo deve avere una struttura binaria determinata - questo è dove i formati eseguibili entrano nella riproduzione . Un tale formato potrebbe indicare che il programma dovrebbe avere alcune sezioni di intestazione all'inizio e quindi il codice dovrebbe seguire, per esempio . È compito del caricatore del sistema operativo interpretare questa struttura e quindi alimentare la CPU con il flusso di istruzioni che contiene la sezione del codice .

Al contrario, un programma che si intende eseguire sull'hardware nudo di solito non ha una struttura speciale e può essere alimentato direttamente alla CPU .

Mi piacerebbe costruire questa risposta molto ben scritta di Blagovest. Infatti, come suggerisce, c'è una differenza tra formati di contenitori eseguibili e interfacce binarie e quant'altro. Tuttavia, probabilmente la più grande differenza è il effettivo punto di ingresso principale per l'esecuzione del codice dell'applicazione, nonché la presenza di un codice di avvio insieme a una libreria di runtime; anche se, se sai cosa stai facendo, puoi evitare di collegarti a quest'ultimo su un sistema operativo a tutti gli effetti.

Spesso con la presenza di routine di avvio, una libreria di runtime, ad esempio crt0, il punto di ingresso effettivo dell'applicazione non è main ma qualcos'altro (in genere _start). Prima che questo effettivo punto di ingresso porti il ​​controllo al tuo main, potrebbe svolgere un sacco di compiti molto specifici, solitamente correlati all'inizializzazione.

C'è sempre Wikipedia per more information on crt0.

Tuttavia, su una piattaforma bare metal potrebbero non esserci routine simili fornite in bundle con il compilatore. Di conseguenza il controllo potrebbe essere trasmesso direttamente al tuo main e il primo codice che deve essere eseguito sulla piattaforma sarebbe tuo.

Ecco, questa è la differenza fondamentale tra i due tipi di main s. Tuttavia, devo dire che la tua domanda è un po 'vaga in quanto puoi fare a meno di uno script di avvio se inizializzi lo stack ecc. E puoi anche farlo con una libreria di runtime che fa tutto questo su alcuni (i più?) Nudi - piattaforme di metallo. In realtà tutto dipende dalla tua suite di compilatori, dalla piattaforma che stai prendendo di mira, ecc.

Answer 3

Sono tentato di dire che non c'è differenza. Cosa fa il compilatore (o il sistema di traduzione) è in gran parte l'implementazione dipendente; un sistema di traduzione è probabile che faccia cose diverse per Windows che per Linux, anche se entrambi si qualificano come SO.

La differenza principale è se l'implementazione è ospitata o no. Se non è ospitato, potrebbe non supportare nemmeno main oppure, in caso affermativo, potrebbe non supportare main con argomenti . Ciò che un'implementazione non ospitata richiede o richiede per l'avvio è definito dall'implementazione. Mentre v'è anche un sacco di "implementazione definito" per quanto riguarda start-up in un ambiente ospitato, l'implementazione è necessarie per supportare main, tornando int e con almeno due firme, e è necessario l'applicazione per fornire una tale funzione.

Si noti che sia nel passato che oggi, molte implementazioni che si potrebbero considerare come ospitate non sono, per vari motivi, . In passato, ad esempio, g ++ si è documentato come non hosted (almeno GCC) perché non aveva alcun controllo e non poteva garantire le parti della libreria dell'implementazione. E anche oggi, il C++ di Microsoft può essere considerato ospitato solo quando genera applicazioni console; Le applicazioni Windows non hanno un main.

Answer 4

@BlagovestBuyukliev ha fornito una risposta ben scritta.

Mi piacerebbe espanderlo un po '- Nessun SO in realtà significa nessun SO implementato dal software. Pezzo di HW in grado di eseguire un codice binario ha anche un protocollo che gestisce il caricamento del programma e lo inserisce nella CPU e tutti gli altri dettagli di basso livello. In questo caso il "SO" è effettivamente presente come uno implementato da HW. Da questo punto in poi le differenze tra esso e il sistema operativo standard non sono principali ma tecniche, per quanto riguarda l'esecuzione del codice binario considerato.