Dubbio sugli eseguibili e sul linguaggio macchina

[gameplay_extreme]

si ma prima di mandare il codice al processore viene letto dal s.o. e se non è capace di leggerlo non lo identifica

Baron diceva che non è così

[xtitox]

mi informo domani dal mio prof di sistemi e poi ti dico

[xtitox]

gli .exe in linux non funzionano perchè ogni sistema operativo compila gli eseguibili in modo diverso anche se il risultato è sempre lo stesso, quindi il sistema operativo legge l' eseguibile poi lo manda al processore

[BaronVsCorsar]

dunque... cosa c'era di non chiaro nella mia precedente spiegazione?

il computer è un circuito integrato che ha due "punti" di ingresso: uno per le istruzioni ed uno per i dati.
le istruzioni e i dati sono delle sequenze binarie.
Es (solo per semplificare, uso 8 bit e mi invento le funzioni):
istruzione 00000100: memorizza il dato nel tuo registro interno
dato 00000001: dato usato da istruzione

nel file eseguibile saranno memorizzati questi 16 bit: 00000100 00000001

e lo posso ottenere tramite assembly magari scrivendo:
mov 1;
che il compilatore, sapendo quale cpu è destinataria (ovviamente quando si compila lo si specifica) lo convertirà in
00000100 00000001 se la cpu è la Baron4000
ed in
11100101 00000001 se la cpu è la Corsar66

cpu differenti, istruzioni binarie differenti, programmi eseguibili differenti.

Notate che il s.o. non c'entra nulla.

Perchè un exe di windows non gira su linux (e viceversa)?
Perchè il s.o. non è altro che un software che gestisce gli aspetti più comuni del pc. Naturalmente questo concetto è cambiato dal dos ad oggi (per intenderci: oggi un aspetto comune è leggere i filmati, nel dos non c'era supportato neppure il BMP).
Quindi se io programmo sotto dos e devo leggere un file scrivo il codice SAPENDO che girerà sotto dos, e scriverò qualche cosa come:
chiama_la_funzione_del_sistema_operativo_leggi_file_su_hard_disk dato_identificativo_della_funzione;
che portrebbe essere in assemply
SUB 0x45552; //esegui la subroutine contenuta nella cella di memoria 0x45552

essendoci un software (il s.o.) che viene eseguito all'accensione del pc (determinato dal boot loader, una sorta di "firmware" che va a cercare il s.o. su qualche memoria di massa) che non è altro che un programma.... la sequenza è questa:

la cpu si accende
seguendo le "istruzioni" del boot loader cerca e carica un sistema operativo
il sistema operativo è un software che viene eseguito
una delle sue funzionalità (fondamentali!) è che può chiamare altri software ad essere eseguiti (i programmi applicativi)
il programma applicativo, forte della conoscenza del s.o. che lo farà girare, può chiedere al s.o. di eseguire alcune operazioni (caricare il file, accedere a zona di memoria utilizzati per scopi specifici dal s.o. ecc.. ecc...)

il linguaggio dell'exe è in sè interpretabile, ma le operazioni richieste potrebbero non avere senso.
Magari per windows il programma sta dicendo di eseguire una funiozine memorizzata a tale indirizzo, mentre in linux a quell'indirizzo ha i colori di una immagine di tux che viene interpretato come
NOP //no operation
GOTO back 1 instruction; //torna alla istruzione precedente
ed ecco la macchina inchiodata.

E' vero che un eseguibile contiene qualche cosa in più oltre il codice macchina, di solito qualche informazione al s.o. su come gestire questo programma (dove allocarlo in memoria, come eseguirlo, se necessità di moduli del s.o. non automaticamente caricati e che quindi devono essere caricati prima di eseguire questo codice...).
Queste meta-istruzioni per la gestione del programma (e non tanto il programma stesso) possono permettere al s.o. di riconoscere anticipatamente che l'exe non è adeguato a questo sistema operativo e non provano ad eseguirlo (riducendo i crash del s.o. che si inchioda provando a eseguire codice che non ha senso).

Se vai su un microcontrollore (PIC ad esempio) normalmente non c'è il s.o., devi scrivere tutto tu... l'"exe" è proprio la sequenza di codici macchina, senza nessuna meta-istruzione (in quanto il s.o. non c'è).

Queste meta istruzioni onn fanno parte del codice macchina in sè, è un po' come l'intestazione dell'mp3 che deve iniziare con una sequenza di caratteri, in modo da evitare di provare a suonare cose che palesemente non sono musica...

Ovviamente quanto detto qui sopra è molto approssimativo e semplificato, ma il concetto più o meno c'è...

[gameplay_extreme]

Nessuno (mi pare) ha risposto riguardo a questo mio dubbio...

p.s.: è da un pò che mi chiedo questo: fino a adesso (in questo topic) mi avete detto che
1) un .exe contiene un "codice" in linguaggio macchina (Baron ha insistito sul fatto gli exe NON contengono una sorta di "bytecode" che devono essere "digeriti" dal S.O. ma contengono PRORIO IL LINGUAGGIO MACCHINA)
2) il linguaggio macchina E' IL LINGUAGGIO "CAPITO" DAL PROCESSORE.

Cioè vorrebbe dire che se uno usa un processore NON itel-compatibile (quindi con un linguaggio macchina differente) non basterebbe cambiare solo il sistema operativo ma sarebbe necessario riscaricare una versione compatibile di tutti gli applicativi???

[BaronVsCorsar]

Cioè vorrebbe dire che se uno usa un processore NON itel-compatibile (quindi con un linguaggio macchina differente) non basterebbe cambiare solo il sistema operativo ma sarebbe necessario riscaricare una versione compatibile di tutti gli applicativi???

questa domanda non ha molto senso... cambiare sistema operativo a cosa? riscaricare, da dove?...
interpretando quello che tu intendi provo a risponderti

se hai un programma per un s.o. (ed in questo modo in genere stabilisci anche l'achitettura hardware che stai usando), e decidi di riusarlo per un altro s.o. (e/o per un altro hardware) tutto deve essere riscritto (o meglio, ricompilato).

Naturalmente esistono soluzioni alternative, gli emulatori software (vedi Mame).

il Mame è un programma che legge un "eseguibile" per altre cpu (chips, una cpu vera e propria, una dedicata al suono, una per la grafica...) le famose "rom" (che oltre al programma contiene anche i dati).
Il programma (eseguibile per l'hardware orginale, ma non per i pc intel) viene a questo punto rielaborato dal software (a questo punto lo puoi vedere come un linguaggio interpretato) che poi lo esegue su un hardware differente.

Discorso analogo per emulatori di C64, Vic20, Amiga, Specturm, Atari 2600, Atari ST....
prendono le rom (il "codice macchina" originale memorizzato su un supporto non volatile), lo mettono in pasto ad un interprete che si preoccupa di emulare su un hw differente le stesse funzioni che avrebbe realizzato l'hw recente.

I linguaggi di programmazione "seri" (pensati per lo sviluppo multipiattaforma) hanno sempre tra le opzioni le macchine per cui il codice è destinato (ad esempio i linguaggi per i microcontrollori chiedono sempre per quale dispositivo si sta compilando), quelli a noi più familiari (che compilano per i pc per intenderci) chiedono il s.o. su cui si dovrà eseguire il programma...

Poi tieni presenti che ci sono accoppiate hw+s.o. (a volte semplicemente chiamati firmware per i dispositivi più semplici, come i vecchi cellulari non smartphone, o altri dispositivi elettronici molto semplici) che non sono scindibili o quasi (playstation, xbox, consolle...). Quando compili decidi in una botta sola quale è l'hw e quale è il s.o. (magari un upgrade di un firmware della consolle potrebbe dare problemi di retrocompatibilità con software scritti per firmware precedenti... suppongo vi sarà capitato di sentire cose del genere quando azzardate a fare degli upgrade firmware di qualche prodotto).

Guarda GM Studio, quando "compili" chiede il dispositivo di destinazione... non è esattamente la stessa cosa, ma ci siamo vicini.

Insomma: il software va scritto perchè giri sull'hw che verrà usato, e sfruttando le "librerie" software esistenti (firmware/sistema operativo).

[gameplay_extreme]

inanzitutto grazie per la risposta

questa domanda non ha molto senso... cambiare sistema operativo a cosa?

a un sistema operativo compatibile con il nuovo hardware.

riscaricare, da dove?...

dal sito di un produttore di applicativi?

se hai un programma per un s.o. (ed in questo modo in genere stabilisci anche l'achitettura hardware che stai usando), e decidi di riusarlo per un altro s.o. (e/o per un altro hardware) tutto deve essere riscritto (o meglio, ricompilato).

Ok, ho capito cosa vuoi dire. Io intendevo chiedere: se esistesse un windows x intel e un windows x vattelapesca potrebbero esistere degli applicativi che girano su tutte e due le piattaforme (senza ricompilazione e senza il trucco degli emulatori) oppure no?

(spero così di essere stato più chiaro su cosa dicevo )

[BaronVsCorsar]

Io intendevo chiedere: se esistesse un windows x intel e un windows x vattelapesca potrebbero esistere degli applicativi che girano su tutte e due le piattaforme (senza ricompilazione e senza il trucco degli emulatori) oppure no?

ok, ora mi è chiaro.

in linea di principio: no.
in pratica spesso sì. Pensa banalmente all'evoluzione dei processori (cioè le cpu) della famiglia intell: 8088, 8086, 286, 386, 486, pentium, pentium II ... (poi mi perdo un po'... è più facile ricordare la sequenza numerica )
tipicamente il codice era riusabile sui processori nuovi, perchè venivano progettati pensando alla retro compatibilità (si tende ad aggiungere operazioni, o a rendere più efficenti quelle esistenti, ma lasciando inalterato il "codice" dell'istruzione e il suo uso formale).

Negli anni '70 si scoprì che le cpu con architettura a ridotto set di isutrizoni erano più veloci di quelle a set di istruzioni complesso (in pratica: le operazioni semplici in proporzione sono molto più di quelle complesse in un programma, quindi conviene avere le istruzioni semplici veloci e quelle complesse lente rispetto l'opposto). Al tempo quasi tutte le cpu erano a set di istruzioni complesse.
Tutt'ora (per retrocompatibilità) i più importanti processori sono ancora CISC (complex instruction set computer) e non RISC (reduced instruction set computer) nonostante si sappiano che i RISC sono più efficienti.

Suppongo che un problema di mancata retrocompatibilità ci sia stato per gli apple quando sono passati dal processore motorola ad intel. Homu che è un po' dentro il mondo mac potrà dare indicazioni.

Un altro mondo in cui si è visto questo problema è quello dei pocketPC (dove girava windows CE, poi windows mobile, windows phone...) su diverse architetture hardware (esattamente l'ipotesi che facevi tu).
I programmi che si scaricano dovevano essere scelti in funzione dell'hw del proprio pocket pc, dove erano diffusi architetture ARM e i primi MIPS.. mi pare pure altre ma non ricordo, ho solo usato un ARM e non lo uso più, per questo ho usato il passato...).
Ecco, in questo caso quando scaricavi un programma dovevi preoccuparti che chi lo forniva lo avesse compilato per l'architettura del tuo telefono, e molti freeware avevano più versioni da scaricare, compilate per le diverse architetture hardware.

[gameplay_extreme]

Grazie per le risposte

Io intendevo chiedere: se esistesse un windows x intel e un windows x vattelapesca potrebbero esistere degli applicativi che girano su tutte e due le piattaforme (senza ricompilazione e senza il trucco degli emulatori) oppure no?

ok, ora mi è chiaro.

in linea di principio: no.

peccato, avevo sempre pensato (non avevo mai aprofondito) che si potesse fare...

in pratica spesso sì. Pensa banalmente all'evoluzione dei processori (cioè le cpu) della famiglia intell: 8088, 8086, 286, 386, 486, pentium, pentium II ... (poi mi perdo un po'... è più facile ricordare la sequenza numerica )
tipicamente il codice era riusabile sui processori nuovi, perchè venivano progettati pensando alla retro compatibilità (si tende ad aggiungere operazioni, o a rendere più efficenti quelle esistenti, ma lasciando inalterato il "codice" dell'istruzione e il suo uso formale).

Si, ma erano/sono tutti processori intel (o intel-compatibili) e poi questa retrocompatibilità (mi riferisco alla retrocompatibilità con gli applicativi) dipende anche da come hanno fatto i processori (non è solo merito del so a quanto è emerso dal dibattito).

Suppongo che un problema di mancata retrocompatibilità ci sia stato per gli apple quando sono passati dal processore motorola ad intel. Homu che è un po' dentro il mondo mac potrà dare indicazioni.

Homu...dove sei ( )

[Homunculus]

C'é stato un problema di compatibilità in effetti quando la apple é passata da processori PowerPC a Intel, perché fondamentalmente tutti i programmi che funzionavano prima hanno smesso di funzionare in seguito.

Durante il periodo di transizione il sistema operativo attualmente in uso (OSX Tiger) e il successivo (OSX Leopard) avevano il supporto per entrambi i processori (immagino che veniva installata una diversa versione a seconda dell'hardware). Questi sistemi erano inoltre dotati di base di un emulatore chiamato "Rosetta" che faceva funzionare regolarmente applicazioni PowerPC su processori intel, l'utente finale fondamentalmente non se ne accorgeva nemmeno, ma andando a vedere la lista dei processi veniva indicato chiaramente quali stavano girando su "Rosetta" e quali nativi su intel.

Ora come ora é passato fin troppo tempo dall'uscita dell'ultimo mac con PowerPC quindi i problemi di compatibilità non esistono più se non su applicazioni molto vecchie e mai aggiornate, tanto che anche Rosetta non é più presente nelle nuove versioni del sistema

[Jak]

i primi MIPS

Muori In Pochi Secondi?

Ormai vedo R&C ovunque

Comunque grazie per la delucidazione baron, finalmente so come fungono gli emulatori(me lo son sempre domandato)

[torchipeppo]

scusate se mi intrometto, ma ho letto tutta la discussione e alla fine mi sono fatto un'idea...
praticamente, è come se nel .exe ci fosse scritto:

00110110110100100101010011011111101001010010101010100010101010101010111111010010101010101010010101010

se lo dai a Windows lo interpreta, ad esempio, così:

Sono un programma di installazione, installa questo programma sul computer.

e installerà il programma;
mentre Linux capirà, sempre per esempio, questo:

C'è un crash di sistema, esegui il comando Spegni prima che vada a fuoco il computer.

e il computer si spegnerà.
Il linguaggio del .exe è sempre linguaggio macchina, cioè numeri binari, ma dato a due OS diversi escono due cose diverse.
(anzi, a dirla tutta se lo dai all' OS sbagliato non succede nulla, anzi dà errore, ma comunque era solo un esempio)
Ho ragione? Se sì, sono abbastanza chiaro? Se no, dove ho sbagliato?

[Jak]

Si e no.
Si perchè hai capito il concetto.
No perchè le istruzioni che intende sono molto più a basso livello, diciamo proprio a livello hardware anche. Scambia un variabile*variabile con un funzione(variabile) per così dire.

[xtitox]

circa esatto

mentre Linux capirà, sempre per esempio, questo:
Linux su quellochevipare.exe ha scritto:
C'è un crash di sistema, esegui il comando Spegni prima che vada a fuoco il computer.

linux non legge niente , è come se ci fossero lettere a caso ad esempio "dfbkjcbkdjavbkjdsfv " che non vuol dire niente

[BaronVsCorsar]

circa esatto

mentre Linux capirà, sempre per esempio, questo:
Linux su quellochevipare.exe ha scritto:
C'è un crash di sistema, esegui il comando Spegni prima che vada a fuoco il computer.

linux non legge niente , è come se ci fossero lettere a caso ad esempio "dfbkjcbkdjavbkjdsfv " che non vuol dire niente

ci sei vicino, ma non è proprio esatto...
Provo a fare un esempio sulla falsariga di quelli fatti poco sopra.

il s.o. è un programma "cornice" che gestisce il copmuter. Ad esempio un software per windows quando vuole accedere ad un file chiederà al sistema operativo "mi apri questo file?".
Il fatto è che windows chiede la domanda formulata in un modo, linux in un altro.

In genere gli eseguibili non partono neppure sul s.o. sbagliato perchè una delle prime richieste del programma al sistema operativo è "fammi girare in questo modo, caricandomi in memoria in questo modo e fornendomi questi 'diritti' su questi pezzi di hardware", e già questa domanda è diversa da s.o. a s.o.

[torchipeppo]

allora, rispondo a tutti...

Si e no.
Si perchè hai capito il concetto.
No perchè le istruzioni che intende sono molto più a basso livello, diciamo proprio a livello hardware anche. Scambia un variabile*variabile con un funzione(variabile) per così dire.

quindi con "livello hardware" intendi anche robe tipo "alza luminosità-abbassa luminosità" o "alza volume-abbassa volume"?

circa esatto

mentre Linux capirà, sempre per esempio, questo:
Linux su quellochevipare.exe ha scritto:
C'è un crash di sistema, esegui il comando Spegni prima che vada a fuoco il computer.

linux non legge niente , è come se ci fossero lettere a caso ad esempio "dfbkjcbkdjavbkjdsfv " che non vuol dire niente

(anzi, a dirla tutta se lo dai all' OS sbagliato non succede nulla, anzi dà errore, ma comunque era solo un esempio)

facevo per dire, capisci, xtitox?

ci sei vicino, ma non è proprio esatto...
Provo a fare un esempio sulla falsariga di quelli fatti poco sopra.

il s.o. è un programma "cornice" che gestisce il copmuter. Ad esempio un software per windows quando vuole accedere ad un file chiederà al sistema operativo "mi apri questo file?".
Il fatto è che windows chiede la domanda formulata in un modo, linux in un altro.

In genere gli eseguibili non partono neppure sul s.o. sbagliato perchè una delle prime richieste del programma al sistema operativo è "fammi girare in questo modo, caricandomi in memoria in questo modo e fornendomi questi 'diritti' su questi pezzi di hardware", e già questa domanda è diversa da s.o. a s.o.

ecco quello che ho capito dalla dettagliata risposta di baron...
hai detto che ogni OS formula "apri questo file" in modo diverso... quindi è come se windows parlasse inglese e linux giapponese? (che effettivamente è quello che state dicendo un po' tutti...)

[Jak]

quindi con "livello hardware" intendi anche robe tipo "alza luminosità-abbassa luminosità" o "alza volume-abbassa volume"?

No, intendo + - * e cose di questo tipo, cioè come ragiona il processore a livello "fisico" e non a ciò che vede l'utente. Ovviamente sono solo esempi, i processori attuali hanno set di istruzioni più ampi permettendo calcoli matematici e funzionalità ad un livello più alto.
Attendo baron per darti le delucidazioni tra basso ed alto livello nel frattempo leggi wiki per quanto non parli molto sull'argomento.
http://it.wikipedia.org/wiki/Linguaggio ... to_livello

[BaronVsCorsar]

hai detto che ogni OS formula "apri questo file" in modo diverso... quindi è come se windows parlasse inglese e linux giapponese? (che effettivamente è quello che state dicendo un po' tutti...)

i s.o. sono programmi che gestiscono l'hw. l'hw è lo stesso? quindi i s.o. lo gestiscono con lo stesso linguaggio (quello macchina).
un programma gira su un s.o.? il programma in genere non accede direttamente all'hw (il sistema operativo serve soprattutto per questo), ma chiede al sistema operativo di accedere in sua vece all'hardware.
Ogni sistema operativo ha gestioini differenti dell'hw, quindi i programmi non sono reciprocamente compatibili.

Se hai dimestichezza con le librerie di programmazione vedi un s.o. come una super libreria sempre caricata in memoria.


Per l'alto e basso livello va bene il link di jak. E, jak, piantala di rigirarmi tutte le spiegazioni che non hai voglia di dare! Anche se è vero che io ti rigiro tutti i test che non ho voglia di fare

[Jak]

Più che altro non sono proprio espertissimo dell'argomento e su alcuni punti ho una certa idea ma non prove concrete che sia vera di conseguenza preferisco aspettare chi ne sa più di me piuttosto di dare informazioni sbagliate.
Una volta su indievault ho scritto un post con termini assolutamente scorretti e solo dopo averlo postato mi sono reso conto di quale orrore avevo scritto
Roba tipo "creare memoria", mi hanno mangiato vivo

E, jak, piantala di rigirarmi tutte le spiegazioni che non hai voglia di dare! Anche se è vero che io ti rigiro tutti i test che non ho voglia di fare

Siamo il team sotutto insomma. Tu conosci ed io ti passo le informazioni

[torchipeppo]

Vediamo di organizzare le idee...
-gli exe contengono linguaggio macchina, cioè codice binario.
-vanno solo su un OS perchè ogni OS scrive le stesse funzioni in modo diverso (per esempio, il concetto "fare" viene espresso in inglese con "do" e in spagnolo con "hacer". Se a uno spagnolo dici "do" non capisce niente.).
-la programmazione in linguaggio macchina è troppo complessa pertanto il programmatore moderno preferisce programmare ad alto livello. ci sono due tipi di linguaggi ad alto livello:
-compilati, che vengono tradotti in linguaggio macchina locale a programmazione ultimata (tipo GML), più efficienti,
-interpretati, che sono tradotti in tempo reale durante l' esecuzione (tipo Java), più trasportabili.
E' più corretto?
E grazie per i chiarimenti forniti!