Stai usando un browser non aggiornato. Potresti non visualizzare correttamente questo o altri siti web. Dovreste aggiornare o usare un browser alternativo.
ho una curiosità.
il linguaggio assembly è il linguaggio più vicino possibile al linguaggio macchina.
...ma puo essere comunque considerato un "linguaggio alto" in quanto non si scrive mica in 1-0 (binario)
la macchina deve comunque avere un compilatore giusto?
mettiamo che io ho un pc anni 80 e non ho internet per scaricare un compilatore..
come faccio a "programmarne uno?"
nel senso come si crea il compilatore di un linguaggio cosi basso?
Una cosa che mi ero scordato di dire e vedo che nessuno l'ha aggiunta. Soprattutto in merito a computer più vecchi (ma ancora oggi in uso, seppure molto sofisticati), in assenza di un assemblatore si utilizza un programma "monitor" (da non confondere con lo schermo del computer!!). Alcuni vecchi personal/home lo avevano addirittura integrato in ROM, vista l'esigua occupazione di spazio (per esempio l' Apple II, io usavo al tempo un compatibile CP/M con z80).
Il MONITOR è un programma anche piuttosto semplice da realizzare che può essere più o meno complesso, ma che di base consente di editare il contenuto delle celle di memoria (RAM e ROM) , scrivere dentro le celle, eseguire dei programmi e, in versioni più evolute, disassemblare il contenuto o scrivere direttamente in assembly.
Usare un monitor è molto illuminante per capire come funziona il computer, per scrivere programmi senza usare un assembler e soprattutto per indagare nel dettaglio su come è organizzato un computer.. infatti vengono usati per il debug e.. dagli hacker per scoprire i segreti più nascosti ;)
Per cui, la risposta alla tua domanda iniziale: se serve un compilatore da usare nei computer anni 80... No, direi che con un monitor puoi già fare tutto, anche eventualmente scrivere un assemblatore.
arrivati a questo punto in cui molti hanno risposto abbastanza deep.. mi verrebbe da chiedere se imparare "bene" l architettura di una cpu (anche vecchia come la 8086) e smanettare parecchio con linguaggio Assembly puo' portarmi effettivamente e SOSTANZIALMENTE ad avere una vision maggiore nel programmare ad alto Livello.
Attualmente sto smanettando con Python e qualche suo framework, conosco le basi del c++ e dei linguaggi di markup principali (html, css3)
rinnovo quindi la mia ultima domanda:
Puo' quindi saper smanettare a basso livello portare ad aver enormi (o comunque Sostanziali) benefici nel programmare ad alto livello?
mi verrebbe da chiedere se imparare "bene" l architettura di una cpu (anche vecchia come la 8086) e smanettare parecchio con linguaggio Assembly puo' portarmi effettivamente e SOSTANZIALMENTE ad avere una vision maggiore nel programmare ad alto Livello.
Naturale. C'è un piccolo libricino scritto da uno dei guru del settore ( Ulrich Drepper ) e titolato "What Every Programmer Should Know About Memory". Tratta principalmente i modelli di gestione della memoria di processori, sistemi operativi e runtime, ma scende ovviamente pure nei dettagli su come il processore manipola i dati. E la premessa dell'autore è proprio che, senza sapere queste cose, puoi essere al massimo un code monkey.
Cioè, mettere insieme quattro linee di codice che svolgano un'operazione, è relativamente facile. Far sì che quelle linee siano efficienti e corrette, è un altro paio di maniche.
Si, se si vuole realizzare software fatto bene. No, se si vuole solo mettere insieme qualcosa che risolva, in un modo o nell'altro, un problema. Ovviamente sto completamente escludendo le attività di debugging, che pure sono fondamentali per creare programmi senza crash e bug eccessivi. Senza un minimo di conoscenza delle attività a basso livello svolte da una CPU, la vedo difficile riuscire anche solo a capire cosa il debugger ti sta dicendo.
arrivati a questo punto in cui molti hanno risposto abbastanza deep.. mi verrebbe da chiedere se imparare "bene" l architettura di una cpu (anche vecchia come la 8086) e smanettare parecchio con linguaggio Assembly puo' portarmi effettivamente e SOSTANZIALMENTE ad avere una vision maggiore nel programmare ad alto Livello.
Attualmente sto smanettando con Python e qualche suo framework, conosco le basi del c++ e dei linguaggi di markup principali (html, css3)
rinnovo quindi la mia ultima domanda:
Puo' quindi saper smanettare a basso livello portare ad aver enormi (o comunque Sostanziali) benefici nel programmare ad alto livello?
Avere conoscenza del assembly aiuta a capire come “ragiona” l’hardware di un computer, ma non ti aiuta affatto nello scrivere meglio codice di linguaggi evoluti. Per scrivere un buon codice in Python o C# (per esempio) devi capire bene come funzionino quei linguaggi, saranno poi loro a ottimizzare il codice che scrivi trasformandolo in linguaggio macchina.
Bada bene, non sto dicendo che studiate assembly sia inutile. Negli anni 80 veniva ancora usato quando i compilatori non erano ottimizzati come adesso (io scrissi un sacco di codice per i processori della famiglia 68000). Adesso viene usato solo in pochissime situazioni e ovviamente a scopo didattico.
Integro la risposta sintetica di cui sopra, e condivido quanto detto da @Andretti60 nel precedente. Anch'io parlo per esperienza personale avendo "assemblato a mano" e disassemblato codice per z80 e mos6502 (MOS6510 del C64), usato "pesantemente" assembler per M68000 (Amiga e Atari ST principalmente) e lavorato con i80386/486..
Oggi mettere mano all'assembler pensando di "ottimizzare" del codice compilato è praticamente assurdo.. ma anche inutile, perché i compilatori sono già molto, ma molto avanzati nelle tecniche utilizzate per la compilazione. Inoltre le CPU sono talmente complesse che l'operazione manuale diventa un'impresa epica e anche dannosa. Inoltre i linguaggi di alto livello utilizzano già sistemi di ottimizzazione delle risorse e sono fatti appunto per astrarre dalle specifiche tecnologie delle macchine.
Imparare l'assembler di processori semplici può essere propedeutico per allenare la risoluzione di algoritmi e sviluppare capacità di sintesi ed economia nella scrittura del codice. Ci sono tecniche di programmazione che nel tempo, grazie alla grande velocità dei processori e alla disponibilità di risorse e memoria, sono andate drammaticamente perdute... Usare un numero minimo di variabili, ridurre la memoria utilizzata sfruttando i singoli bit per memorizzare informazioni, ridurre la lunghezza del codice,.inventare trucchi o strategie per raggiungere gli obiettivi sono modalità di pensiero tipiche di chi sa usare l'assembly.
arrivati a questo punto in cui molti hanno risposto abbastanza deep.. mi verrebbe da chiedere se imparare "bene" l architettura di una cpu (anche vecchia come la 8086) e smanettare parecchio con linguaggio Assembly puo' portarmi effettivamente e SOSTANZIALMENTE ad avere una vision maggiore nel programmare ad alto Livello.
Attualmente sto smanettando con Python e qualche suo framework, conosco le basi del c++ e dei linguaggi di markup principali (html, css3)
rinnovo quindi la mia ultima domanda:
Puo' quindi saper smanettare a basso livello portare ad aver enormi (o comunque Sostanziali) benefici nel programmare ad alto livello?
Caro @rob25111,
come avrai compreso, siamo su due livelli di astrazione molto diversi, i linguaggi denominati "evoluti" sono problem-oriented, le loro istruzioni non fanno riferimento alle operazioni macchina, mentre i linguaggi Assembler sono machine-oriented, collegati strettamente al microprocessore a cui si riferiscono e quindi vincolati al modo con cui la CPU esegue i comandi.
L'Assembly ha il vantaggio di produrre codice molto efficiente, con un run-time ridotto, per contro la stesura dei programmi, perlomeno quelli più "articolati", richiede tempi più lunghi, non tanto per la loro analisi, quanto per la gestione dei registri e dei tipi di dati, soprattutto quelli non elementari.
La programmazione a basso livello può essere utile per comprendere l'architettura di base di un microprocessore (peraltro già conosciuta, è scontato), le temporizzazioni dei vari segnali elettronici, gli interrupt, le subroutine e così via ma gli algoritmi di risoluzione sono più complicati da realizzare (a questo proposito suggerisco di usare i diagrammi di flusso per la visualizzazione grafica del flusso operativo) poiché implicano una maggiore concentrazione sui dettagli, dovendo ragionare in termini più strettamente "fisici" :asd:
Il vantaggio maggiore dei linguaggi evoluti è quello di aumentare la produttività da parte dei programmatori, magari a scapito dell'efficienza del codice (peraltro compensata dalla sempre maggiore potenza elaborativa dei computer) ma in ogni caso lo sviluppo di applicazioni è molto più rapido.
In sintesi, per rispondere alla tua domanda, se intendi andare "più a fondo" sulla struttura hardware/elettronica di un sistema a microprocessore, ti sollecito allo studio della programmazione "low level", utile, tra l'altro, per dare maggiore "peso" ai dettagli "algoritmici" più complessi, in caso contrario, volendo trascurare la parte fisica, è meglio orientarsi su un linguaggio più "evoluto".
A presto ;)
P.S. Con Python puoi "scrivere" un semplice assemblatore Z80, conoscendone la semplice architettura, ma anche nel C/C++ è possibile inserire codice Assembler (il cosiddetto Inline Assembler), ne ho parlato qui: https://forum.tomshw.it/threads/come-è-fatto-il-bios.575357/post-5448202 :sisi:
@gronag grazie mille per la risposta.
ho una domanda che mi sorge ora anche se off topic ma credo non valga la pena creare una nuova discussione in quanto mi basterebbe anche una risposta " semplice" .
Essendo in questo periodo vicino alla programmazione machine-oriented mi sorge un altro dubbio/ curiosità.
dov'è memorizzato il codice ASCII nella macchina ? o meglio a grandi linee come avviene la conversione? è tutto nella ROM ?è gestita dal OS?
p.s non voglio sembrare uno con domande superficiali ma sembra che mi frullino sempre domande ostiche.. sul web non ho trovato una risposta a questa domanda.. e neanche nei miei libri di testo da Superiori.. :(
Te lo ho già spiegato in un mio messaggio precedente ma cercherò di essere più chiaro.
Il codice scritto in linguaggio simbolico è un semplice file di testo. Dopo che lo si ha scritto, lo si dà “in pasto” a un programma chiamato “assemblatore” che “traduce” il codice simbolico in codice macchina, generando un file binario (chiamato “eseguibile”). L’assemblatore dipende da che processore e che sistema operativo si usano.
L’eseguibile viene fatto girare come qualsiasi altro programma, lo si chiama con il suo nome ed è poi compito del sistema operativo di leggere il file, metterlo in memoria (RAM) a un certo indirizzo di partenza, dopodiché il sistema operativo dice alla CPU “esegui il programma a partire da questa locazione di memoria” e a quel punto entra in gioco la CPU (e i suoi componenti interni)
Anche in questo caso ho cercato di semplificare al massimo.
Nell’altro mio messaggio ho spiegato come poi è compito della ALU di “eseguire” le istruzioni (è tutto fatto in hardware)
@gronag grazie mille per la risposta.
ho una domanda che mi sorge ora anche se off topic ma credo non valga la pena creare una nuova discussione in quanto mi basterebbe anche una risposta " semplice" .
Essendo in questo periodo vicino alla programmazione machine-oriented mi sorge un altro dubbio/ curiosità.
dov'è memorizzato il codice ASCII nella macchina ? o meglio a grandi linee come avviene la conversione? è tutto nella ROM ?è gestita dal OS?
p.s non voglio sembrare uno con domande superficiali ma sembra che mi frullino sempre domande ostiche.. sul web non ho trovato una risposta a questa domanda.. e neanche nei miei libri di testo da Superiori.. :(
Non trovi nulla perché stai parlando di qualcosa che appartiene ad un livello.(layer) di astrazione superiore.
Però ti consiglio ancora, se sei interessato a questi argomenti, di prenderti una pausa e d dedicarti (con molta pazienza) allo studio di qualche libro sull'argomento. Continuare con domande "spot" in questo thread non contribuisce a farti chiarezza, ma purtroppo, molta confusione.
Un testo, piuttosto impegnativo, ma un classico per studenti e soprattutto incentrato sugli argomenti che hai sollevato (codice assembly e unità di elaborazione hardware) è sicuramente il classico di Taunenbaum: "architettura dei calcolatori".. un libro usato per la didattica a livello universitario.
Ti consiglio di nuovo anche degli approcci più semplificati che quelli suggeriti per CPU x86.. ripeto, se incominci a studiare con uno Z80 o.un 6502 (che puoi anche sperimentare praticamente utilizzando dei banalissimi emulatori) il tutto ti sarà molto più chiaro.
La sola gestione della memoria con segmentazione e gli indirizzamenti del x86 rischierebbe di farti passare ogni entusiasmo!!! :)
Ricorda però che ci vuole pazienza e impegno, non sono cose da chiacchieretta da bar. E a volte anche un po' pallose perché l'assembly è arcigno nel dare soddisfazioni!
Ahi ahi, stai scivolando nel dubbio di cui ho scritto un pò di giorni fa. Non confondere il concetto di rappresentazione con quello di esistenza di un oggetto. La CPU vede la corrente, nient'altro. I byte, le loro rappresentazioni in codice ASCII, ecc... sono cose nostre, degli umani.
Gli editor ragionano in termini di codice ASCII ( e più recentemente Unicode ), perchè devono dar modo agli umani di modificare i dati. L'editor potrebbe benissimo mostrarti tutto in codice binario, ma non è che poi in memoria ci va lo zero col suo cerchietto o l'uno con la sua zampetta e il piede su cui poggia.
Cioè se prendi un'istruzione Assembly, la codifichi in binario e ti esce, che so, 10011000, non è che poi apri un file e ci scrivi quella sequenza e il processore la vede come l'istruzione che cercavi di esprimere.
Per questo consigliavo di partire da x86 ( 16 bit ) o Z80/6502 come suggerito dagli altri, magari 68k visto che va di moda pure nelle università. E realizza qualche programma, altrimenti questa confusione ti rimarrà.
@gronag grazie mille per la risposta.
ho una domanda che mi sorge ora anche se off topic ma credo non valga la pena creare una nuova discussione in quanto mi basterebbe anche una risposta " semplice" .
Essendo in questo periodo vicino alla programmazione machine-oriented mi sorge un altro dubbio/ curiosità.
dov'è memorizzato il codice ASCII nella macchina ? o meglio a grandi linee come avviene la conversione? è tutto nella ROM ?è gestita dal OS?
p.s non voglio sembrare uno con domande superficiali ma sembra che mi frullino sempre domande ostiche.. sul web non ho trovato una risposta a questa domanda.. e neanche nei miei libri di testo da Superiori.. :(
Guarda, caro @rob25111,
lo studio dei codici, della codifica e della decodifica delle informazioni è un classico problema di Cibernetica che è stato approfondito da autori quali Shannon e Hamming, in riferimento soprattutto alla trasmissione di tali informazioni.
Per il funzionamento di un sistema digitale è necessario che le informazioni del mondo esterno vengano codificate in parole binarie dal sistema, il quale, dopo l'elaborazione, le pone in uscita in una forma comprensibile.
Ora ho poco tempo, nel pomeriggio approfondiremo questi concetti :sisi:
A dopo ;)
Post unito automaticamente:
Eccomi qua,
come sai, un codice è formato da una serie di simboli (pensa alle lettere dell'alfabeto) e dalle loro combinazioni valide (pensa al vocabolario di una lingua).
Ora, tutti i codici in un computer utilizzano come alfabeto le cifre binarie 0 e 1 :asd:
Un codice può essere utilizzato in seguito ad un processo di codifica.
In che modo ?
Mettendo semplicemente in corrispondenza ciascun simbolo di un codice con una parola di un altro codice; ad esempio, il codice ASCII associa a ogni carattere alfanumerico una combinazione di 7 bit, oppure nel caso di un codice BCD ad ogni cifra decimale è associata una combinazione di 4 bit (ovviamente delle 16 combinazioni ne vengono utilizzate 10, le 6 rimanenti possono essere usate per altre codifiche o per la rilevazione e la correzione degli errori).
Lo standard ISO 646 utilizza la codifica US ASCII (ASCII americano) a 7 bit per rappresentare 128 caratteri.
E` possibile estendere il codice ASCII utilizzando 8 bit (256 caratteri diversi), secondo lo standard ISO 8859, per il supporto di altre lingue che usano alfabeti diversi (cirillico, arabo, ecc.).
Anche in questo modo, però, vengono trascurati gli ideogrammi delle lingue orientali e altri particolari simboli, per questo motivo è stato istituito lo standard Unicode a 16 bit (65536 caratteri), usato da Windows per memorizzare i nomi dei file e da Java per la codifica dei caratteri.
In seguito è stato definito lo standard UCS-4 (la codifica Unicode è UCS-2 a 2 byte) a 4 byte (in realtà si usano 31 bit, il primo bit è sempre 0, e quindi più di 2 miliardi di caratteri).
Tutti questi codici non sono perfettamente compatibili col codice ASCII poiché hanno un numero diverso di bit.
La codifica UTS è un tipo di codifica Unicode e UCS-4 (standard ISO 10646) che risulta perfettamente compatibile col codice ASCII in quanto il numero di byte è variabile da 1 a 6 per ogni carattere ma l'ordinamento viene mantenuto.
Nel codice UTF-8 viene utilizzato 1 byte per codificare i 127 caratteri dell'ASCII "ridotto" e tutti gli altri caratteri sono codificati secondo una logica multi-byte (da 2 a 6 byte), non c'è possibilità di confusione.
Venendo alla tua domanda, esistono specifici "chip" elettronici integrati, chiamati Encoder (codificatori), in grado di convertire alcune variabili in ingresso in un codice risultante generato in uscita: http://www.elemania.altervista.org/digitale/combinatorio/comb2.html :sisi:
Il processo inverso, quello di decodifica, viene attuato tramite circuiti "decoder" (decodificatori):
Di solito i decoder (che consentono il passaggio tra i vari codici) vengono usati per "pilotare" dispositivi optoelettronici come display a LED o a cristalli liquidi LCD (al fine di visualizzare informazioni sotto forma di caratteri alfanumerici).
A presto ;)
