Link alla notizia: http://www.hwupgrade.it/news/sistemi/i-floppy-disk-sono-obsoleti-ma-non-per-il-programma-nucleare-usa_62886.html

Il Pentagono continua ad utilizzare sistemi di calcolo che richiedono l'utilizzo di floppy disk da 8". Lo conferma un nuovo rapporto del GAO (Governement Accounttability Office degli Stati Uniti). Prodotti obsoleti ma tuttora impiegati dagli Stati Uniti per gestire attività molto delicate, come quelle relative al programma nucleare nazionale.

Click sul link per visualizzare la notizia.

nemmeno da 5,25 :asd:

proprio vero che hanno mandato uomini sulla luna con tecnologie degne dell'euroconvertitore che ci ha mandato a casa il governo nel 2000

Un sistema così antiquato è molto più difficile da hackerare, e poi non si aggiorna automaticamente a Windows 10

Sempre meglio Un IBM S/1 che un tablet android XD

In certi casi è meglio avere uno strumento affidabile, dove 5000 righe di codice ben fatto funzionano senza bug, rispetto ad avere milionate di righe dove statisticamente è più facile trovare errori (e nessuno ci capisce niente XD)

Tu pensa se uno attaccasse un Mac al sistema norad, e OSX gli vede i missili balistici come "stampante generica in rete" XD

usano tali sistemi perchè sono immuni dall'emp di una bomba nucleare nemica.

Altri esempi sono rappresentati dal Dipartimento del Tesoro che utilizza il linguaggio assembly, risalente agli anni '50 o dal Dipartimento di Giustizia che ricorre al COBOL nell'ambito di un sistema che gestisce, tra l'altro, informazioni relative alla popolazione carceraria

In realtà il COBOL + la base di quasi tutte le elaborazioni bancarie "core" in Italia... E l'Assembly viene utilizzato anche nella moderna automazione industriale... insomma, vecchi ma non obsoleti. :)

Squadra che vince non si cambia.

Il Cobol è tutttora molto usato in gran parte dei sistemi bancari italiani.

Di certo sono immuni a qualsiasi bug o virus moderno.

Un virus manco ci entra (quasi) in 230 kb :asd:

Ogni riga di codice porta in seno n bug.

Vedo più rischio nei sistemi moderni che non in questi.

Oggi come oggi, a meno che non commissionino qualcosa da zero, sarà sempre una versione ridotta all'osso di un qualche OS, magari un kernel Unix con tutti i suoi bug e vulnerabilità. (Come qualsiasi altro kernel, beninteso).

Ambienti "mission critical" come il sistema missilistico nucleare mal tollerano il concetto di patch. Ogni aggiornamento rappresenta un rischio per il funzionamento del sistema.

Interfacce grafiche, accesso a reti protette, sono tutte feature a rischio fallimento.

Ve l'immaginate un crash della shell grafica durante un test che potrebbe capitare?

meno codice c'è meglio è, considerate che aerei moderni hanno fly-by-wire che stanno in 5-10 mb.

certo che un floppy magnetico non brilla per affidabilità nel tempo...

Preferisco che sia una tecnologia vecchissima (non connessa ad internet , ma poco hackerabile) a gestire le forze armate , piuttosto che win10 o peggio !

Il cobol noi lo usiamo ancora in azienda su as400. Una parte dei sw sono scritti in cobol nativo, un'altra parte in RPG.

Si ma a parte il resto guardiamo quella stazione di lavoro della foto.

'na figata, oltre ad essere belle ti danno proprio l'impressione di solidità ed affidabilità.

Allora terminator aveva ragione...

https://youtu.be/V5TaAq_BKGk

Skynet è vicina!

:asd:

Fortunatamente, lo scenario che in prima battuta sembra adatto al sequel de "Il Dottor Stranamore", è un po'meno catastrofico di quanto non possa sembrare. Il Dipartimento della Difesa ha infatti in programma di aggiornare l'antiquata soluzione di storage, al pari del sistema che ne richiede l'utilizzo, entro la fine dell'anno fiscale 2017 (sperando che, nel frattempo, non scoppi un conflitto nucleare "per errore").

Piu' probabile che il rischio di errore ci sia dopo l'upgrade.

Certo che da un sito specializzato in hi tech, questa uscita da testata giornalistica scandalistica stile "vecchio = pericoloso" non me la aspettavo proprio.

Mi aspettavo considerazioni su come la complessita' del codice porta a bug, crash, comportamenti inattesi...

Mica e' roba del tipo "prova a riavviare" o "chiama il tecnico mentre siamo sotto attacco". Sono sw che devono funzionare al primo colpo e punto.

Prima per sabotare una centrale nucleare dovevi attaccarla fisicamente. Oggi lasci una pen drive usb ad hoc in un posto frequentato dagli impiegati della centrale ed ottieni il risultato.

Si ma a parte il resto guardiamo quella stazione di lavoro della foto.

'na figata, oltre ad essere belle ti danno proprio l'impressione di solidità ed affidabilità.

vabbe dai visto il numero di righe di codice le puoi anche stampare.

c'è un bellissimo video sui primi calcolatori a ingranaggi di traiettoria balistica da nave militare su youtube, visto su popularmechanics, se avete tre quarti d'ora di pausa pranza godetevelo perchè è superlativo imho. e lì niente codice!

Un sistema così antiquato è molto più difficile da hackerare, e poi non si aggiorna automaticamente a Windows 10
Preferisco che sia una tecnologia vecchissima (non connessa ad internet , ma poco hackerabile) a gestire le forze armate , piuttosto che win10 o peggio !

L'intero dipartimento della difesa degli USA ha già avviato la migrazione a Win10.

sapete il rischio che si può correre se la una migrazione di un sistema nucleare fallisce o semplicemente ha problemi non marginali?

Beh c'è da sperare che i floppy servano "solo" per far partire i missili e non per abortire il lancio. :p

quindi è solo Hollywood che ci mostra incredibili e fantascientifiche tecnologie nelle loro sale di controllo ?

in realtà il massimo della tecnologia utilizzata è un C64 ?

Avevano provato nel 1983 ad installare presso il NORAD il sistema WOPR, ma non gli era andata troppo bene.
Da allora hanno deciso di non aggiornare più...
:sofico:

Premetto le scuse ma avendo letto quanto sopra in tanti post ,m'è irresistibile la voglia di dire : io c'ero.

Beh! certo nulla di che!, anche tanti di voi c'erano non parliamo di 100 anni fà ...... se però penso che sul Data General CS-50 col cobol dovevo stare nei 24mb di programma ..... per cui si andava a distinguere quanto pesava meno l'istruzione SET A=B al posto della MOVE A TO B :stordita:.

Il disco removibile era di questo tipo ... https://upload.wikimedia.org/wikipedia/commons/thumb/0/03/IBM_2315_disk_cartridge.agr.jpg/220px-IBM_2315_disk_cartridge.agr.jpg

...... che dite? glielo mando il curriculum :fagiano:

Chi ha detto che l'Assembly è obsoleto?
Istruzioni Assembly sono tuttora utilizzate su tutti i pc...in maniera trasparente all'utente...
Oltretutto l'Assembly è il secondo linguaggio più veloce...

usano tali sistemi perchè sono immuni dall'emp di una bomba nucleare nemica.

sicuro sicuro? :sofico:

i floppy sono magnetici, semmai sarebbe meglio un cd/dvd allora ;)

ma il resto del pc che legge/scrive sti floppy come funziona? con circuiti elettronici o per magia? :D

ciao ciao

Chi ha detto che l'Assembly è obsoleto?
Istruzioni Assembly sono tuttora utilizzate su tutti i pc...in maniera trasparente all'utente...
Sì, ma si usa di gran lunga di meno rispetto al passato, ed è ormai relegato a una nicchia.
Oltretutto l'Assembly è il secondo linguaggio più veloce...
Il primo qual è? :fagiano:

Il primo qual è? :fagiano:

10101110101000101011110101010101010011....... :D

Lo immaginavo, ma... è veloce uguale. :O

Lo immaginavo, ma... è veloce uguale. :O

Non avendo mai scritto nulla in binario non saprei, però in assembly si, in certi ambiti embedded è l'unica soluzione applicabile, i linguaggi di alto livello non vanno bene

Già. Pero con l'assembly traduci uno mnemonico in un equivalente binario. Diciamo che sostanzialmente non c'è alcuna differenza (perché preferisco non scendere in certi dettagli). :)

"Un'impiegata del Dipartimento della Difesa USA? Non proprio, ma il computer è lo stesso utilizzato oggi dal Pentagono nell'ambito del programma nucelare"

Nuculare, si pronuncia nuculare
https://www.youtube.com/watch?v=Zl4SmzIreSs

la realtà è che tali sistemi sono MOLTO più sicuri degli attuali. É un fatto da considerare più che un opinione.

Già. Pero con l'assembly traduci uno mnemonico in un equivalente binario. Diciamo che sostanzialmente non c'è alcuna differenza (perché preferisco non scendere in certi dettagli). :)

Non proprio, l'Assembler traduce l'Assembly in Linguaggio Macchina...
traduce = perde tempo

la realtà è che tali sistemi sono MOLTO più sicuri degli attuali. É un fatto da considerare più che un opinione.e allora perché li aggiornano tutti?

:rolleyes:

Non proprio, l'Assembler traduce l'Assembly in Linguaggio Macchina...
traduce = perde tempo
E il linguaggio macchina come lo traduci in binario?

Posto che l'operazione di traduzione in ambo i casi si fa una volta, e una volta generati i binari si eseguono questi.

la realtà è che tali sistemi sono MOLTO più sicuri degli attuali. É un fatto da considerare più che un opinione.
più che sicuri, forse sono molto più collaudati ma soprattutto più economici
nelle banche si usa il COBOL solo per sto motivo

un floppino con una puntina che va a graffiare fisicamente il disco magnetico(vi ricordate quanto casino facevano), non so quanto sia affidabile e veloce...sicuramente li backupperano in modalità usa e getta

E il linguaggio macchina come lo traduci in binario?
Posto che l'operazione di traduzione in ambo i casi si fa una volta, e una volta generati i binari si eseguono questi.
Il Linguaggio Macchina è in binario...

No. Agli inizi era stampato su schede perforate.

Poi sono arrivati i listatoni con sequenze binarie o esadecimali, che infine generavano il binario.

In breve: una codifica per il linguaggio macchina c'è sempre stata, perché è necessaria (in qualche modo devi scriverlo quel codice).

Non affiderei la mia vita ad un floppy. A quanto pare però è affidabile :D

Le macchine leggono solo il Linguaggio Macchina(binario), che poi "leggono" schede perforate(in binario) o listati(in binario) o cd(in binario) o pendisk(in binario) o nastri(in binario), dipende solo dall'interfaccia di lettura della suddetta macchina

Quindi in un ipotetica macchina che ha due ingressi di lettura:
1 - linguaggio macchina
2 - assembly

nel primo caso il codice sarà letto al volo, nel secondo sarà letto in assembly e tradotto in linguaggio macchina

l'assembly di solito non viene interpretato.. di solito viene trasposto in binario per una sola volta. Non c'e' differenza sulle prestazioni rispetto a un file binario scritto a mano che rappresenta lo stesso programma. (Gli) L'assembly e' stato creato proprio per questo motivo!

Inoltre secondo me parlare di velocita' del linguaggio e' scorretto. La velocita' finale dipende da un infinita' di fattori e a volte scrivere tutto in assembly non produce il risultato migliore. Cosi' per fare un esempio non credo che esista nessuno che riesca a produrre a mano il codice assembly di un programma molto complesso che va piu' veloce di un analogo scritto in C/C++/Fortran/(InserisciLinguaggioImperativoStatico) con un compilatore ottimizzante moderno. Magari alcune piccole parti o funzioni ha senso che siano scritte in assembly, ma su tutto il programma e' una cosa senza senso e controproducente.

Premettendo che "io c'ero" (si, sono un vecchione che ha vissuto gli albori dell'informatica), vorrei dare alcune spiegazioni sul tema, perchè, per quanto basilari, vedo che ce n'è bisogno.

Un progamma in Assembly (ovvero Assembler), il cui codice sorgente (source) viene compilato una tantum per tradurlo in programma oggetto (Object ovvero Assoluto ovvero Codice Macchina ovvero Formato Binario), verrà poi sempre eseguito in questo formato, almeno fino a nuova compilazione per sopraggiunte modifiche del codice sorgente.
Ma non è vero che ogni riga di codice source corrisponda sempre one to one ad un'istruzione object, caso mai ogni istruzione source può avere questa corrispondenza. A seconda del compilatore adottato, alcune case hanno creato forme di Assembler più avanzate, dove una riga di codice può essere sviluppata in più istruzioni macchina, cioè si dono "inventati" alcune espressioni di codice sorgente aggiuntive, di uso generale ma magari anche personalizzate al campo di utilizzo verso cui questo compilatore è più o meno orientato. Ma anche parlando di compilatore base, standard, il programmatore stesso più che la casa produttrice può ricorrere all'uso di macroistruzioni, creandosi una libreria personalizzata ai suoi scopi: in questo caso le cosidette "macro" vengono preepanse nelle istruzioni source corrispondenti prima di essere passate alla fase di compilazione standard.
Non solo, ma possono esistere preconfezionate (generallizzate) oltre che preparate dai programmatori (personalizzate) intere librerie di subroutines precompilate, che svolgono funzioni ripetitive di frequente occorrenza, richiamabili opportunamente nel corso del programma. Sia in caso di macro che di "Call" (o anche "Functions" implicite, cambia solo la grafia) si tratta non certo di istruzioni base ma di espressioni source aggiuntive che il compilatore svilupperà traducendole in sequenze di istruzioni binarie a volte anche molto estese (in realtà l'aggancio ed incorporazione delle subroutine in formato oggetto avviene in una fase successive chiamata "Linkedit").
Ora è chiaro che sviluppi di macro e subroutines più o meno generalizzate (che in source si richiamano con una istruzione avanzata corredata da parametri), avranno un'efficienza più o meno grande a seconda dl livello di generalizzazione e sopratutto di accuratezza con le quali sono state realizzate, ma una cosa è certa: istruzioni di base one to one scritte da un buon programmatore che intenda ottimizzare al massimo il risultato ovvero la velocità di esecuzione, saranno sempre potenzialmente più effcienti di sviluppi di espansioni più o meno automatiche generate dal complatore, per ottimizzato che possa essere; spesso in fase di sviluppo macro o inclusione linkedit finiscono per introdursi intere sequenza spurie di codice binario che potrebbero servire in casi particolari, ma anche il solo riconoscerle e bypassarle oltre ad impostazione dei parametri vari per le chiamate e recupero del risultato, costa risorse aggiuntive a fondo perso. Una programmazione manuale, volendo, potrebbe evitarlo.
All'atto pratico tutto l'inut/output viene gestito da complesse macro, ed una parte non trascurabile dell'Object sono call con tanto di parametri. Se poi andassimo nei linguaggi molto più avanzati e molto più recenti, vedremmo un assoluto quasi interamente composto di impostazione parametri e call a librerie precotte da tutte le parti.
Alla faccia dell' efficienza; senza voler parlare dello scempio totale di risorse dei linguaggi attuali, che guazzano in programmazione strutturata, non procedurale, per finire in programmazione Object Oriented..., con tanto di vincoli e blocchi e regole e regolette ed espressioni cervellotiche che per la macchina non hanno proprio senso, una per tutte le classi di oggetti che ci/vi obbligano ad adottare, e che quale legame col codice macchina possano avere lo sannno solo i propugnatori di dette metodologie, che sacrificano l'efficenza macchina e pulizia e linerità e sinteticità della programmazione sull'altare di un malinteso scopo di produttività e leggibilità (e su quest'ultima, mi scappa da ridere...).

Da questo punto di vista la programmazione a oggetti non è affatto diversa da quella strutturata, funzionale, logica, etc.: sono tutte "aliene" alla macchina, che interpreta ed esegue soltanto istruzioni che riconosce nel suo particolare formato (ISA).

La OOP consente "semplicemente" (!) di astrarre il codice in maniera diversa, ma sotto sotto l'implementazione fa uso di meccanismi come la VMT, che è implementata con un paio di istruzioni macchina (una "load" per leggere il puntatore alla VMT, e una "call" per leggere e saltare all'indirizzo del metodo virtuale selezionato. Per lo meno per x86/x64. Altre ISA possono richiedere più istruzioni).

Detto in altri termini, la VMT altri non è che la classica tabella di puntatori a funzione che viene usata nei linguaggi di programmazione strutturati. Per cui se fosse "indigesta" / "aliena" alla macchina la prima, parimenti lo è anche la seconda.

Per cui le obiezioni fatte alla OOP sono riconducibili a persone che non hanno sviluppato l'adeguata forma mentis per destreggiarla, essendo abituate soltanto al paradigma che hanno imparato e che è l'unico che conoscono. La classica paura del nuovo, insomma.
Le macchine leggono solo il Linguaggio Macchina(binario), che poi "leggono" schede perforate(in binario) o listati(in binario) o cd(in binario) o pendisk(in binario) o nastri(in binario), dipende solo dall'interfaccia di lettura della suddetta macchina

Quindi in un ipotetica macchina che ha due ingressi di lettura:
1 - linguaggio macchina
2 - assembly

nel primo caso il codice sarà letto al volo, nel secondo sarà letto in assembly e tradotto in linguaggio macchina
E cosa cambia? Dev'essere tradotto, per l'appunto, perché il linguaggio macchina è, per definizione, un linguaggio che viene usato per rappresentare qualcosa che sarà poi tradotto nei grezzi bit (il codice oggetto).

Per cui ancora no: le macchine non "leggono" il linguaggio macchina. Leggono il prodotto della traduzione in codice oggetto di un sorgente scritto in linguaggio (di cui quello macchina è uno dei tanti).

E cosa cambia? Dev'essere tradotto, per l'appunto, perché il linguaggio macchina è, per definizione, un linguaggio che viene usato per rappresentare qualcosa che sarà poi tradotto nei grezzi bit (il codice oggetto).
Per cui ancora no: le macchine non "leggono" il linguaggio macchina. Leggono il prodotto della traduzione in codice oggetto di un sorgente scritto in linguaggio (di cui quello macchina è uno dei tanti).

cambia invece la sequenza binaria di linguaggio macchina viene direttamente trasformata in impulsi elettrici, se si tratta di una macchina elettrica,
Es.se premo l'interruttore di una lampadina sto eseguendo il linguaggio macchina di quella lampadina (mappato su 1bit) e con 2 sole istruzioni(0 spento, 1 acceso), se ci fosse un controller prima dell'interruttore che deve interpretare o compilare "accendi" e "spegni" le cose cambiano

allo stesso modo in assembly devi passare per l'Assembler(Livello1) che è un'altra macchina che sta al disopra della macchina fisica(Livello0) e ha il compito di compilare il codice in binario

che poi l'Assembler produca un programma oggetto in binario non significa niente, domani puoi inventarti un linguaggio di altissimo livello che produca un programma oggetto in binario, diverso è se scrivi il programma oggetto in binario direttamente(qui non ci sono interpreti o compilatori)

Negli anni 40 si scriveva direttamente in codice binario poi siccome non era molto umano si è creata un'altra macchina astratta l'assembler che aveva il compito di facilitare il compito del programmatore, sino ad arrivare ad oggi dove si sono sovrapposte sempre più macchine astratte

Un sistema così antiquato è molto più difficile da hackerare, e poi non si aggiorna automaticamente a Windows 10

Verissimo ! Vallo a trovare un floppy da 8"

@Vi7o: ancora una volta stai mischiando codice oggetto (binario) con linguaggio macchina. Sono due cose diverse, e il primo rimane il risultato della compilazione/traduzione di un sorgente scritto col secondo.

Se si chiama LINGUAGGIO, ci sarà un motivo, no? E se l'altro si chiama codice oggetto (o binario), idem.

allo stesso modo in assembly devi passare per l'Assembler(Livello1) che è un'altra macchina che sta al disopra della macchina fisica(Livello0) e ha il compito di compilare il codice in binario
l'unica differenza tra assembly e il linguaggio macchina, è solo la rappresentazione....una istruzione in assembly equivale ad un'istruzione in linguaggio macchina, c'è una relazione uno a uno...l'unica differenza, che invece di scrive una sequenza di uno e di zeri (una istruzione x86 può essere lunga 120 bit, ed è facile sbagliare qualcosa....) si scrivono dei codici, che ovviamente devono essere tradotti, nei CORRISPETTIVI codici binari, interpretabili dalla macchina


Inoltre in C/C++ mi hanno sempre detto di evitare il goto perche' questo non permette al compilatore di fare ulteriori passi di ottimizzazione e riordinamento del codice.
più che altro con il goto, si fa fatica a comprendere il codice.
Per contro, visto che siamo in argomento, l'equivalente del goto in assembly, l'istruzione JUMP (JMP ecc...) è necessaria.
Assembly è davvero qualcosa di disumano: bisogna scrivere molte righe, pianificando l'uso che se ne farà dei registri...per una semplice operazione a=4+5;, bisogna caricare nei registri gli operandi , e solo successivamente è possibile usare l'istruzione ADD e poi trascrivere il risultato memorizzato nel registro in memoria: 1 istruzione in C semplicissima sono diventate 4 istuzioni macchina (assembly)

@Vi7o: ancora una volta stai mischiando codice oggetto (binario) con linguaggio macchina. Sono due cose diverse, e il primo rimane il risultato della compilazione/traduzione di un sorgente scritto col secondo.

Se si chiama LINGUAGGIO, ci sarà un motivo, no? E se l'altro si chiama codice oggetto (o binario), idem.
il codice oggetto è scritto in linguaggio macchina. Ma la differenza tra il codice sorgente in linguaggio assembly è solo nella rappresentazione.. sostituendo i simboli mnemonici con le corrispettive sequenze binarie si ottiene il codice oggetto...

L'assembler (assemblatore) che trasforma il file sorgente in codice oggetto, semplicemente converte le istruzioni in codice mnemonico in binario e le monta una accanto alle altre...non fa nient'altro

usano tali sistemi perchè sono immuni dall'emp di una bomba nucleare nemica.

No, tutta l'avionica critica ed i sistemi informatici devono essere resistenti agli EMP
(entro limiti ragionevoli in base alla criticità ed alle schermature dove vengono installati).

Semplicemente sono un numero limitato sistemi (che risalgono a fine anni '70 ed inizio anni '80) usati nei siti di lancio "fissi" e dalle basi dove sono custodite le testate e le armi aviolanciate, ed è più conveniente andare avanti con i pezzi di ricambio ed i floppy che hanno in stock piuttosto che sostituirli.

Probabilmente quando sostituiranno i missili "fissi" sostituiranno anche tutto il sistema di lancio oppure rottamerano tutti i siti fissi, si appoggeranno solo sui sottomarini lanciamissili e sulle armi aviolanciate e sostituiranno solo il software di "gestione magazzino armi nucleari".

Già ora UK e Francia fanno così, mentre Russia e Cina hanno siti fissi perchè non riescono ad avere un numero sufficiente di sottomarini lanciamissili "ben piazzati" (e con vettori con sufficiente portata ) da potersi appoggiare solo ad essi.

Ragazzi a questo punto non mi resta che citare wikipedia :help: :

"Il linguaggio macchina viene spesso confuso con il linguaggio assembly e viceversa. L'assembly è in realtà un linguaggio di programmazione a basso livello che, analogamente ai linguaggi ad alto livello come C, C++, C#, Pascal, Java, Python, Visual Basic, Ruby, ecc., richiede un processo di traduzione. A differenza di questi ultimi, l'assembly consente una traduzione particolarmente semplice che trasforma ogni istruzione dell'assembly, in modo univoco, in una istruzione in linguaggio macchina.

I codici operativi e i dati nel linguaggio macchina sono pattern (stringhe) di bit. L'assembly utilizza al loro posto istruzioni mnemoniche, che rendono più semplice al programmatore umano lo sviluppo e il debug di programmi."

l'articolo completo è qui: https://it.wikipedia.org/wiki/Linguaggio_macchina

Spero a questo punto che la vostra confusione possa dissolversi, altrimenti mi arrendo e vi auguro buona fortuna con le vostre convinzioni;)

Visto che state discutendo sui vari "linguaggi" di programmazione, e in particolare su quello Assembly e Binario(macchina), mi unisco alla discussione chiedendo una cosa che nessuno mi ha mai saputo spiegare, ovvero come è stato programmato il tutto?

Mi spiego meglio.
Perchè da qualche parte si è pur dovuto iniziare.
La "Macchina" capisce solo una sequenza di ZERO e UNO, quindi Binario.
L'Assembly è il linguaggio che piu si avvicina a quello Binario.

Ma cosa è stato usato per creare/inventare/programmare l'Assembly?

Non credo che il computer stesso abbia dettato all'Uomo i comandi che lui accetta e quelli che invece non gli piacciono.

C'è qualcuno che riesce a spiegarmi questa cosa?
Grazie!

Visto che state discutendo sui vari "linguaggi" di programmazione, e in particolare su quello Assembly e Binario(macchina), mi unisco alla discussione chiedendo una cosa che nessuno mi ha mai saputo spiegare, ovvero come è stato programmato il tutto?

Mi spiego meglio.
Perchè da qualche parte si è pur dovuto iniziare.
La "Macchina" capisce solo una sequenza di ZERO e UNO, quindi Binario.
L'Assembly è il linguaggio che piu si avvicina a quello Binario.

Ma cosa è stato usato per creare/inventare/programmare l'Assembly?

Non credo che il computer stesso abbia dettato all'Uomo i comandi che lui accetta e quelli che invece non gli piacciono.

C'è qualcuno che riesce a spiegarmi questa cosa?
Grazie!

Un'istruzione in Assembly è una sorta di "etichetta" di una istruzione binaria. Se ti riferisci a come è stato implementato il primo assembler, direi probabilmente direttamente in binario, no?

Visto che state discutendo sui vari "linguaggi" di programmazione, e in particolare su quello Assembly e Binario(macchina), mi unisco alla discussione chiedendo una cosa che nessuno mi ha mai saputo spiegare, ovvero come è stato programmato il tutto?

Mi spiego meglio.
Perchè da qualche parte si è pur dovuto iniziare.
La "Macchina" capisce solo una sequenza di ZERO e UNO, quindi Binario.
L'Assembly è il linguaggio che piu si avvicina a quello Binario.

Ma cosa è stato usato per creare/inventare/programmare l'Assembly?

Non credo che il computer stesso abbia dettato all'Uomo i comandi che lui accetta e quelli che invece non gli piacciono.

C'è qualcuno che riesce a spiegarmi questa cosa?
Grazie!

Ci provo io nel mio piccolo, senza scendere troppo nei dettagli:
Si parte dal presupposto che le macchine elettroniche comprendono solo la presenza/assenza di segnale elettrico(anche se non è proprio così per non scendere troppo nei dettagli), qui entra in gioco l'uomo, che assegna a presenza=1 assenza=0(anche se nella pratica accade il contrario)
Quindi se tu hai una lampadina con due pulsanti puoi assegnarli i seguenti codici:
0 = spento
1 = acceso

se crei un circuito fisico più complesso(si parlerebbe di maggior numero di "porte" e qui si parlerebbe di un altro linguaggio...):
00 = spento
01 = acceso
10 = strobo
11 = prossimo comando

quindi se vuoi dare un istruzione complessa alla tua lampadina dovresti fare una cosa del genere:
01;
11;
10;
11;
00;
avrai detto alla macchina(che riceve gli impulsi) accenditi, fai effetto strobo, spegniti

qui nasce però il problema che lavorare con i binari diventa un po complicato, quindi posso montare una macchina intermedia: l'assembler
questa macchina traduttore o meglio compilatore mi permette di dire(sempre tutto semplificato):
acceso;
prossima istruzione;
strobo;
prossima istruzione;
spento;

o addirittura chiamare il tutto "programma1"
l'assembler leggendo queste 5 stringhe o 1 stringa nel caso di "programma1" compila la stessa sequenza binaria di prima, la macchina leggendo l'impulso eseguirà gli ordini in binario.

Se non leggi il testo tra le parentesi diventa tutto più fluido.

l'assembly consente una traduzione particolarmente semplice che trasforma ogni istruzione dell'assembly, in modo univoco, in una istruzione in linguaggio macchina.
che è esattamente quello che stavo dicendo:
una volta che si dà in pasto all'assembler, NON esiste alcuna differenza se prima di questo processo hai usato il linguaggio macchina o l'assembly...il codice oggetto sarà IDENTICO, per dimensioni e prestazioni, perchè identica sarà la sequenza di bit..
Il fatto che l'assembly sia più lento del linguaggio macchina è una bufala, a meno di non eseguire la traduzione run-time...cosa che non avviene praticamente mai quando la fase di debugging è terminata.

Una forma, se vogliamo primitiva di assembly è quello di usare il codice esadecimale in sostituzione di quello binario.
Ad un 1010 viene sostituito la cifra A, modificandone la sintassi, ma mantenendo la semantica. Anche in questo caso i numeri esadecimali devono essere tradotti nei corrispettivi binari, prima di essere eseguibili dalla macchina.
in sostanza, la differenza tra linguaggio assembly e macchina, è SOLO nella sintassi....detta in un altro modo, cambia la forma ma non la sostanza di quello che si scrive.

devo però correggerti tuttodigitale, perchè programmare in Assembly significa scrivere stringhe

le macchine sanno leggere stringhe? NO quindi hai bisogno di un'altra macchina(l'assembler)

Se io so scrivere direttamente in linguaggio macchina ho bisogno dell'Assembler? NO

Cosa è più efficiente 1 macchina che esegue il codice al volo o 2 macchine(macchina+assembler), sta benedetta traduzione assembly/codice_macchina porta via tempo o no?SI

anche Nero o ImgBurn creano codice macchina per il lettore cd ma Quanto vi fanno aspettare?

Per intenderci nell'esempio della "lampadina a 4funzioni" che ho fatto sopra l'Assembler per leggere istruzioni stringa per sta lampadina sarebbe una macchina più complicata della "lampadina a 4funzioni" stessa, perchè minimo deve saper leggere i caratteri alfanumerici

Un altro esempio: se io voglio spegnere la tv ho due vie:
1 - spengo dal tasto attaccato alla tv(può essere visto come linguaggio macchina)più comodo per la macchina meno per l'uomo.
2 - spengo dal tasto del telecomando(può essere visto come linguaggio assembly) devo prevedere altro hardware, più comodo per l'uomo meno per la macchina

il risultato è si lo stesso ma posso benissimo fare a meno del telecomando in modo più efficiente per il tv, e meno costoso per l'uomo(costo del telecomando, e del controller hw/sw)

Premetto le scuse ma avendo letto quanto sopra in tanti post ,m'è irresistibile la voglia di dire : io c'ero.

Beh! certo nulla di che!, anche tanti di voi c'erano non parliamo di 100 anni fà ...... se però penso che sul Data General CS-50 col cobol dovevo stare nei 24mb di programma ..... per cui si andava a distinguere quanto pesava meno l'istruzione SET A=B al posto della MOVE A TO B :stordita:.

Il disco removibile era di questo tipo ... https://upload.wikimedia.org/wikipedia/commons/thumb/0/03/IBM_2315_disk_cartridge.agr.jpg/220px-IBM_2315_disk_cartridge.agr.jpg

...... che dite? glielo mando il curriculum :fagiano:

Io usavo le pizze!
A casa dei miei ci sono ancora due storage IBM 1311 con 5 o 6 disk pack (erano soprannominati Pizze! :asd: ) della Dysan e in corredo un fantastico IBM 1620 COMPLETO!!! (FUNZIONANTE!!!!)

Che dici, li mandiamo assieme? :fagiano:

Un altro esempio: se io voglio spegnere la tv ho due vie:
1 - spengo dal tasto attaccato alla tv(può essere visto come linguaggio macchina)più comodo per la macchina meno per l'uomo.
2 - spengo dal tasto del telecomando(può essere visto come linguaggio assembly) devo prevedere altro hardware, più comodo per l'uomo meno per la macchina
l'esempio non è calzante...il tempo di traduzione è una tantum.
un esempio sempre attinente alla TV è il seguente...
sono seduto distante (rappresentazione mnemonica). una volta che mi sono avvicinato (traduzione al binario), non esiste più nessuna differenza anche nelle istruzioni svolte (spegnere la tv con il tasto) ....e se le istruzioni eseguite sono identiche lo è anche la veloxità.

E una volta che ho ottenuto il codice oggetto, resterl vicino alla TV per l'eternità

Quello che scrivi e' sicuramente vero. Pero' proprio perche' con il goto si puo' scrivere facilmente flussi di controllo complicati, il compilatore fa fatica ad ottimizzare codice in cui si abusa di goto
non lo metto in dubbio, ma la ragione principale è da ricercarsi nella manuntenibilità del codice.
E questa è anche la ragione per cui i parametri vengono per lo più passati per valore.


Perchè da qualche parte si è pur dovuto iniziare.
La "Macchina" capisce solo una sequenza di ZERO e UNO, quindi Binario.
L'Assembly è il linguaggio che piu si avvicina a quello Binario.
l'assembly, ma anche il codice esadecimale, non può essere interpretabile dalla macchina: per ragioni di efficienza si usa la più semplice fra tutte le codifiche posizionali. La macchina conosce solo la sua lingua.

La domanda interessante, è chi ha dato la lingua alla macchina...la lingua è intrinseca nella progettazione della macchina,e dovuta nella forma più semplice in quella che viene chiamata CU (Control Unit), una rete combinatoria che in base al codice eseguibile, (determinato dal produttore in fase di progetto) cambia la configurazione della CPU.
In sostanza, come ha spiegato Vi70, l'istruzione non fa che aprire e chiudere determinati fili, bus....ad esempio mettere in comunicazione tre registri per l'istruzione ADD, o mettere in comunicazione un registro e la RAM, e nel caso abilitare il comando read/write enable per registro/ram rispettivamente se è un'istruzione STORE, o abilitare il comando write/read enable se è un'istruzione LOAD.

PS non sono un programmatore.

Sintassi, appunto perché parliamo di un linguaggio che viene utilizzato per rappresentare qualcosa che andrà a finire poi nel codice oggetto/binario.

La rappresentazione esadecimale usata al posto di quella binaria (ma s'è usata anche quella ottale) è un esempio di sintassi diversa impiegata per il linguaggio macchina di un'architettura, che finisce poi per generare il codice oggetto finale una volta effettuata la traduzione.

Non c'è nessuno che nei primi anni '80 ha mai scritto qualcosa in linguaggio macchina? Si usavano le opcode table per le istruzioni, facendo poi i calcoli a mano per gli offset (istruzioni di salto "breve", in particolare), e si mettevano via via tutti i byte in sequenza per generare il listato finale.

Nessuno ha mai visto le riviste dell'epoca, come LIST o anche la famosissima MC MicroComputer, che riportavano listati da digitare contenenti queste sequenze, che venivano poi tradotte e caricate in precise zone di memoria, per poi essere eseguite con istruzioni tipo SYS? Quei listati contenevano blocchi di istruzioni (tipo DATA) che contenevano appunto i codici binari/ottali/esadecimali in linguaggio macchina. A volte per ogni riga veniva aggiunto un byte extra di checksum per verificare che la riga non contenesse errori di digitazione; ovviamente il byte non veniva copiato in memoria.

Basti, quindi, andare a prendere una di queste riviste (e non Wikipedia), spulciarla, e toccare con mano cosa significava scrivere un programma in linguaggio macchina, e cosa si otteneva alla fine (il codice oggetto da qualche parte in memoria).

TL;DR: due cose diverse.

Aggiungo un paio di precisazioni: non c'è necessariamente corrispondenza biunivoca fra istruzioni assembly e corrispondenti in linguaggio macchina. Esistono, infatti, architetture come i Motorola 68K o gli Intel x86 che presentano aliasing nelle istruzioni: la stessa istruzione in assembly può essere tradotta in una di diverse in linguaggio macchina, di cui ovviamente l'assemblatore ne sceglierà sempre e soltanto una.

Infine sì: lavorare in assembly non era affatto semplice, ma all'epoca quello c'era (se si voleva velocità e/o compattezza), ma c'è da dire che architetture come quelle elencate prima consentivano di scrivere programmi in maniera più facile rispetto ad altre architetture. Infatti alcune istruzioni C, come ad esempio l'incremento di una variabile, si mappano in esattamente una istruzione assembly.

Non è nemmeno vero che un programma scritto in "logica sequenziale" debba essere più veloce di uno in OOP: dipende sempre dal tipo di codice, e da com'è implementato il meccanismo di dispatching dei metodi nel secondo caso.

.....

:cool:

Ma infatti io ho scritto il contrario ;)
E io t'ho dato ragione. :D

l'esempio non è calzante...il tempo di traduzione è una tantum.
un esempio sempre attinente alla TV è il seguente...
sono seduto distante (rappresentazione mnemonica). una volta che mi sono avvicinato (traduzione al binario), non esiste più nessuna differenza anche nelle istruzioni svolte (spegnere la tv con il tasto) ....e se le istruzioni eseguite sono identiche lo è anche la veloxità.

E una volta che ho ottenuto il codice oggetto, resterl vicino alla TV per l'eternità

Una Tantum = 1
Nessuno = 0

1>0

qui se non io è la matematica che ti smentisce

Quindi una volta ti sei alzato(compilazione assembly>binario), e se non ti pesa alzarti(sai programmare in linguaggio macchina), tanto che sei vicino al tv, risparmi le batterie del telecomando(avere un assembler)

ribadisco il risultato è lo stesso ma a regime in presenza di hw/sw specifico e questo non è banale, e meno male non vorrei mai programmare in binario...

la realtà è che tali sistemi sono MOLTO più sicuri degli attuali. É un fatto da considerare più che un opinione.

Pura verità. Fine della discussione.

E poi c'è da considerare un'altro fatto: Non si costruiscono più missili nucleari ICBM da decenni(parlo degli USA), e quelli più moderni sono i LGM-Peacekeeper, che è roba degli anni 80... Anzi, vi dirò di più, se non erro di Peacekeeper ne fecero pochissimi(perchè già andavamo verso la fine della Guerra Fredda) e adesso dovrebbero essere stati tutti smantellati. Quindi gli ICBM americani più moderni sono i Minuteman III, degli anni 70.

Quindi, noi adesso stiamo prendendo per il culo i flopponi da 8", che in realtà sono anche fin troppo moderni per gestire roba costruita nel 1970.

Gli USA stanno sviluppando nuove armi ben più moderne e versatili di una bomba H, e state pur sicuri che la gestione di tali armi avviene tramite computer e SO che a noi apparirebbero irreali.

Gli USA stanno sviluppando nuove armi ben più moderne e versatili di una bomba H, e state pur sicuri che la gestione di tali armi avviene tramite computer e SO che a noi apparirebbero irreali.

Si ... se per irreali intendi un mix tra roba avazatissima e roba risalente all'era dei dinosauri elettronici, a volte con roba prodotta quasi su scala artigianale, ecc. ecc.
Basta pensare che certi sistemi d'arma vengono sviluppati in 10. .15 anni (quindi quando si inizia a produrli in grossi quantitativi anche usando la roba più nuova quando erano in progettazione ... sono basati su roba "vecchia") e che restano in servizio per almeno 20 anni (spesso di più).
Per esempio, il B-52 è entrato in produzione nel 1955 e dopo 61 anni è ancora in servizio attivo ma è stato più volte rovesciato come un calzino per sostituire sistemi troppo obsoleti o di cui non si potevano più trovare pezzi di ricambio o almeno compatibili.
Attualmente l'USAF sta meditando sulla possibilità di trasformarlo da un aereo ad 8 turbogetti ad uno a 4 oppure con solo 2 (i motori attuali sono diventati molto più potenti di quelli originali .. costano meno, consumano meno e sopratutto i ricambi sono più facili da trovare).

Ma quello che sto cercando di dire sin dall'inizio non è un confronto numeri alla mano a chi va più veloce sto solo cercando di far capire che programmare in assembly e programmare in linguaggio macchina sono due cose diverse e la macchina può prescindere dall'assembly che deve essere compilato almeno una volta e in architettura quella compilazione non è un operazione banale o trascurabile, anche il visul basic per citarne uno alla fine di chissà quante traduzioni/compilazioni diventa linguaggio macchina...e per me che non so scrivere in linguaggi di più basso livello è sicuramente più efficiente e meno soggetto ad errori
Guardate sta slide e spero possiate capirmi:
http://images.slideplayer.it/2/585159/slides/slide_5.jpg

Il linguaggio assembly è una forma di rappresentazione del linguaggio macchina, quel che è si trova in linguaggio macchina può sempre essere rappresentato, con un disassembler, in linguaggio assembly. Per questo è sbagliato fare confronti prestazionali sui due linguaggi, visto che sono strettamente legati: diversi nei significanti, pressoché uguali nel significato.

Ma guarda che questo è pur vero, e ti spiego il perchè,

se il mio costo di programmazione in linguaggio macchina è 5(sono un fenomeno, e non dobbiamo pensare solo come esseri umani)
se il mio costo di programmazione in assembly è sempre 5

quale dei due linguaggi è più veloce(si parlo di velocità)?
se vado grezzamente a misurare la velocità:
linguaggio macchina = 5
assembly = 5+1

penso che qui la logica non sia un opinione

Il linguaggio assembly è una forma di rappresentazione del linguaggio macchina, quel che è si trova in linguaggio macchina può sempre essere rappresentato, con un disassembler, in linguaggio assembly. Per questo è sbagliato fare confronti prestazionali sui due linguaggi, visto che sono strettamente legati: diversi nei significanti, pressoché uguali nel significato.

e diciamo sempre le stesse cose: Assembler, Disassembler, Compilatore, Traduttore sono tutte macchine!

ogni macchina fisica o astratta aggiunta ha un costo lo volete capire?

Bellaz89, abbi pazienza invece di pensare come un umano pensa come una macchina, perchè questi linguaggi sono pensati per essere eseguiti sulle macchine, che linguaggio è più veloce o efficiente per te? qual è l'unico che riesci a comprendere? tutto il resto è fuffa per gli umani? la sempre famosa lampadina con on/off(che è una macchina) ha bisogno di un assembler?

Ma quello che sto cercando di dire sin dall'inizio non è un confronto numeri alla mano a chi va più veloce sto solo cercando di far capire che programmare in assembly e programmare in linguaggio macchina sono due cose diverse e la macchina può prescindere dall'assembly che deve essere compilato almeno una volta e in architettura quella compilazione non è un operazione banale o trascurabile, anche il visul basic per citarne uno alla fine di chissà quante traduzioni/compilazioni diventa linguaggio macchina...e per me che non so scrivere in linguaggi di più basso livello è sicuramente più efficiente e meno soggetto ad errori
Guardate sta slide e spero possiate capirmi:
http://images.slideplayer.it/2/585159/slides/slide_5.jpg
E di questo programma per Commodore 64 scritto in linguaggio machina che ne pensi?

http://files.museo-computer.it/salalettura/PaperSoft/pp0102/26.jpg
Ma guarda che questo è pur vero, e ti spiego il perchè,

se il mio costo di programmazione in linguaggio macchina è 5(sono un fenomeno, e non dobbiamo pensare solo come esseri umani)
se il mio costo di programmazione in assembly è sempre 5

quale dei due linguaggi è più veloce(si parlo di velocità)?
se vado grezzamente a misurare la velocità:
linguaggio macchina = 5
assembly = 5+1

penso che qui la logica non sia un opinione
Premesso che concordo con Bellaz89, mettiamoci un attimo nell'ottica che hai descritto.

Siccome scrivere un programma in linguaggio macchina richiede un tempo ENORMEMENTE SUPERIORE a fare esattamente la stessa cosa, ma in assembly (altro che 5 e 5: come minimo è un 50 a 5), allora i conti tornano anche con la tua metrica: l'assembly è di gran lunga più veloce del linguaggio macchina.

cdimauro quello di certo non è linguaggio macchina, non mi sembra di vedere nemmeno una sequenza binaria...anzi da ciò che ho letto rapidamente dovrebbe essere un linguaggio di altissimo livello di questo tipo:
Tastiera-64>BASIC>Assembly>Linguaggio Macchina
ci sono almeno 3 traduzioni

Nell'esempio del 5+1 io premettevo che io sapessi programmare allo stesso costo(5) in entrambi i linguaggi(per quanto sia fattibile o meno non ci interessa)

quanto da voi affermato è sicuramente giusto visto nell'ottica umana,
Linguaggio ad Alto Livello efficientissimo per l'umano poco/niente per la macchina e non ci piove
Linguaggio di Basso Livello efficientissimo per la macchina poco/niente per l'umano

sono le basi dell'informatica ma non riuscite a distaccarvi dai Linguaggi ad Alto Livello

ma soprattutto ci sto provando a spiegarvi che per quanto di Bassissimo Livello l'assembly non è la stessa cosa del linguaggio macchina perche la macchina non comprende l'assembly se prima non lo traduci

non continuate a dire: si ma una volta che l'hai tradotto è la stessa cosa:mc: l'assembly serve all'uomo per facilitare il suo compito non quello della macchina

perchè continuate ad ignorare che l'assembler è un altra macchina? vi ho messo anche la slide guardate la slide...

cdimauro quello di certo non è linguaggio macchina, non mi sembra di vedere nemmeno una sequenza binaria...anzi da ciò che ho letto rapidamente dovrebbe essere un linguaggio di altissimo livello di questo tipo:
Tastiera-64>BASIC>Assembly>Linguaggio Macchina
ci sono almeno 3 traduzioni

Nell'esempio del 5+1 io premettevo che io sapessi programmare allo stesso costo(5) in entrambi i linguaggi(per quanto sia fattibile o meno non ci interessa)

quanto da voi affermato è sicuramente giusto visto nell'ottica umana,
Linguaggio ad Alto Livello efficientissimo per l'umano poco/niente per la macchina e non ci piove
Linguaggio di Basso Livello efficientissimo per la macchina poco/niente per l'umano

sono le basi dell'informatica ma non riuscite a distaccarvi dai Linguaggi ad Alto Livello

ma soprattutto ci sto provando a spiegarvi che per quanto di Bassissimo Livello l'assembly non è la stessa cosa del linguaggio macchina perche la macchina non comprende l'assembly se prima non lo traduci

non continuate a dire: si ma una volta che l'hai tradotto è la stessa cosa:mc: l'assembly serve all'uomo per facilitare il suo compito non quello della macchina

perchè continuate ad ignorare che l'assembler è un altra macchina? vi ho messo anche la slide guardate la slide...

Io sinceramente continuo a non capire il tuo punto. Il discorso sulla velocità (di che? Di realizzazione o di esecuzione?) non ha proprio senso. Nessuno può programmare in linguaggio macchina nello stesso tempo che impiegherebbe a farlo in assembly, tanto per cominciare.

Poi, se è per questo, è la macchina stessa che serve all'uomo per facilitare i propri compiti, altrimenti nemmeno esisterebbero i computer, quindi, mi pare normale che l'uomo abbia cercato modi via via più "umani" di interfacciarsi ad essa. L'assembly non è un linguaggio di alto livello, e vi è una corrispondenza uno a uno tra le sue istruzioni e quelle binarie.

L'assembler è una "macchina", tanto quanto lo è una GUI, visto che il tuo click in un punto deve essere tradotto in istruzioni da eseguire, quindi? Rimuoviamo le interfacce e lasciamo solo i kernel?

In tutto ciò, se un compilatore è in grado di genererare un codice binario quasi impossibile da ottenere "a mano", solo un folle potrebbe impelagarsi nella scrittura di vagonate di 1 e 0.

cdimauro quello di certo non è linguaggio macchina, non mi sembra di vedere nemmeno una sequenza binaria...anzi da ciò che ho letto rapidamente dovrebbe essere un linguaggio di altissimo livello di questo tipo:
Tastiera-64>BASIC>Assembly>Linguaggio Macchina
ci sono almeno 3 traduzioni
Come pensi di realizzare un programma in linguaggio macchina e caricarlo in memoria?
Nell'esempio del 5+1 io premettevo che io sapessi programmare allo stesso costo(5) in entrambi i linguaggi(per quanto sia fattibile o meno non ci interessa)
Ciò che supponi è impossibile. Se hai programmato in linguaggio macchina e in assembly per la stessa macchina, dovresti saperlo.
quanto da voi affermato è sicuramente giusto visto nell'ottica umana,
Linguaggio ad Alto Livello efficientissimo per l'umano poco/niente per la macchina e non ci piove
Linguaggio di Basso Livello efficientissimo per la macchina poco/niente per l'umano

sono le basi dell'informatica ma non riuscite a distaccarvi dai Linguaggi ad Alto Livello
L'assembly è un linguaggio a bassissimo livello.
ma soprattutto ci sto provando a spiegarvi che per quanto di Bassissimo Livello l'assembly non è la stessa cosa del linguaggio macchina perche la macchina non comprende l'assembly se prima non lo traduci
Non comprende nemmeno il linguaggio macchina se non gli piazzi il codice oggetto/binario DIRETTAMENTE in memoria.
non continuate a dire: si ma una volta che l'hai tradotto è la stessa cosa:mc:
E' ESATTAMENTE la stessa cosa.
l'assembly serve all'uomo per facilitare il suo compito non quello della macchina
L'unica cosa su cui concordo.
perchè continuate ad ignorare che l'assembler è un altra macchina?
Non è una macchina, ma un tool. In particolare il linguaggio assembly è, al pari di quello macchina, un linguaggio.
vi ho messo anche la slide guardate la slide...
Già fatto, e allora? Solo perché hai messo una slide dovremmo prenderla per vera?

Io ho iniziato a lavorare in linguaggio macchina 6502 (quello degli home computer Commodore) nell'82 (dopo un inizio col BASIC, che però era troppo limitato), facendo uso di una opcode table (presa da poster contenuto in un numero di Commodore Computer Club, se non ricordo male), e i programmini in questo linguaggio me li facevo su carta, producendo una sfilza di sequenze esadecimali.

Queste sequenze venivano poi caricate in memoria facendo uso di programmi come quello di cui ho postato l'immagine prima.

Una volta eseguito, le sequenze esadecimali diventavano byte caricati in precise locazioni di memoria.

Infine con una SYS potevo eseguire il codice oggetto generato dai passaggi precedenti.

Questa era la prassi all'epoca, se volevi lavorare in linguaggio macchina, e non solo con le macchine Commodore se ti vai rileggere le riviste dell'epoca (di cui trovi tante scansioni online, come quella che ho riportato).

Quando finalmente ho avuto a disposizione il Commodore Plus 4, che aveva un monitor integrato (programma che consentiva di disassemblare blocchi di memoria, assemblare istruzioni, eseguire il dump di blocchi di memoria, eseguire esecuzione passo-passo, ecc. ecc.), ho potuto assaggiare la differenza fra assembly e linguaggio macchina.

Ma il risultato finale, e la velocità d'esecuzione del codice oggetto/binario prodotto, era esattamente la stessa. A fronte di uno sforzo sovrumano col linguaggio macchina.

Per cui permettimi: ho potuto provare sulla mia pelle la differenza fra le due cose, e so benissimo come si lavorava con entrambi. Di slide, dunque, non ne ho proprio bisogno: al più te le posso produrre io, sulla scorta di anni di esperienza sul campo.

Io sinceramente continuo a non capire il tuo punto. Il discorso sulla velocità (di che? Di realizzazione o di esecuzione?) ovviamente di esecuzione da parte della macchina


non ha proprio senso. Nessuno può programmare in linguaggio macchina nello stesso tempo che impiegherebbe a farlo in assembly, tanto per cominciare. VERO, questo lo sanno anche i pioppi


Poi, se è per questo, è la macchina stessa che serve all'uomo per facilitare i propri compiti, altrimenti nemmeno esisterebbero i computer, quindi, mi pare normale che l'uomo abbia cercato modi via via più "umani" di interfacciarsi ad essa. L'assembly non è un linguaggio di alto livello, e vi è una corrispondenza uno a uno tra le sue istruzioni e quelle binarie. VERO ma non stai dicendo niente di nuovo


L'assembler è una "macchina", tanto quanto lo è una GUI, visto che il tuo click in un punto deve essere tradotto in istruzioni da eseguire, quindi? Rimuoviamo le interfacce e lasciamo solo i kernel? non ho mai detto questo, ma soprattutto nel contesto non centra una mazza questa domanda


In tutto ciò, se un compilatore è in grado di genererare un codice binario quasi impossibile da ottenere "a mano", solo un folle potrebbe impelagarsi nella scrittura di vagonate di 1 e 0.VERO, anche se in passato anche se per la maggiore erano pieni di bug si realizzavano programmi esclusivamente in questo modo

la diatriba nasce dal fatto che c'è confusione tra linguaggio macchina e assembly, tra uomo e macchina, e questo non mi va giù tutto qui:stordita:

La confusione ce l'ha chi non c'ha mai lavorato.

ovviamente di esecuzione da parte della macchina

A livello di esecuzione non c'è alcuna differenza, visto che, gira e rigira, il processore eseguirà le IDENTICHE operazioni binarie.

la diatriba nasce dal fatto che c'è confusione tra linguaggio macchina e assembly, tra uomo e macchina, e questo non mi va giù tutto qui:stordita:
Non c'è alcuna confusione, secondo me. Le istruzioni assembly sono, praticamente, delle etichette delle istruzioni binarie.

Ciò che conta, ripeto, è che vi sia una corrispondenza di uno a uno. Dunque, se scrivo un programma di 100 istruzioni in assembly, l'assembler tirerà fuori 100 istruzioni binarie corrispondenti.

Il resto della polemica ancora non ho capito da cosa nasca. Pare di parlare del sesso degli angeli.

A questo punto, presupposto che reputo ancora di avere ragione appieno:muro: , e che state girando intorno alle mie domande o affermazioni solo per trovarvi dalla parte della ragione, essendo giunti ad una fase di stallo(mi sembra di dire sempre le stesse cose e non essere compreso), ma soprattutto trovandomi in un contesto democratico, per il momento vi do ragione :cry: almeno sinchè la democrazia non volga a mio favore.:D

Vi ringrazio comunque per il piacevole confronto ho comunque imparato tanta bella roba ;)

A questo punto, presupposto che reputo ancora di avere ragione appieno:muro: , e che state girando intorno alle mie domande o affermazioni solo per trovarvi dalla parte della ragione, essendo giunti ad una fase di stallo(mi sembra di dire sempre le stesse cose e non essere compreso), ma soprattutto trovandomi in un contesto democratico, per il momento vi do ragione :cry: almeno sinchè la democrazia non volga a mio favore.:D

Vi ringrazio comunque per il piacevole confronto ho comunque imparato tanta bella roba ;)

Scusami, chi sta girando intorno? La velocità di esecuzione dei programmi è UGUALE, visto che ad essere eseguito è il codice binario. Il punto è che tu metti in mezzo anche il tempo dovuto alla compilazione/assembling, che però non c'entra nulla con l'esecuzione.

Tra l'altro, a 'sto punto si dovrebbe dire pure che avresti ancora più efficienza se non dovessi passare attraverso il sistema operativo e caricare direttamente il programma in memoria. Anzi, meglio ancora se il programma fosse realizzato in hardware, pensa. :D

Tra l'altro, a 'sto punto si dovrebbe dire pure che avresti ancora più efficienza se non dovessi passare attraverso il sistema operativo e caricare direttamente il programma in memoria. Anzi, meglio ancora se il programma fosse realizzato in hardware, pensa. :D
è quello che cerco di spiegare da un paio di giorni...

Guarda. ti fo anche un esempio

supponiamo che si scrivano due programmi che fanno la stessa cosa. Uno in linguaggio macchina e uno in C

Il programma in C compilato ha un tempo di esecuzione di 2
Il programma in linguaggio macchina ha un tempo di esecuzione di 4

Supponiamo poi che il compilatore C impieghi tempo 4 a portare il sorgente C a rappresentazione binaria.

Allora secondo la tua definizione se eseguo i programmi e tengo conto del tempo di compilazione ho che

C = 2+4 = 6
Linguaggio macchina = 4

Quindi in questo caso il linguaggio macchina sarebbe piu' veloce, giusto?

Ora supponiamo di necessitare di usare lo stesso programma dieci volte. Allora:

C = 2*10 + 4 = 24
Linguaggio macchina = 4*10 = 40

Quindi se uso il programma dieci volte il programma C e' piu' veloce....

Ora non so te, ma una definizione di velocita' che dipende dal numero di volte che si usa un programma e' stupida e inutile e infatti non e' questa la definizione comunemente accettata il discorso che farei io sarebbe questo
un programma tradotto da C ad esempio 1010
un programma pronto per la macchina 1010
eseguito 3 volte
1010
1010
1010
sono la stessa cosa in esecuzione?SI ma il codice in C l'ho compilato almeno una volta?SI

dal lato macchina, che ha fame, gli conviene ricevere subito la pappa(il binario) o attendere che la mamma gli prepari la compilazione?

nella matematica che hai postato tu, a mio avviso, potrei benissimo sbagliarmi non tiene in considerazione che il risultato è lo stesso quindi la macchina come lunghezza di bit dovrà sempre leggere, come nel mio esempio:
1010 1010 1010 a cui dovrai aggiungere il tempo di compilazione

forse la tua matematica sarebbe più corretta a mio avviso sottolineo:

C = 2+(4*10)
Linguaggio macchina = 4*10 = 40

dove (4*10) è il risultato di esecuzione della macchina che legge il binario che come risultato è lo stesso in entrambi i casi

quindi sempre secondo il mio ragionamento invece di una panda e una ferrari, parlerei della stessa macchina(meglio la ferrari:D ) una pronta per la strada e l'altra che deve essere prima assemblata.

perchè noi siamo partiti dall'assembly che ha una trasposizione 1 a 1 con il binario

1a1=lo stesso binario

vedete che ci girate intorno...

e soprattutto ottimizzazioni de che? se il binario generato è lo stesso che ottimizzazioni ci sono?

Quindi devo supporre che la tua definizione di velocita' sia consistente solo e solamente per fare confronti tra assembly e binario
forse sono riuscito a spiegarmi finalmente, a fronte di chi diceva fossero equivalenti

, mentre fallisca miseramente a descrivere qualsiasi altro linguaggio. Scusa se noialtri comuni mortali utilizziamo una definizione che descrive casi piu' generali.

Ah per la cronaca se pensi che anche usando lo stesso algoritmo diversi compilatori producano lo stesso binario forse sei te che hai le idee un po molto confuse... non stavo infatti descrivendo o tentando di descrivere altri linguaggi quelli erano i casi che mi avete messo davanti voi quando mi continuavate a parlare di linguaggi di alto livello senza che il contesto lo richiedesse, MA io mi stavo solo opponendomi a "assembly=linguaggio macchina", era tutto un discorso teorico riscontrabile su qualunque libro accademico che tratta l'argomento, dove sulla macchina fisica lavorano macchine astratte su macchine astratte.(quindi l'ultimo punto ce l'ho ben chiaro non ti preoccupare);)

Ok. resta comunque una tua personale definizione di efficienza e velocita' di un linguaggio di programmazione che il resto del mondo non conosce. Magari se lo avessi specificato prima che era una tua definizione personale si sarebbe finita prima la discussione.

come ti dicevo puoi riscontrarlo anche su libri accademici che parlano di architettura/ingegneria degli elaboratori o linguaggi di programmazione non è solo una mia filosofia

proprio per questo mi aspettavo un po' di supporto:(

dal lato macchina, che ha fame, gli conviene ricevere subito la pappa(il binario) o attendere che la mamma gli prepari la compilazione?
Adesso mi spieghi come fa la macchina a ricevere il binario, senza passare da un compilatore ANCHE nel caso del linguaggio macchina?

Detto in altri termini, tu realizzi un programma in linguaggio macchina: come fai da questo a dare in pasto alla macchina il corrispondente codice binario?

Ciò che ho descritto prima su quello che si faceva nella prima metà degli anni '80 è un chiarissimo esempio della situazione in cui ci si trovava quando si doveva scrivere qualcosa in linguaggio macchina.

Ma "stranamente" su quello che ho scritto non hai avuto nulla da dire... :rolleyes:
come ti dicevo puoi riscontrarlo anche su libri accademici che parlano di architettura/ingegneria degli elaboratori o linguaggi di programmazione non è solo una mia filosofia
Quei libri li ho letti anch'io, se permetti, che una laurea me la sono sudata.

Adesso dimmi cosa trovi di sbagliato in quello che ho scritto in questo commento, come nei miei precedenti, e in particolare nel #81. Grazie.

MA io mi stavo solo opponendomi a "assembly=linguaggio macchina",
non mi pare che nessuno abbia detto che il linguaggio assembly == linguaggio macchina...
Essendo la sintassi per forza di cose diverse (i simboli del vocabolario è immensamente più ricco nell'assembly) i 2 linguaggi sono diversi...
La cosa che accomuna il linguaggio macchina e l'assembly è la semantica. il significato delle produzioni del linguaggio...


era tutto un discorso teorico riscontrabile su qualunque libro accademico che tratta l'argomento,
ma nel tuo testo non fa distinzione tra run-time e compile-time....ti pare possibile che devi compilare ogni qual volta che esegui un programma?


dal lato macchina, che ha fame, gli conviene ricevere subito la pappa(il binario) o attendere che la mamma gli prepari la compilazione?
ma il file sorgente, a parte i pc di cdimauro e di altri Programmatori, l'utente a cui saranno destinati nel 99,99999% non li vedranno mai....
ti risulta che il tuo PC prima di eseguire un aggiornamento di Windows effettui la compilazione? :rolleyes:
Quindi si, che sia compilato in assembly, in C, in basic, il PC che usufrirà del programma avrà per lo più la pappa pronta...

comunque anche il termine compilazione è errato per l'assembly, visto che si usa un assemblatore (assembler).



Guardate sta slide e spero possiate capirmi:
http://images.slideplayer.it/2/585159/slides/slide_5.jpg

cdimauro prendi appunti :asd: :sbonk:

scherzo


se il mio costo di programmazione in linguaggio macchina è 5(sono un fenomeno, e non dobbiamo pensare solo come esseri umani)
se il mio costo di programmazione in assembly è sempre 5
ma con l'assembly devi conoscere a fondo l'architettura su cui stai lavorando, i punti di forza e i punti deboli...
ma chi conosce l'assembly di fatto conosce il linguaggio macchina....

Ti faccio un'esempio di un'istruzione MIPS.
add $4, $4, $7; ASSEMBLY
00000000100001000011101101010000 LINGUAGGIO MACCHINA

Non c'è niente di particolarmente difficile passare dall'assembly a linguaggio macchina ( ho qualche dubbio su architetture più complesse in cui le dimensioni dei campi variano continuamente e le istruzioni sono innumerevoli),
certo è impossibile da correggere e difficile da scrivere (nel senso devi contare il numero di zeri e uno....)
http://www2.cs.uidaho.edu/~jeffery/courses/210/binary.gif

detto questo il vero problema è essere capce di usare l'assembly

Infatti il problema è con le architetture più complesse, dove passare da assembly a linguaggio macchina non è, diciamo, una passeggiata. :stordita:

P.S. Sto prendendo appunti. :D

Adesso mi spieghi come fa la macchina a ricevere il binario, senza passare da un compilatore ANCHE nel caso del linguaggio macchina?
mi pare che esistevano dei programmatori HW che programmavano direttamente la PROM, ma c'è anche da dire che si introduceva codice esadecimale...:D Quindi c'era sempre un qualcosa che traduceva....

edit
ho trovato questo:
http://www.old-computers.com/museum/photos/heathkit_ET3400_System_s1.jpg

Esatto. Come la breadboard che usavamo al triennio dell'ITIS ('87-90) che integrava un 8086 e un mini display esadecimale con annesso tastierino esadecimale, per introdurre le sequenze che componevano il programma in linguaggio macchina (scritto rigorosamente a manina su qualche quadernone, o stampato su carta se si trattava di roba più complessa). :fagiano:

EDIT. Ma LOL :D Era qualcosa di simile a quello che hai postato. :asd:

Esatto. Come la breadboard che usavamo al triennio dell'ITIS ('87-90)
io li ho solo viste...programmavamo già a PC...sempre in esadecimalte, ma con windows, credo...

Vecchi bacucchi :D

Io in assembly ho programmato su un emulatore del vecchio 8086 e su un microcontrollore della Atmel, ma ora mi sfugge il nome (AT90S qualcosa).:sofico:

cari il mio pensiero l'ho già espresso a più riprese, e assolutamente non voglio imporlo, e molte delle risposte che potrei continuare a dare sarebbero ridondanti.
certamente non è giusto prendere singolarmente i miei commenti e dare interpretazioni a propria convenienza...

non dico assolutamente di perdere tempo, ma se rileggete tutti i miei commenti dal primo all'ultimo senza partire dal presupposto ma questo è utile o inutile, a che serve ecc...distaccandosi dalla praticità/comodità, distaccandosi anche dai computer(mi sembra di non aver utilizzato nemmeno una volta la parola "computer" al massimo "macchina",ho parlato addirittura di "lampadina")ho fatto un discorso teorico con esempi (volutamente esasperati essendo che perlopiù si parlava di un astrazione della realtà), che il buon cdimauro avrà di certo riscontrato sui testi da lui letti

scusami cdimauro ma il commento #81 non era tuo, era un altro numero?

detto questo ribadisco è stato un piacevole confronto

@Vi7o: l'81 è il mio (http://hwupgrade.it/forum/showpost.php?p=43720815&postcount=81).

Comunque di quello che hai scritto non ricordo di aver riscontrato qualcosa sul Tanenbaum, il Patterson, o qualche altro testo.

Per il resto, mi pare di capire che non hai avuto alcuna esperienza sull'argomento.

EDIT: Antonio m'ha fregato per 1 minuto. :p

Surreale direi che sia proprio la parola giusta. :p

ciao, una curiosita' che mi si e' rinfocolata leggendo il thread: ma i famigerati demo in assembly che qualche era geologica fa giravano su macchine di classe molto-pre-pentium (e che se non ricordo male nacquero sotto amiga) e facevano cascare la mascella, posto che fossero scritti in assembly... era una necessita' per motivi prettamente tecnici o anche ad esempio ancora non esistevano altri linguaggi utili ad ottenere lo stesso risultato?

Premesso che mi ero già ritirato da questa discussione, per educazione quindi ti rispondo spero di essere il più esaustivo possibile:

Come pensi di realizzare un programma in linguaggio macchina e caricarlo in memoria?
Non mi sembra centri niente il caricamento in memoria con quanto abbiamo detto, che ovviamente avverrà per mezzo dello strumento di input previsto dalla macchina, non penso ci eravamo mai soffermati sull'IO sino ad ora.

Ciò che supponi è impossibile. Se hai programmato in linguaggio macchina e in assembly per la stessa macchina, dovresti saperlo.

Qui non ho capito la domanda

L'assembly è un linguaggio a bassissimo livello.

l'ho detto anche io a più riprese,anzi vedo che quotandomi successivamente affermo proprio questo, non penso di aver affermato il contrario da qualche altra parte

Non comprende nemmeno il linguaggio macchina se non gli piazzi il codice oggetto/binario DIRETTAMENTE in memoria.

Che io sappia il linguaggio macchina è binario o no?? anche se è un problema secondario piazzarlo in memoria visto che il risultato di LM e Assembly è lo stesso, lo faremo allo stesso modo

E' ESATTAMENTE la stessa cosa.

è inutile gridare decontestualizzando la mia affermazione: non continuate a dire che una volta compilato è la stessa cosa, perchè l'ho detto più volte che a prescindere dalla compilazione è la stessa cosa solo chè c'è un passaggio in più la compilazione attraverso l'assembler

L'unica cosa su cui concordo.

almeno una, il gol della bandiera...

Non è una macchina, ma un tool. In particolare il linguaggio assembly è, al pari di quello macchina, un linguaggio.

qui sei tu che confondi assembler(può essere vista come una macchina astratta fisica o software) con assembly(linguaggio tradotto dall'assembler in linguaggio macchina), non mi sembra di aver confuso da nessuna parte questo punto...

Già fatto, e allora? Solo perché hai messo una slide dovremmo prenderla per vera?

la slide siccome è scritta con il comic sans non l'ho creata per forza io l'ho trovata in rete e sicuramente è di qualche corso universitario, la puoi riscontrare anche sui testi... e dovrebbe esplicare la suddivisione di un elaboratore in livelli con i rispettivi linguaggi, serviva semplicemente a far capire che i livelli in cui sono disposti non sono li tanto per e diceva soprattutto livello macchina sotto livello assembly, due livelli diversi, qui però il tono che hai utilizzato mi è dispiaciuto mi dava tanto di "qualunque cosa dirai di qui in poi è una cavolata e non ti crederò nemmeno se mi dai prova che la Terra non è piatta..."

Io ho iniziato a lavorare in linguaggio macchina 6502 (quello degli home computer Commodore) nell'82 (dopo un inizio col BASIC, che però era troppo limitato), facendo uso di una opcode table (presa da poster contenuto in un numero di Commodore Computer Club, se non ricordo male), e i programmini in questo linguaggio me li facevo su carta, producendo una sfilza di sequenze esadecimali.
Queste sequenze venivano poi caricate in memoria facendo uso di programmi come quello di cui ho postato l'immagine prima.
Una volta eseguito, le sequenze esadecimali diventavano byte caricati in precise locazioni di memoria.
Infine con una SYS potevo eseguire il codice oggetto generato dai passaggi precedenti.
Questa era la prassi all'epoca, se volevi lavorare in linguaggio macchina, e non solo con le macchine Commodore se ti vai rileggere le riviste dell'epoca (di cui trovi tante scansioni online, come quella che ho riportato).
Quando finalmente ho avuto a disposizione il Commodore Plus 4, che aveva un monitor integrato (programma che consentiva di disassemblare blocchi di memoria, assemblare istruzioni, eseguire il dump di blocchi di memoria, eseguire esecuzione passo-passo, ecc. ecc.), ho potuto assaggiare la differenza fra assembly e linguaggio macchina.
Ma il risultato finale, e la velocità d'esecuzione del codice oggetto/binario prodotto, era esattamente la stessa. A fronte di uno sforzo sovrumano col linguaggio macchina.
Per cui permettimi: ho potuto provare sulla mia pelle la differenza fra le due cose, e so benissimo come si lavorava con entrambi. Di slide, dunque, non ne ho proprio bisogno: al più te le posso produrre io, sulla scorta di anni di esperienza sul campo.

Qui stai dicendo quello che io ho detto dall'inizio,
la velocità di esecuzione del codice generato è la stessa, solo che con l'assembly anche se decisamente più conveniente da parte tua facevi o meglio l'assembler faceva un passaggio in più, non ho mai detto da nessuna parte che è più bello o più figo scrivere in linguaggio macchina altrimenti non ci sarebbe stato bisogno dell'assembly
sul Tanenbaum che forse è quello che descrive meglio e in modo più marcato i livelli dell'elaboratore trovi una slide simile a quella che avevo linkato dove l'assembly si trova a Livello 4, il linguaggio macchina al Livello 3 per favore però non iniziamo a discutere riguardo i livelli inferiori ti prego...

Spero di aver risposto a tutte le domande pendenti a questo punto anche se la maggior parte erano state ampiamente trattate in post precedenti, anzi alcune era doppie già nello stesso post.

...

Secondo me il punto centrale di tutta la questione è questo:

da quello che scrivi (magari mi sbaglio) sembra che tu sia convinto che il codice assembly venga compilato prima di ogni esecuzione del programma.


Quello che normalmente succede è che il codice assembly viene compilato UNA VOLTA dal computer del programmatore, che poi distribuisce "la pappa pronta" a MILIONI di utenti. QUINDI L'UTENTE CHE AVVIA IL PROGRAMMA NON DEVE MAI COMPILARE NULLA, nemmeno al primo avvio, perché ha già il codice oggetto pronto per essere eseguito!

In questo l'esempio delle due ferrari era perfettamente calzante: quale delle due ferrari è più veloce? La ferrari già costruita o quella ancora da costruire?
La velocità delle due è la stessa, l'esempio che fai tu avrebbe senso solo se la ferrari la dovesse costruire l'utente finale OGNI VOLTA che gli serve.



Poi se consideriamo la quantità di riferimento giusta il tuo ragionamento non fa una piega, mi spiego meglio:

la quantità che ti interessa non è il tempo di esecuzione del singolo programma, ma "la somma di tutti i tempi di compilazione e di esecuzione passati, presenti e futuri di un determinato programma".

Considerando questa quantità, prendiamo ad esempio un programma che in tutto il suo ciclo di vita verrà utilizzato nel mondo per un totale di 1000000000 di ore (non è tanto se pensi che ci sono programmi che vengono utilizzati a livello mondiale per 1 miliardo di ore ogni giorno, e non per tutto il ciclo di vita del programma):

a questo punto avresti questa incredibile differenza prestazionale:

- codice binario: 1000000000 di ore

- codice assembly: 1000000000 di ore più 1 secondo di compilazione (a stare larghi)

Si, considerando questa quantità hai ragione tu, il codice binario è più ""veloce"" dello 0,000000000027% :fagiano:




Ora, consideriamo il caso all'estremo opposto: un programma che si fa un singolo programmatore per sè stesso, e che userà poco. Ipotizziamo che nell'intero ciclo vitale di questo programma, venga utilizzato solo per 1 ora:

qui la differenza prestazionale comincia ad essere rilevante:

- codice binario: 3600 secondi

- codice assembly: 3601 secondi (a stare larghi, ma molto... dubito che un programmino fatto per essere usato un'ora in tutta la sua vita richieda più di qualche millisecondo di compilazione DALL'ASSEMBLY* )

In questo caso, il codice binario è più ""veloce"" dello 0,027% :winner:




PS: Il ragionamento che fai tu non è che non abbia MAI senso, può avere senso nel caso di programmi che vengono compilati all'inizio di ogni esecuzione (ad esempio JAVA con compilatore JIT, in cui il bytecode viene compilato prima di ogni esecuzione del programma).
Ma non ha senso invece se si parla di un normale programma compilato una sola volta.


*PPS: ho pensato solo adesso che giustamente qualcuno mi potrebbe far notare che quello per l'assembly non è nemmeno un compilatore ma un assemblatore, infinitamente più semplice e veloce

IMHO:

sono sistemi molto piu' affidabili di quelli attuali

ciao, una curiosita' che mi si e' rinfocolata leggendo il thread: ma i famigerati demo in assembly che qualche era geologica fa giravano su macchine di classe molto-pre-pentium (e che se non ricordo male nacquero sotto amiga) e facevano cascare la mascella, posto che fossero scritti in assembly... era una necessita' per motivi prettamente tecnici o anche ad esempio ancora non esistevano altri linguaggi utili ad ottenere lo stesso risultato?

era una necessita' dato che le memorie e la potenza erano molto inferiori di adesso e per aver quei risultati dovevi "spremere" l'hardware, ovvero, programmare a basso livello, quasi a livello di linguaggio macchina. L'assembler e' molto vicino al linguaggio macchina. Ancora oggi alcune routine dove la precisione e la performance sono primarie vengono programmate in assembler. Di solito queste routine sono poi all'interno di programmi piu' ad alto livello. Un esempio: i driver HW hanno un nocciolo di assembler, di solito.

@Vi7o: l'81 è il mio (http://hwupgrade.it/forum/showpost.php?p=43720815&postcount=81).

Comunque di quello che hai scritto non ricordo di aver riscontrato qualcosa sul Tanenbaum, il Patterson, o qualche altro testo.

Per il resto, mi pare di capire che non hai avuto alcuna esperienza sull'argomento.

EDIT: Antonio m'ha fregato per 1 minuto. :p

Cazz..oo il Tanenbaum, lo ho ancora, che ricordi che mi hai tirato fuori, la programmazione del MIPS... ahaha che tempi!

Quanto detto Lonherz era grosso modo ciò che volevo dire.

Quello in cui sono stato spesso frainteso essendo pur sempre un ragionamento per lo più teorico che può benissimo distaccarsi dalla pragmantica praticità di tutti i giorni: è che una macchina a volte può essere semplice o semplice abbastanza da non giustificare l'utilizzo di un assemblatore che deve essere implemento ad hoc per quella macchina(e di conseguenza l'assembly)...forse è questo il punto dove non sono riuscito ad essere abbastanza chiaro(anche se ho fatto numerosi esempi in questo senso).
Non ho frainteso nulla, so bene di ciò che stiamo parlando altrimenti non mi sarei cimentato nella discussione, ho semplicemente estremizzato i concetti...e questo ha creato un pò di scompiglio...poi spesso sono state lette tra le righe di quello che scrivevo cose che non affermavo...essendo stata un discussione un pò lunga capisco anche che qualche post venisse perso per strada e non tutti avevano giustamente voglia/tempo di leggersi tutta la pappardella...
Con questo mi assumo le mie responsabilità, mi scuso e me ne tiro fuori:)

ciao, una curiosita' che mi si e' rinfocolata leggendo il thread: ma i famigerati demo in assembly che qualche era geologica fa giravano su macchine di classe molto-pre-pentium (e che se non ricordo male nacquero sotto amiga) e facevano cascare la mascella, posto che fossero scritti in assembly... era una necessita' per motivi prettamente tecnici o anche ad esempio ancora non esistevano altri linguaggi utili ad ottenere lo stesso risultato?
Sostanzialmente la seconda che hai detto, perché con l'assembly potevi scrivere codice molto più compatto e veloce rispetto a qualunque altro linguaggio (C incluso).

E, cosa non meno importante, potevi sfruttare in maniera precisa ogni singola locazione di memoria del sistema.

Che poi è esattamente quello che ho fatto nei giochi a cui ho lavorato per Amiga (Fightin' Spirit, pubblicato, e USA Racing, mai pubblicato): senza l'assembly non sarebbero stati possibili, a meno di rinunciare a diverse cose.
Premesso che mi ero già ritirato da questa discussione, per educazione quindi ti rispondo spero di essere il più esaustivo possibile:

Non mi sembra centri niente il caricamento in memoria con quanto abbiamo detto, che ovviamente avverrà per mezzo dello strumento di input previsto dalla macchina, non penso ci eravamo mai soffermati sull'IO sino ad ora.
Avevi affermato questo prima:

"Le macchine leggono solo il Linguaggio Macchina(binario), che poi "leggono" schede perforate(in binario) o listati(in binario) o cd(in binario) o pendisk(in binario) o nastri(in binario), dipende solo dall'interfaccia di lettura della suddetta macchina

Quindi in un ipotetica macchina che ha due ingressi di lettura:
1 - linguaggio macchina
2 - assembly

nel primo caso il codice sarà letto al volo, nel secondo sarà letto in assembly e tradotto in linguaggio macchina"

Nel momento in cui affermi che la macchina può leggere il linguaggio macchina, è ovvio che si pone il problema di come sarà stato generato.

In che modo pensi di generarlo?
Qui non ho capito la domanda
Parlavi di saper programmare allo stesso costo in assembly e linguaggio, il che è assolutamente impossibile: con l'assembly lavori di gran lunga più velocemente.

Ovviamente a parità di programma da realizzare.
Che io sappia il linguaggio macchina è binario o no??
No: può essere anche ottale o esadecimale, o con un'altra base, o con un mix di basi diverse. L'importante è che venga generato il codice oggetto che ci si aspetta.
anche se è un problema secondario piazzarlo in memoria visto che il risultato di LM e Assembly è lo stesso, lo faremo allo stesso modo
Non è un problema secondario. Se la macchina, come hai detto, è in grado di comprendere solo il linguaggio macchina, e questo deve stare in memoria, ci si pone il problema di come farglielo arrivare in quelle zone di memoria.

E, prima ancora, ci si pone il problema di come generare il codice binario.
è inutile gridare decontestualizzando la mia affermazione:
Non ho gridato: ho evidenziato, per mettere in risalto.
non continuate a dire che una volta compilato è la stessa cosa, perchè l'ho detto più volte che a prescindere dalla compilazione è la stessa cosa solo chè c'è un passaggio in più la compilazione attraverso l'assembler
Idem come sopra: se, a tuo dire, col linguaggio macchina ci sarebbe un passaggio in meno, ci spiegheresti in che modo verrebbe generato il codice oggetto/binario?

Esempio pratico: devi realizzare un programmino che dati due numeri interi a 8 bit senza segno ne faccia la somma, trascurando eventuali riporti, e la visualizzi.

Per semplicità si potrebbe prendere un PC col DOS in modalità 8086, visto che il problema si risolve con una manciata di istruzioni (e, dunque, in poco tempo), ma sei libero di scegliere la piattaforma che più ti aggrada.

Giusto per essere chiari, vorrei sapere in che modo scriveresti questo programma in linguaggio macchina evitando qualunque traduzione, e ovviamente in che modo lo faresti eseguire dalla macchina.

Quest'esempio taglierà la testa al toro.
qui sei tu che confondi assembler(può essere vista come una macchina astratta fisica o software) con assembly(linguaggio tradotto dall'assembler in linguaggio macchina), non mi sembra di aver confuso da nessuna parte questo punto...
Dove mi sarei confuso? Ho scritto chiaramente che l'assembler (da te citato) è un tool.

Poi ho specificato che l'assembly (dunque NON l'assembler) è un linguaggio (che ovviamente è quello che l'assembler riconosce per poi generare il codice oggetto).
la slide siccome è scritta con il comic sans non l'ho creata per forza io l'ho trovata in rete e sicuramente è di qualche corso universitario, la puoi riscontrare anche sui testi... e dovrebbe esplicare la suddivisione di un elaboratore in livelli con i rispettivi linguaggi, serviva semplicemente a far capire che i livelli in cui sono disposti non sono li tanto per e diceva soprattutto livello macchina sotto livello assembly, due livelli diversi,
E quindi solo per questo dovremmo essere d'accordo col contenuto?

Io non lo sono per le motivazioni che ho già ampiamente riportato.
qui però il tono che hai utilizzato mi è dispiaciuto mi dava tanto di "qualunque cosa dirai di qui in poi è una cavolata e non ti crederò nemmeno se mi dai prova che la Terra non è piatta..."
No, semmai dovresti porti il problema che non è che se una cosa la trovi su internet sia necessariamente vera. Questo anche nei corsi universitari, perché il docente potrebbe sbagliare. E magari uno studente potrebbe pure correggerlo...
Qui stai dicendo quello che io ho detto dall'inizio,
la velocità di esecuzione del codice generato è la stessa, solo che con l'assembly anche se decisamente più conveniente da parte tua facevi o meglio l'assembler faceva un passaggio in più, non ho mai detto da nessuna parte che è più bello o più figo scrivere in linguaggio macchina altrimenti non ci sarebbe stato bisogno dell'assembly
Il nocciolo della questione è che il passaggio serve anche col linguaggio macchina. Vedi sopra l'esempio.
sul Tanenbaum che forse è quello che descrive meglio e in modo più marcato i livelli dell'elaboratore trovi una slide simile a quella che avevo linkato dove l'assembly si trova a Livello 4, il linguaggio macchina al Livello 3 per favore però non iniziamo a discutere riguardo i livelli inferiori ti prego...
Non c'è bisogno, perché quei livelli riguarderanno sicuramente l'astrazione, che è un'altra cosa.

Che la macchina capisca e possa eseguire soltanto certe sfilze di uni e zeri è pacifico.

Il punto, però, è che col linguaggio macchina io posso scrivere codice ponendomi al suo stesso livello d'astrazione.

Solo che dovrà farglielo avere in qualche modo, e per questo motivo servirà sempre un "passaggio", come dici tu, esattamente come con tutti gli altri linguaggi (leggi: serve sempre un "traduttore" che generi l'apposito codice oggetto).
Spero di aver risposto a tutte le domande pendenti a questo punto anche se la maggior parte erano state ampiamente trattate in post precedenti, anzi alcune era doppie già nello stesso post.
Idem. E speriamo di aver chiarito tutto finalmente.
*PPS: ho pensato solo adesso che giustamente qualcuno mi potrebbe far notare che quello per l'assembly non è nemmeno un compilatore ma un assemblatore, infinitamente più semplice e veloce
Si tratta di una sottigliezza: definizione alla mano, un assemblatore è comunque un compilatore. ;)
Cazz..oo il Tanenbaum, lo ho ancora, che ricordi che mi hai tirato fuori, la programmazione del MIPS... ahaha che tempi!
Meglio il 68000: i MIPS sono troppo semplici. :stordita:

http://specialprogramsipe.altervista.org/images/foto49.jpg



:O




Csmklsnmknjlsml

No: può essere anche ottale o esadecimale, o con un'altra base, o con un mix di basi diverse. L'importante è che venga generato il codice oggetto che ci si aspetta.
ma no, il linguaggio macchina è binario per definizione.
sono tutti linguaggi isomorfi al linguaggio macchina

La codifica binaria è isomorfa alla struttura degli opcode, ma non è l'unica codifica utilizzata per de/codificare le istruzioni di un processore.

Basti aprire un manuale dell'architettura per verificare che quella privilegiata ormai è quella esadecimale, che consente di raggruppare più informazione in poco spazio, rendendo più semplice la scrittura o lettura dei byte (o word) che compongono le istruzioni.

Persino nei manuali più vecchi, come ad esempio quello di 8086, esistono tabelle per la decodifica e codifica delle istruzioni i cui byte sono codificati in esadecimale. Oltre ovviamente a contenere tabelle in binario per rappresentare la struttura degli opcode (che però nei manuali recenti non si usa più, e non si trova infatti).