Dall'assembly ai linguaggi di alto livello

  • Autore discussione Autore discussione Utente 125751
  • Data d'inizio Data d'inizio
Pubblicità
Il problema in realtà è dovuto al fatto che il codice a 16bit viene eseguito da OS Windows a 32bit e non dai 64bit (ci sono in realtà rarissime eccezioni su alcuni software in particolare).

Per curiosità: quali sono queste rarissime eccezioni ?

Non esiste un "e quindi a scrivere il contenuto della libreria nel programma"... mi è difficile anche contestare affermazioni simili. Non esiste nel senso che non è concepibile. Le librerie, intese come librerie di codice, servono proprio per svolgere determinati compiti. Oltretutto, anche nel tuo esempio di qualche post fa, utilizzavi librerie, ma erano native dell'OS; questo implica anche la non portabilità del codice che hai scritto (e non da un'architettura ad un'altra, ma proprio da un OS ad un altro).

Scriversi tutto e non utilizzare librerie sarebbe come prendere un auto e levare tutto, come la leva del cambio, il volante, i pedali... e per sterzare agire con una chiave direttamente sull'asse delle ruote.

Mi piacerebbe imparare e capire ad es. il codice contenuto nelle principali librerie ed header relativi al linguaggio C etc... Parto con Ms dos (intendo l' OS) così tra l' altro posso anche fare il confronto con i programmi assembly a 16 bit :)

Ho scoperto che anche sull' assembly si possono creare librerie e questa è una cosa hai dei pregi. Però al momento non ho la necessità di crearle/userle. Poi si vedrà.

Io, al momento, non ho la necessità delle portabilità del codice in linguaggio C da un OS ad un altro.

Le librerie e gli header permettono: di non scrivere sempre lo stesso codice, di risparmiare tempo e di avere un programma più corto. Però io attualmente non ho queste necessità visto che è a fini didattici etc...

L' esempio che hai fatto sull' auto non riguarda il discorso in questione. Secondo me scrivere (es. dentro Ms dos) quella parte di codice delle librerie (non .dll) e degli header necessari al programma che bisogna scrivere (usando il linguaggio C) sarebbe come smontare un auto e ed i relativi pezzi/componenti, smontare determinati singoli pezzi (es. motore, scatola del cambio etc..) per imparare e capire come è fatta,come funziona, per capire ed imparare come funzionano e sono fatti determinati componenti singolie, per avere consapevolezza di quello che ci sta facendo o/e si vuole modificare l' auto per renderla custom. Mi vengono in mente delle office che ad es. come base partono dalle auto vintage e poi le modificano e le personalizzano.

Ho pure scoperto ma con stupore (in senso positivo) che in C è possibile creare una propria libreria (.c) con il relativo header (.h) ^^
Nella bibbia del C ho visto ad es. che viene spiegato il codice delle librerie (.c) e degli header (.h) scritto in linguaggio C :)

Ovviamente chi ha necessità (o/e magari non vuole) di non riscrivere sempre lo stesso codice, di risparmiare tempo, di rendere il programma più corto, etc... ha la possibilità di farlo ed di ottenere dei vantaggi semplicemente includendo una o più header che programma.

Che cosa dimostrerebbe l'assenza di "int main"? E che vuol dire che non ha incluso librerie? https://docs.python.org/3/reference/import.html

Per librerie intendevo quelle principali.
Dimostra semplicemente che avrà avuto uno o più motivi affinchè il linguaggio avesse determinate caratteristiche. Non sto dicendo che questi motivi siano giusti oppure sbagliati.

Non si tratta di mancare di rispetto ai creatori del linguaggio, o a chi apprezza il C. Sono proprio le argomentazioni, in generale, che vacillano...
C è adatto alla programmazione di sistema.

Le parti in asm sono una minima parte, e si tratta di codice inline, scritto da C/C++; e per essere più precisi si tratta di parti delicate come push/pop di registri e context switch, o altre operazioni simili e non realizzabili (o meno convenienti) con linguaggi differenti da asm.

Come ho ripetuto sopra nei post precedenti, e com'è stato ricordato da un altro utente, ciascun linguaggio è nato per una ragione e la scelta da parte del programmatore dovrebbe essere dettata dalle necessità.
Quando si deve iniziare, è un altro discorso.

Ci sono delle cose a livello tecnico che devo ripassare mentre altre le devo studiare da zero o quasi mentre altre le devo approffondire. Sono tantissime cose.

il C non è l' unico linguaggio adatto alla programmazione di sistema.

Però ci sono delle cose su cui la penso diversamente da voi però rispetto il vostro pensiero :)

Prima ancora le parti in asm non erano una minima parte ed andando più indietro ancora veniva utilizzato solo l' assembly per la creazione di un O.S. Pensa ad es. all' 86 dos.

Infatti ogni linguaggio di programmazione è nato per determinati motivi.

Ci sono uno o più linguaggi che sono più avvantaggi per un determinato ambito rispetto ad altri.
Nel corso di questa discussione ho spiegato/menzionato le mie necessità.

Riprendo anche io la domanda di rctimelines, ed a mia volta te la pongo, per mia curiosità :)

Ho risposto sopra a questa domanda, nella precedente risposta.

Hai aperto un thread su programmazione, C, assembly, embedded, computing e non t'interessa programmare? Cioè pretendi di studiare a memoria un certo numero di libri e concludere che hai capito tutto? Onestamente non capisco qual è il tuo obiettivo.
Comunque Art of Assembly, lo leggi, lo segui, realizzi programmi e avrai un'idea molto precisa del funzionamento a basso livello dell'architettura x86. Oppure ancora più semplice e didatticamente valido "Programming from the Ground Up". E' per Linux, quindi devi installarti Linux in dual boot, su un pc di comodo, in una macchina virtuale. E' pure disponibile gratuitamente https://download-mirror.savannah.gnu.org/releases/pgubook/ProgrammingGroundUp-1-0-booksize.pdf

Ma ripeto, se parti con "non mi interessa imparare a programmare", francamente non so dov'è che vuoi andare a parare.

Nella frase che hai linkato non ho scritto che non mi interessa programmare ma che non mi interessa imparare a programmare ed è inteso in senso generale. Ho l' interesse (non l' ossesione) nello specifico ad imparare a programmare l' hardware in particolare quello dei pc, dei server e delle workstation e mi interessa imparare a programma in assembly partendo da 8008 ed 8086. Per il resto l' ho scritto nella/e risposta/e precedente/i.

Il secondo libro non lo conoscevo.

Appunto. La questione è: "messo di fronte ad un problema, riesci a trovare la soluzione algoritmica"? Scrivere codice è relativamente facile, basta conoscere gli strumenti che si stanno usando. Il difficile è immaginare la sequenza di operazioni che insieme implementano la soluzione ad un dato problema.

Purtroppo no a meno che non ci sono cose moolto semplice da realizzare. Come posso fare per migliorare la situazione considerando ad es. l' assembly ed il C (non linguaggi più astratti)?

Questa cosa mi lascia perplesso. Un problema è un problema e ha una soluzione algoritmica. Che poi venga codificata in Assembly, Python, Pascal, C o altro, è del tutto indifferente nella stragrande maggioranza dei casi. Se ti viene in mente un problema la cui soluzione potresti codificare in Assembly, cosa t'impedisce di provare a codificarla in un altro linguaggio?

La pensi diversamente da me, lo rispetto ed hai tutto il diritto di pensarla diversamente.

Io, personamente, non ci vedo una soluzione algoritmica ed un problema.

1) Mi viene in mente una cosa che mi piacerebbe fare oppure vedo una cosa che se mi interessa, mi piace o/e anche mi incuriosisce la voglio realizzare. Oppure mi può venire in mente una variante.

2) O ci provo da me, se riesco oppure mi affido a google o chiedo a qualcuno per prendere/avere ispirazione o/e sapere. Non mi interessa avere il tutto già fatto o quasi, perchè non impararei nulla o quasi e non ci sarebbe nessuna soddisfazione personale.

Il problema c'è quando ad es. non so come procedere, oppure capitano uno o più errori oppure capitano uno o più problemi lungo il percorso che mi bloccano o/e rallentano e quindi o non arrivo all' obiettivo finale oppure ci arrivo in ritardo. Ci sono anche quelle volte in cui ho sopravvalutato quello che voglio fare e li c'è il problema e la delusione finale.

A me interessa sia il percorso per arrivare a realizzare quello che decido/voglio, sia lo strumento/mezzo per farlo e sia ottenere il risultato finale che deve anche funzionare.

Al momento sto facendo cose semplici che in passato ho fatto con dei linguaggi ad alto livello però l' assembly è più vicino all' hardware, mi da più/moltà più consapevolezza di quello che sto facendo, mi piace e mi interessa. Ovviamente anche l' assembly come tutti i linguaggio hai suoi pro e contro.

Ho scoperto che c'è la possibilità di creare il proprio interrupt in ms dos e questa cosa mi piace :)

Una delle cose che vorrei fare in asm è stampare sullo schermo delle variabili numeriche o/e delle stringhe sullo schermo all' interno di ms dos senza usare gli interrupt per l' output video ma scrivendo istruzioni per programma direttamente la scheda video come avviene con la cpo. Non so se mi sono fatto capire :D

Nessun riassunto. In genere si legge, si capisce anche se solo parzialmente e poi si va ad implementare ed è quello il vero banco di prova.

Il programma non è affatto uguale al precedente. Qui il while è relativo solo all’incremento di nc. Poi esegue le condizioni su c (che ovviamente risulteranno false visto che c è necessariamente EOF). nw è poi incrementata.
Risultato quindi prevedibile: 0, 1, <numero di caratteri> che non è quello che il programma dovrebbe fare

Non ho capito perchè nel secondo programma che ho scritto il while è relativo solo all' incremento di nc.

Se faccio così invece così:

C:
int main()
          {
              int c,n1,nw,nc, state;
              state=OUT;
              n1=nw=nc=0;
              while ((c=getchar() )!=EOF)
              ++nc;
              if (c=='\n')
              ++n1;
              if (c=='  ' || c=='\n' || c=='\t')
              state=OUT;
              else if (state==OUT)
              state=IN;
              ++nw;      
              printf("%d %d %d\n",n1,nw,nc);

Ho linkato solo la parte centrale per sintetizzare però il resto è uguale.

Molto esplicativo del tuo atteggiamento al limite del comprensibile è l'ossessione, oltre che per l'assembly x86, anche il fatto che dici di "voler imparare e capire ms-dos" .. insistendo anche sulla versione 6 e 6.22... ???
Posso capire che per curiosità tu possa dire di essere interessato alla storia di questo "sistema operativo" nonostante tu ne parli immancabilmente insieme a linguaggi di programmazione. Ma dal punto di vista della pratica ciò è assolutamente inutile e nemmeno particolarmente interessante.. ci sono voluti 10 anni per liberarsi di un os che ormai era diventato un mostro! Non capisco davvero cosa tu voglia imparare così approfonditamente, e che non ti porterà a nulla neanche come cultura personale.
Insisto anche sulla fissazione per x86, considerando che ci sono molte altre architetture altrettanto se non più interessanti.
Quali sono le ragioni di queste ossessioni? Non mi puoi dire che ms-dos e x86 sono più simili al tuo modo di pensare perché saresti da ricovero istantaneo!

Nel mio atteggiamento non c'è nessuna ossessione.Non sono affatto ossessioni le cose ho menzionato. Ma che cavolo c' entra la somiglianza tra ms-dos ed x86 ed il mio modo di pensare :nono:

Ho semplicemente fatto un elenco indicando delle cose che mi interessano, che mi piacerrebbe fare, che mi incuriosiscono e che voglio capire.
Non ho insistito su quelle due versioni ma l' ho semplicemente menzionate per far capire da che pensavo di ripartire ora da una di quelle due. La scorsa settimana ho installato la versione 6.22 su una VM. Se poi sia meglio partire ad es. dalla versione 5.00 per me non c' è nessun problema. In passato avevo provato anche la versione 5.0 e per me anch' essa andava bene.

Come anche ad altre persone:

A) ci sono svariate cose che mi piacciono, mi interessano o/e che mi possono anche appassionare o/e farmi ritornare in mente ricordi, emozioni e nostalgia (può essere anche in senso positivo) etc... Penso di essere come minimo una persona eclettica.

B) ci sono cose che mi piacciono, mi interessano etc... di meno rispetto ad altre.

C) ci sono invece cose che non mi piacciono proprio, non mi interessano affatto, etc...

Il mio primo pc aveva ms dos e c' era installato doom. Mi ricordo che non aveva il lettore cd. Poi dopo del tempo ho scoperto che c' era pure installato Windows 3.1 .
Nel corso degli anni, quando non avevo più il primo pc, mi sono messo in determinati periodi sull' ms dos visto che mi piace, mi interessa e perchè voleva impare ad usarlo, volevo imparare i comandi e volevo capire come funzionava, qual'è la sua logica etc...

Ad es. per un periodo usavo un pc, dove avevo creato una partizione da 2gb su un hard disk, e il lettore floppy. Avevo comprato due pacchi di floppy. Avevo installato anche Windows 3.1. Ce li ho ancora e su alcuni ci sono ancora le etichette.

Avevo anche comprato il lettore floppy perchè il penultimo pc acquistato non c'è l' aveva.

Poi ad es. in un altro periodo ho usato un pc più vecchio (socket 478) che avevo. Comprai altri floppy come nuovi. Poi mi sono rimesso sul Qbasic Etc...

Nel 2015 presi un pc vintage che è più vecchio del primo pc (quello con Ms dos e Doom) che avevo. Monta ad es. l' 80286 ed anche il lettore floppy da 5 5¼-inch.

Avevo comprato anche un lettore floppy nuovo fondi di magazzino, per il pc socket 478 però non ho mai funzionato visto che molto probabilmente c'è un cortocircuito.

Ci sono altri acquisti che vorrei fare in futuro.

Pochissimi anni fa avevo scoperto che ad es. negli 70 e negli anni 80 c' erano i kit Intel, quelli di altri aziende e quelli di privati sia per programmare la cpu, sia per collegarla anche ad una breadboard per metterci led, resistenze etc.. e sia per assemblare un pc. Al giorno d' oggi ci sono dei kit (non di aziende) in vendita che sono recenti e nuovi su determinate cpu vintage.

A me piace ed interessa ad es. l' hardware pc/server vintage e non.

Per quanto riguarda ad es. le altre cpu vintage (non Intel)e i relativi assembly per vari motivi decisi di rimandare il tutto nel futuro (non prossimo) ma senza abbandonare le cpu Intel.

Per quanto riguarda l' assembly 8008 per il momento userò o un emulatore oppure installerò un vecchio OS (che supporti l' assembly 8008) su una VM. Ora non posso

l' MS dos non è l' unico sistema operativo che mi piace e mi interessa. Ci sono ad es, anche Windows 3.0/1.0, Windows 95/98, Windows XP, Non voglio mettere andare su Unix (quello vintage) e Linux per la programmazione per non aggiungere altre carne al fuoco

Conoscere la storia di ms dos, dei determinati linguaggi di programmazione, degli home computer, degli altri s.o. etc... è una cosa che è secondaria/terziaria per me.

Ho trovato una tua vecchia risposta (settembre 2017) che vorrei condividere:

"Intendo dire che un motivo può essere anche il piacere di volerlo fare, non necessariamente motivi pratici o utilitaristici.
Se per questo i motivi per studiare latini e greco ci sono e (ti svelo un segreto) non sono "lingue straniere" !!! :):):)

Penso però che aldilà del piacere per la conoscenza, mettersi ad imparare un linguaggio di programmazione debba essere una decisione ponderata perché conoscerlo non vuol dire riuscire a scrivere "hello world". Per cui non è che studi uno per imparare un altro. Per imparare il C ti serve impegno e dedizione, non capisco come fate a prendere tutto con tale leggerezza! L'assembler è una cosa ancor più complessa, non certo per le istruzioni del macro-assembler, ma per tutte le tecniche di programmazione degli algoritmi (e quella sorta di trucchi che si imparano con tanta esperienza) sia perché strettamente legato all'architettura di specifici microprocessori... "

L' ho presa da qui:

https://www.tomshw.it/forum/threads...liano-per-assembly.658768/page-2#post-6469834

Per MS-DOS credo abbia visto qualche listato in Assembly in giro e abbia letto del fatto che non implementa la modalità protetta, quindi lo vede come più bare metal degli altri.

Su x86 penso sia la popolarità, anche nei forum dedicati alla programmazione di sistemi operativi/bare metal.

Se però facesse due conti, sceglierebbe ARM, comprando una scheda come Raspberry e si cimenterebbe in questo https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/

Per ms dos invece ho spiegato in sintesi. sopra come stanno le cose.

Quelli che vedo bare metal per me sono ad es. ESXI, Xen, Kvm ed Hyper-V. Però riguardano i server.

La popolarità viene al secondo forse terzo posto per me.
Non sapevo che esistessero forum dedicati alla programmazione di sistemi operativi/bare metal.

Ma Arm ed il Raspberry non c' entrano assolutamente nulla con i pc. L' architettura e l' assembly sono totalmente diverse/i. Arm ed il Raspberry non sono compatibili con i sistemi operativi, i programmi, gli assemblatori, i compilatori per pc. I sistemi operativi ed i programmi che girano su Arm ed il Raspberry non sono compatibili con i pc (lasciando perdere le VM). Poi in più su arm con ho nessun interesse e non mi piace proprio.

Nel link che hai menzionato spiega come creare semplici sistemi operativi su Raspberry però non mi servono, non ho questa necessità su arm/raspberry, non sono compatibili su pc e devo per forza comprarmi il raspberry che a me personalmente non mi serve proprio, alla fine non ci farei nulla e rimarrebbe poi inutilizzato a prendere la polvere. Conosco gli utilizzi del raspberry ma non mi servono.

A giugno sono stato alla fiera dell' elettronica e ad es. ad uno stand vendevano anche Raspberry (diversi modelli) e non l' ho comprato per ciò che ho spiegato sopra.

Ritornando in topic come programma asm con Tasm ho fatto questo in questi ultimi giorni:

Codice:
.MODEL Small
.STACK 100H
.DATA

      at    DB 40     ;aperta tonda
      num1  DB 52     ;numero 4
      sim1  DB 43     ; +
      num2  DB 50     ;numero 2
                      ; +    
      num3  DB 56     ;numero 8
      sim2  DB 45     ; -
      num4  DB 53     ;numero 5
                      ; -
      num5  DB 49     ;numero 1
      ct    DB 41     ;chiusa tonda
      sim3  DB 61     ; =
      spac  DB 32     ;spazio
      res   DB 55     ;risultato 7
     
.CODE
.STARTUP
     
      mov AX,@DATA    ;copia in AX il contenuto del .DATA
      mov DS,AX       ;copia nel segmento dei dati,il contenuto del .DATA
       
      mov DL,at       ;copia il valore di res,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H
     
   
      mov DL,num1     ;copia il valore di num1,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H              
       
      mov DL,sim1     ;copia il valore di sim1,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H
     
      mov DL,num2     ;copia il valore di num2,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H      
 
      mov DL,sim1     ;copia il valore di sim1,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H  
     
      mov DL,num3     ;copia il valore di num3,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H        
           
      mov DL,sim2     ;copia il valore di sim2,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H          
           
      mov DL,num4     ;copia il valore di num4,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H          
     
      mov DL,sim2     ;copia il valore di sim2,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H
     
      mov DL,num5     ;copia il valore di num5,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H
     
      mov DL,ct       ;copia il valore di ct,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H      

      mov DL,sim2     ;copia il valore di sim2,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H
     
      mov DL,num5     ;copia il valore di num5,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H
     
      mov DL,sim3     ;copia il valore di sim3,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H
     
      mov DL,spac     ;copia il valore di spac,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H
                 
      mov DL,res      ;copia il valore di res,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H            
           
      mov AH,4CH      ;restituisce il controllo all' O.S
      int 21H        
     
END                   ;termina programma

Sinceramente seguo questo discorso solo per divertirmi :chupachup: Si e' partiti dal Basic (quello orignale) per arrivare a discutere il sesso degli angeli :)

Cibachrome, i problemi che hai sono dovuti al fatto che non hai abbastanza conoscenze di base, sarebbe come volere cambiare il motore di una auto senza sapere come costruire un motore. Vedi per esempi oquesta tua referenza:

L'articolo non dice che NON si deve usare il IF (ci mancherebbe ancora) ma come in certe situazioni sia molto meglio sostituirlo con metodologie OOP. L'esempio che fa e' classico, ed e' proprio un fondamento della programmazione a oggetti. Si definisce una interfaccia, dopodiche' si costruiscono diverse classi che la implementano. A seconda della situazione si utilizza una classe o un'altra, ma nel seguito le classi vongno viste solo attraverso la comune classe di base, per cui nessun IF viene richiesto. Ovvio che se NON si sa cosa voglia dire OOP (o se non se ne ha esperienza) si finisce con il non interpretare l'articolo correttamente.

Potevi pure rispondere alla risposta che ti avevo dato in precedenza, anzichè seguire questa discussione solamente per divertirti :)

Dopo il programma in GW-basic io volevo solamente un consiglio da voi per la scelta di un linguaggio di programmazione ed avevo indicato le caratterestiche affinchè mi poteste aiutare. Mi sono reso conto dopo che sarebbe stato meglio chiedere questo consiglio in futuro quando il livello sarebbestato più elevato. Non mi sarei mai immaginato che si sarebbe arrivati addirittura a pag 5. Rimanderò questa cosa in seguito/in futuro, quando il mio livello teorico/pratico sarà più alto.

Purtroppo so benissimo di non avere abbastanza conoscenze di base. Voglio ampliare questo conoscenze ed aumentare il mio livello teorico/pratico. Nella mia ultima risposta risposta ho indicato il percorso che ho scelto di intraprendere e gli obiettivi che mi sono prefissato.


Non avevo letto l' articolo ed il codice in quel link ma avevo solo dato un' occhiata molto superficiale e mi rendo conto ora di aver sbagliato. L' ultima frase che hai scritto non c' entra in questo caso.

Ho letto il codice ed ho visto che ci sono gli oggetti tipici della OOP (programmazione ad oggetti).

Leggendo l' articolo ad es. ho trovato questo che ho tradotto a mente:

"Have you ever wondered how IFs impact on your code? Avoid dangerous IFs and use Objects to build a code that is flexible, changeable and easily testable, and will help avoid a lot of headaches and weekends spent debugging! Share how to write effective code the easy way!

The goal of the Anti-IF Campaign is to raise awareness of the effective use of software design principles and practices, by first of all removing bad, dangerous IFs."

Se lo leggevo anzichè dare un occhiata molto superficiale, prima di linkare il link, mi sarei risparmiato una brutta figura e non avrei certo messo il link nella risposta.
 
Per curiosità: quali sono queste rarissime eccezioni ?
C:
int main()
          {
              int c,n1,nw,nc, state;
              state=OUT;
              n1=nw=nc=0;
              while ((c=getchar() )!=EOF)
              ++nc;
              if (c=='\n')
              ++n1;
              if (c=='  ' || c=='\n' || c=='\t')
              state=OUT;
              else if (state==OUT)
              state=IN;
              ++nw; 
              printf("%d %d %d\n",n1,nw,nc);
NO
L'istruzione while ha uno scope che è rappresentato dalle { }.
Questo:
C:
while(1)
{
    printf("Ciclo ");
    printf("Infinito\n");
}
È diverso da questo:
C:
while(1)
printf("Ciclo ");
printf("Infinito\n");
E per questo esiste la tabulazione, che usata ottimamente per differenziare i casi e produrre codice almeno leggibile produce questo:
C:
while(1)
    printf("Ciclo ");    //oppure while(1) printf("Ciclo ");
printf("Infinito\n");
Cavare delle partesi può rendere il codice in ogni caso compilabile, ma di certo l'esecuzione non è simile.
 
Per curiosità: quali sono queste rarissime eccezioni ?

Ad esempio degli installer. Questi installer sono riconosciuti da windows, il quale li converte in 32bit.

Mi piacerebbe imparare e capire ad es. il codice contenuto nelle principali librerie ed header relativi al linguaggio C etc... Parto con Ms dos (intendo l' OS) così tra l' altro posso anche fare il confronto con i programmi assembly a 16 bit :)

Ti basterebbe studiare C, ad esempio, per poter capire il codice contenuto in file header o in sorgenti. Posto che poi la comprensione dipende dalla complessità del codice e dalle competenze acquisite sino a quel momento.
Sull'altra parte di frase... non ho capito che cosa intendi dire (confronto tra assembly 16bit e cosa?).

Ho scoperto che anche sull' assembly si possono creare librerie e questa è una cosa hai dei pregi. Però al momento non ho la necessità di crearle/userle. Poi si vedrà.

Dalla frase si evince che non ti è chiaro cosa sia una libreria di un linguaggio.

Io, al momento, non ho la necessità delle portabilità del codice in linguaggio C da un OS ad un altro.

Questo perchè non programmi, probabilmente. Salvo applicazioni specifiche, dove si ha un target ben definito, il codice lo si scrive portabile.

il C non è l' unico linguaggio adatto alla programmazione di sistema.

Qui non si tratta di pensarla diversamente o no, si tratta di costatazioni. Ci sono anche OS scritti in altri linguaggi... ma io faccio riferimento ai sistemi operativi più utilizzati (dal kernel Linux e le distro, a Windows e Mac).
Eccezioni esistono ovviamente; un esempio potrebbe essere: http://kolibrios.org/it/index

Prima ancora le parti in asm non erano una minima parte ed andando più indietro ancora veniva utilizzato solo l' assembly per la creazione di un O.S. Pensa ad es. all' 86 dos.

Vista la complessità di ciò che utilizziamo, sono discorsi che non stanno molto in piedi.Prima ancora, ad esempio, non venivano usati calcolatori elettronici.
Non ha senso ripensare ai "bei vecchi tempi" (50 anni fa, diciamo), pensando a quanto fosse bello programmare. Ci volevano anche 2 giornate per vedere l'output di un programma, e di conseguenza ciò che si era riusciti a realizzare... ed in caso di errore e correzione, tutto doveva essere fatto girare nuovamente.

Il dato di fatto attuale, e non mi riferisco al 2018, ma agli ultimi 30 anni (o più) rimane proprio questo: asm non lo si utilizza se si può farne a meno.
E lo dico da simpatizzante dell'asm, oltretutto (avendo scritto anche qualcosa per divertimento).


Nel corso di questa discussione ho spiegato/menzionato le mie necessità.

Credo che nessuno di noi le abbia davvero capite però...
Un linguaggio di programmazione lo si studia se si ha intenzione di programmare, di realizzare qualcosa. Se è solo questioni di stili di scrittura, allora guarda anche i linguaggi esoterici. Se è questione di curiosità, allora sii curioso ed abbandonati alla curiosità, non ha senso cercare per mesi una cosa che non può esistere.

Nella frase che hai linkato non ho scritto che non mi interessa programmare ma che non mi interessa imparare a programmare ed è inteso in senso generale. Ho l' interesse (non l' ossesione) nello specifico ad imparare a programmare l' hardware in particolare quello dei pc, dei server e delle workstation e mi interessa imparare a programma in assembly partendo da 8008 ed 8086. Per il resto l' ho scritto nella/e risposta/e precedente/i.

Imparare a programmare l'hardware? A cosa ti riferisci? :boh:
Non so se ti è sfuggito quanto ho detto già più volte nei post precedenti: non hai accesso diretto a tutto ciò che vuoi, dal sistema operativo dovrai comunque passare. Sempre se parliamo di applicazioni per Windows/Linux.

Purtroppo no a meno che non ci sono cose moolto semplice da realizzare. Come posso fare per migliorare la situazione considerando ad es. l' assembly ed il C (non linguaggi più astratti)?

Studia ed applica.
Oltretutto pretendere di iniziare ad esempio da asm, senza avere capacità di problem solving, è davvero... pesante. Devi preoccuparti di risolvere le decine di problemi che ti pone il linguaggio, e poi il problema al quale devi trovare soluzione.

Ho scoperto che c'è la possibilità di creare il proprio interrupt in ms dos e questa cosa mi piace :)

Mi sa che ti sei fatto una strana idea. Non "crei" l'interrupt; crei la procedura per gestirlo, un interrupt handler, e lo "registri" (modificando la IVT; preferibilmente tramite procedura e non "a mano").

Una delle cose che vorrei fare in asm è stampare sullo schermo delle variabili numeriche o/e delle stringhe sullo schermo all' interno di ms dos senza usare gli interrupt per l' output video ma scrivendo istruzioni per programma direttamente la scheda video come avviene con la cpo. Non so se mi sono fatto capire :D

Considera che al 99% sei sotto ad un emulatore, sempre se non hai installato DOS su una macchina fisica...
Puoi scrivere nella memoria video, al limite (devi scrivere in una porzione di memoria ben specifica). Se ti interfacci con un OS devi utilizzare le chiamate di sistema dell'OS.
Tralasciando poi le inesattezze; ciò che vuoi fare è meglio se lo eviti... Del disegno si occupano DOS e BIOS (evito di addentrarmi sul come).
 
Nella frase che hai linkato non ho scritto che non mi interessa programmare ma che non mi interessa imparare a programmare ed è inteso in senso generale.

Non esiste la programmazione in senso stretto. Programmare è innanzitutto ragionare algoritmicamente, il resto sono solo dettagli implementativi. Quindi o si ha intenzione di programmare ( imparando a ragionare per algoritmi e studiando le necessarie tecnologie ) o non la si ha.


Purtroppo no a meno che non ci sono cose moolto semplice da realizzare. Come posso fare per migliorare la situazione considerando ad es. l' assembly ed il C (non linguaggi più astratti)?

E allora è inutile fare discussioni sul sesso degli angeli e sulle parantesi se sono quadre, tonde o graffe. Devi prendere un linguaggio, il più ad alto livello possibile ( Python è consigliatissimo ), e implementare programmi finchè non riesci a ragionare per algoritmi. E no, i linguaggi da considerare non c'entrano nulla, sono solo strumenti secondari rispetto alla capacità di produrre soluzioni algoritmiche. Senza queste non c'è linguaggio che tenga, perchè nessun linguaggio risolverà mai il problema al posto tuo.



La pensi diversamente da me, lo rispetto ed hai tutto il diritto di pensarla diversamente.
Io, personamente, non ci vedo una soluzione algoritmica ed un problema.

Non è questione di pensarla in un modo o in un altro. Esistono delle tappe obbligate. E si, si tratta di problemi e soluzioni ( nel senso logico-matematico del termine ). Che poi vuoi risolvere solo i problemi che t'interessano piuttosto che quelli commissionati da un cliente o da un datore di lavoro, è irrilevante.



Ho scoperto che c'è la possibilità di creare il proprio interrupt in ms dos e questa cosa mi piace :)

Ok, ma tutto questo riguarda la semplice conoscenza dell'implementazione ( a livello logico ) dell'hardware. Però tu stesso hai scritto che il tuo problema è la logica algoritmica e quella non riguarda linguaggi, interrupt, bare metal e quant'altro. E soprattutto è l'aspetto fondamentale. Per cui puoi decidere di restare sulla programmazione dell'hardware, ma devi comunque imparare a pensare da informatico.

e Linux per la programmazione per non aggiungere altre carne al fuoco

Appunto. Stai mettendo troppa carne al fuoco, col rischio di creare un pastrocchio da cui non si esce. Secondo me dovresti dedicarti innanzitutto alla logica algoritmica, metterti su Python, andare su un sito tipo Project Euler ed implementare le soluzioni ai problemi ivi proposti. Dopo di che avrai almeno la capacità di analizzare, scomporre e risolvere i problemi.

Quelli che vedo bare metal per me sono ad es. ESXI, Xen, Kvm ed Hyper-V. Però riguardano i server.

Definizione sbagliata. Bare metal è qualunque pezzo di codice che gira direttamente interfacciandosi con l'hardware, senza mediazioni. Dunque i kernel dei sistemi operativi ( MS-DOS compreso ) sono programmi bare metal.

Non sapevo che esistessero forum dedicati alla programmazione di sistemi operativi/bare metal.

Certo che esistono https://wiki.osdev.org/Expanded_Main_Page

Ma Arm ed il Raspberry non c' entrano assolutamente nulla con i pc. L' architettura e l' assembly sono totalmente diverse/i.

ARM è una famiglia di architetture di processori e ci si può creare anche un notebook https://www.tomshw.it/novena-un-computer-portatile-hardware-open-source-44051

Ma il punto non è questo. Il Raspberry PI è un computer completamente programmabile alla pari di un PC. Non userà x86 ma non cambia il fatto che sia altrettanto istruttivo studiarne l'implementazione.

Arm ed il Raspberry non sono compatibili con i sistemi operativi, i programmi, gli assemblatori, i compilatori per pc. I sistemi operativi ed i programmi che girano su Arm ed il Raspberry non sono compatibili con i pc (lasciando perdere le VM).

Linux e Windows girano su ARM. Compresi tanti programmi applicativi per questi due sistemi operativi.


Conosco gli utilizzi del raspberry ma non mi servono.

In uno dei post precedenti hai scritto che t'interessa l'elettronica. Gli utilizzi maggiori del Raspberry riguardano proprio la costruzione di oggetti elettronici microcomputerizzati. La cosiddetta elettronica embedded.

Ritornando in topic come programma asm con Tasm ho fatto questo in questi ultimi giorni:

Codice:
.MODEL Small
.STACK 100H
.DATA

      at    DB 40     ;aperta tonda
      num1  DB 52     ;numero 4
      sim1  DB 43     ; +
      num2  DB 50     ;numero 2
                      ; +  
      num3  DB 56     ;numero 8
      sim2  DB 45     ; -
      num4  DB 53     ;numero 5
                      ; -
      num5  DB 49     ;numero 1
      ct    DB 41     ;chiusa tonda
      sim3  DB 61     ; =
      spac  DB 32     ;spazio
      res   DB 55     ;risultato 7
   
.CODE
.STARTUP
   
      mov AX,@DATA    ;copia in AX il contenuto del .DATA
      mov DS,AX       ;copia nel segmento dei dati,il contenuto del .DATA
     
      mov DL,at       ;copia il valore di res,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H
   
 
      mov DL,num1     ;copia il valore di num1,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H            
     
      mov DL,sim1     ;copia il valore di sim1,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H
   
      mov DL,num2     ;copia il valore di num2,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H    

      mov DL,sim1     ;copia il valore di sim1,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H
   
      mov DL,num3     ;copia il valore di num3,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H      
         
      mov DL,sim2     ;copia il valore di sim2,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H        
         
      mov DL,num4     ;copia il valore di num4,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H        
   
      mov DL,sim2     ;copia il valore di sim2,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H
   
      mov DL,num5     ;copia il valore di num5,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H
   
      mov DL,ct       ;copia il valore di ct,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H    

      mov DL,sim2     ;copia il valore di sim2,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H
   
      mov DL,num5     ;copia il valore di num5,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H
   
      mov DL,sim3     ;copia il valore di sim3,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H
   
      mov DL,spac     ;copia il valore di spac,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H
               
      mov DL,res      ;copia il valore di res,in DL
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H          
         
      mov AH,4CH      ;restituisce il controllo all' O.S
      int 21H      
   
END                   ;termina programma

Ed in quel programma noto la totale mancanza di un ciclo, che semplificherebbe il codice enormemente. Ovviamente imparare ad usare i cicli partendo dall'Assembly è lavoro piuttosto oneroso mentalmente. Quindi perchè ti ostini ad usare lo strumento sbagliato? Tu sei nella fase di apprendimento e ti serve un linguaggio il più espressivo possibile ( ritiro in ballo Python ). Perchè vuoi farti del male? Perchè ostinarsi ad usare un bazooka per uccidere farfalle? Tu sei nella fase in cui devi plasmare il tuo cervello per pensare algoritmicamente e dovresti usare lo strumento che più ti semplifica la vita, non quello che te la rende un inferno.
 
NO
L'istruzione while ha uno scope che è rappresentato dalle { }.
Questo:
C:
while(1)
{
    printf("Ciclo ");
    printf("Infinito\n");
}
È diverso da questo:
C:
while(1)
printf("Ciclo ");
printf("Infinito\n");
E per questo esiste la tabulazione, che usata ottimamente per differenziare i casi e produrre codice almeno leggibile produce questo:
C:
while(1)
    printf("Ciclo ");    //oppure while(1) printf("Ciclo ");
printf("Infinito\n");
Cavare delle partesi può rendere il codice in ogni caso compilabile, ma di certo l'esecuzione non è simile.

Nel libro ho visto ad es. un programma dove il while non ha lo scope quindi la differenza c'è ma devo capire ed imparare cosa cambia ai fini del programma.

Riguardo alla tabulazione sto all' inizio e sto piano piano facendo pratica trovando la mia strada. Ovviamente bisogna rispettare le regole e le libertà del rispetto linguaggio che si ha davanti.

In questa discussione mi avete detto che in C le due parentesi graffe all' interno di un funzione sono obbligatorie visto che servono al compilatore. Sulle altre parentesi graffe non mi avete detto nulla e quindi io pensavo che non fossero obbligatorie. Devo imparare in quali casi, se ci sono, non è obbligatorio inserire altre parentesi graffe. Sto ancoora all' inizio dei 2 libri (1a e seconda edizione).

Ad esempio degli installer. Questi installer sono riconosciuti da windows, il quale li converte in 32bit.

Mi piacerebbe saperne di più e mi piacerebbe sapere cosa succede per i 64 bit però lascio perdere queste due cose ora perchè altrimenti metto altra carne sul fuoco e non va bene.

Ti basterebbe studiare C, ad esempio, per poter capire il codice contenuto in file header o in sorgenti. Posto che poi la comprensione dipende dalla complessità del codice e dalle competenze acquisite sino a quel momento.
Sull'altra parte di frase... non ho capito che cosa intendi dire (confronto tra assembly 16bit e cosa?).

Ho riprovato, giorni fa, con Pascal ma l' ho rimollato.
Ora sono invece all' inizio del libro (prima e seconda edizione) dei 2 autori del C e tentare di andare avanti con le pagine.

Per gli header e le librerie .C ci sono per caso degli argomenti che non vanno fatti? Lo chiedo perchè non lo so e non voglio fare di testa mia.

Confronto in Ms dos (ad es. 6.22) tra programmi in asm 8086 con Tasm e programmi in C (fino al C90) su Ms dos (l' O.S). Tutto questo a fini didattici, per interesse personale ed hobby.

Dalla frase si evince che non ti è chiaro cosa sia una libreria di un linguaggio.

A grandi linee credo che mi è chiaro. Però considera che nel mio percorso di apprendimento tra gli argomenti da fare, ho inserito: imparare cos'è la libreria in un linguaggio (sono serio).

Questo perchè non programmi, probabilmente. Salvo applicazioni specifiche, dove si ha un target ben definito, il codice lo si scrive portabile.

Io non ho l' esigenza che i programmi siano compatibili su Unix e linux. Parlo per me non per tutte le altre persone.
Parlo sempre per me: non devo programmare su Unix e Linux e non uso altri assemblatori ed i compilatori compatibili Solo su Unix e Linux.
Non ho assolutamente nulla contro Unix e Linux.

Qui non si tratta di pensarla diversamente o no, si tratta di costatazioni. Ci sono anche OS scritti in altri linguaggi... ma io faccio riferimento ai sistemi operativi più utilizzati (dal kernel Linux e le distro, a Windows e Mac).
Eccezioni esistono ovviamente; un esempio potrebbe essere: http://kolibrios.org/it/index

Il fatto di pensarla diversamente o no ovviamente non era riferito a questa cosa qui.
Io prima facevo riferimento sia ai sistemi operativi che hanno fatto di più la storia e sia ai sistemi operativi Windows e Linux.
Poi ho fatto riferimento ai linguaggi che esistono per la programmazione di sistema, indipendentemente dalla loro fama (es. Rust).

Non conoscevo quell' OS. Ho visto che in parte hanno utilizzato asm ^^

Vista la complessità di ciò che utilizziamo, sono discorsi che non stanno molto in piedi.Prima ancora, ad esempio, non venivano usati calcolatori elettronici.
Non ha senso ripensare ai "bei vecchi tempi" (50 anni fa, diciamo), pensando a quanto fosse bello programmare. Ci volevano anche 2 giornate per vedere l'output di un programma, e di conseguenza ciò che si era riusciti a realizzare... ed in caso di errore e correzione, tutto doveva essere fatto girare nuovamente.

Il dato di fatto attuale, e non mi riferisco al 2018, ma agli ultimi 30 anni (o più) rimane proprio questo: asm non lo si utilizza se si può farne a meno.
E lo dico da simpatizzante dell'asm, oltretutto (avendo scritto anche qualcosa per divertimento).

Le prime 2 frasi non le ho capite molte dato che sono sintetiche.

Io penso sia al passato che al futuro e questo vale per tutte le cose che mi interessano o/e mi piacciono o/e mi incuriosiscono etc...
Ogni periodo storico ha i suoi pregi e difetti, ha cose belle e cose brutte. Queste cose sono pure soggettive.
Lo sapevo che eri simpatizzante assembly visto che sei l' autore della guida "CPU:Hardware e linguaggio macchina".
Per hobby o/e passatempo o/e piacere personale, se vuoi, puoi tranquillamente andare avanti con l' assembly e la scrittura di programmi :)
Non è la discussione giusta per parlare di queste cose. Andiamo avanti.

Credo che nessuno di noi le abbia davvero capite però...
Un linguaggio di programmazione lo si studia se si ha intenzione di programmare, di realizzare qualcosa. Se è solo questioni di stili di scrittura, allora guarda anche i linguaggi esoterici. Se è questione di curiosità, allora sii curioso ed abbandonati alla curiosità, non ha senso cercare per mesi una cosa che non può esistere.

Qualcuno, delle cose, credo che le abbia capite.

Concordo sulla seconda frase che si applica anche ai linguaggi esoterici.
Nel mio caso non è solo questione di stili di scrittura. Poi sono una persona curiosa di natura.
Non so se questo linguaggio che cerco esista, oppure mi è passato davanti e non ci ho fatto caso però ho rimandato la ricerca in seguito o nel futuro visto il livello teorico/pratico che ho ora.

Imparare a programmare l'hardware? A cosa ti riferisci? :boh:
Non so se ti è sfuggito quanto ho detto già più volte nei post precedenti: non hai accesso diretto a tutto ciò che vuoi, dal sistema operativo dovrai comunque passare. Sempre se parliamo di applicazioni per Windows/Linux.

Ad es. Asm, al Bios, al chipset, ai driver, al bootloader, assemblatore, cpu, scheda video etc...

Io non parlo di Unix e Linux.
Pensa a Ms dos e a Windows fino ad es. Me (no 2000 e successivi)
So ad es. di non aver accesso a tutte la parti di un processore. Il resto lo devo/voglio imparare.
L' accesso all' hardware ed i sistemi operativi sono cose che voglio e devo imparare ^^

Studia ed applica.
Oltretutto pretendere di iniziare ad esempio da asm, senza avere capacità di problem solving, è davvero... pesante. Devi preoccuparti di risolvere le decine di problemi che ti pone il linguaggio, e poi il problema al quale devi trovare soluzione.

Riguardo alla prima frase, va bene :)

Non c'è nessuna pretesa da parte mia. Ti è sfuggito il mio percorso di apprendimento riguardante la programmazione da quando iniziai.

Ho fatto delle ricerche specifiche ed ho capito che ho sbagliato, per es., ad escludere ad es la materia "algoritmi e strutture dati".

Nel mio caso per quanto riguarda il problem solving il discorso è un po' complesso.

Ho letto in passato cose riguardanti il problem solving ma per me non c'è nessun problema ad andare avanti. Nella domanda che ho fatto a Pabloski ho menzionato ad es. anche il linguaggio C.

Il livello di pesantezza e di difficoltà di ogni linguaggio di programmazione e dei relativi argomenti ed aspetti (sintassi e semantica compresi/e) è soggettivo e varia da persona a persona.

Dimentichi quei casi dove, secondo me, non c'è un problema ma ad es. un' idea che si vuole realizzare e mettere in pratica.

Mi sa che ti sei fatto una strana idea. Non "crei" l'interrupt; crei la procedura per gestirlo, un interrupt handler, e lo "registri" (modificando la IVT; preferibilmente tramite procedura e non "a mano").[/QUOTE]

Il titolo dice "Create your own interrupt",
Poi dice: "
DOS has left a few interrupts open for us to use if we would like, so let's grab one and point it at our code.
Once we have written the code for the interrupt, we can make a TSR to set the interrupt vector and then stay resident.

We write our code for the interrupt to do anything as long as we don't call another interrupt. We also can have the layout
like the other interrupts where there is a service number in AH. See the code for an example.

We use some similar code from Interrupt Vectors to find the first
unused interrupt. We will start with int 34h. On most machines, this interrupt is the first unused interrupt, while the ones
before are used for misc. things and we won't even bother them.

We then can set the interrupt vector to point to our code via the INT 21h service.

Then call service 31h of INT 21h to Terminate and Stay Resident."

Considera che al 99% sei sotto ad un emulatore, sempre se non hai installato DOS su una macchina fisica...
Puoi scrivere nella memoria video, al limite (devi scrivere in una porzione di memoria ben specifica). Se ti interfacci con un OS devi utilizzare le chiamate di sistema dell'OS.
Tralasciando poi le inesattezze; ciò che vuoi fare è meglio se lo eviti... Del disegno si occupano DOS e BIOS (evito di addentrarmi sul come).

Quali sono i limiti di una VM su cui ci è installato Ms dos?
Nel caso posso tranquillamente installare ms dos su una macchina fisica.

Posso scrivere nella memoria video (scrivendo in una porzione di memoria ben specifica) all' interno di Ms dos che gira su una macchina fisica?

Giorni fa ho scoperto che Ms dos ha le sue API (chiamate Ms Dos API) e che hanno origine dalle API dell' 86 dos.

Se ho detto delle inesattezze mi piacerebbe essere corretto.
Perchè è meglio se lo evito? Se ti riferisci al fatto che non ho il livello teorico/pratico adatto allora non c'è problema, sospendo questa cosa e la riprendo quando avro i requisiti.

Facendo ricerche ho saputo che anche il bios ha le sue API.
C'è qualcosa che non ha queste API? :D

E allora è inutile fare discussioni sul sesso degli angeli e sulle parantesi se sono quadre, tonde o graffe. Devi prendere un linguaggio, il più ad alto livello possibile ( Python è consigliatissimo ), e implementare programmi finchè non riesci a ragionare per algoritmi. E no, i linguaggi da considerare non c'entrano nulla, sono solo strumenti secondari rispetto alla capacità di produrre soluzioni algoritmiche. Senza queste non c'è linguaggio che tenga, perchè nessun linguaggio risolverà mai il problema al posto tuo.

Nella prima frase hai generalizzato.

Io sono abituato alla matematica dove le parentesi si aprono a sinistra e si chiudono a destra, si aprono e si chiudono nella stessa riga e non si utilizzano 2 parentesi dello stesso tipo appiccicate. Ad es. in C la parentesi graffe sono un problema per me visto che mi fanno confondere/intrecciare gli occhi.

Nel programma in C, preso dal libro, l' ho modificato per renderlo più leggibile ed ordinato e mi sono trovato un po' meglio. Però non sapevo che in certi programmi ci fosse l' obbligo di inserire altre 2 o 4 parentesi graffe all' interno delle altre due. Poi il fatto che il programma veniva compilato e funzionava mi ha tratto in inganno. Il mio livello non mi aveva permesso di capire se il risultato finale del programma fosse giusto oppure no.
Quello delle parentesi e quell' riguardanti gli algoritmi non sono gli unici problemi che ho.

Il consiglio/metodo che mi hai dato nella seconda frase già lo sapevo. Non prenderla a male però. Se ti ho fatto quella domanda specifica è perchè ne cerco un altro (metodo/percorso) che sia adatto a me e che mi permetta di migliorare e che consideri gli altri problemi che ho. Non esiste un consiglio/metodo oggettivo che sia adatto a quasi tutti oppure a tutti.

Ci sono delle eccezioni riguardo all' ultima frase (quella dopo la virgola) però il punto non è ovviamente questo quindi andiamo avanti.

Non è questione di pensarla in un modo o in un altro. Esistono delle tappe obbligate. E si, si tratta di problemi e soluzioni ( nel senso logico-matematico del termine ). Che poi vuoi risolvere solo i problemi che t'interessano piuttosto che quelli commissionati da un cliente o da un datore di lavoro, è irrilevante.

Per le tappe dipende dal percorso che si fa. Esistono anche i percorsi personalizzati.
Riguardo ai problemi e soluzioni (in senso logico/matematico) io la penso diversamente da te. Ho spiegato più volte cosa intendo quindi andiamo avanti.

Se ci saranno uno o più clienti e se mi proporranno in futuro (non prossimo) qualcosa che mi interessa o/e incuriosisce o/e mi piace potrei anche accettare il lavoro o il progetto.

Ok, ma tutto questo riguarda la semplice conoscenza dell'implementazione ( a livello logico ) dell'hardware. Però tu stesso hai scritto che il tuo problema è la logica algoritmica e quella non riguarda linguaggi, interrupt, bare metal e quant'altro. E soprattutto è l'aspetto fondamentale. Per cui puoi decidere di restare sulla programmazione dell'hardware, ma devi comunque imparare a pensare da informatico.

La logica algoritmica non è l' unico problema che ho e nel mio caso non viene al primissimo posto.

La logica algoritmica e pensare agli algoritmi etc.. nel mio caso dipendono dalla conoscenza di determinati argomenti , dal linguaggio, dalla sintassi del linguaggio, dal livello di astrazione dall' hardware, dal espressività del linguaggio, dal livello di consapevolezza su ciò che ci sta facendo o che si dovrà fare, dalla conoscenza e dall' uso dei metodi e delle tecniche.

Mi sono reso conto di aver sbagliato ad ignorare e ad evitare la materia "algoritmi e strutture dati" e le materie che nel titolo riportano la parola: algoritmo o algoritmi. Poi "DisplatchCode" mi ha fatto notare che c'è anche il problem solving a cui non avevo pensato e che è un altro argomento/materia che nel mio caso è da tenere in considerazione e che mi piacerebbe continuare. Le devo includere nel mio percorso didattivo.

Es. ho letto nella discussione relativa ai libri consigliati per programmare, che una ragazza aveva consigliato ad es. che quando c'è un problema, si può scomporre in più parti in modo da risolvere la prima parte, poi quella dopo e così via. Questo consiglio lo trovo molto utile.

Rimango sulla programmazione dell' hardware, sulle architetture Intel Pre-X86 ed X86 (al momento solo su l' Intel 8008 ed Intel 8086) e sul linguaggio C. Farò anche una o più materie che ho menzionato nella penultima frase.
Per determinate cose devo ripassare degli argomenti di matematica o/e colmare le eventuali lacune.

Un' altra cosa importantissima, specie per me, è la pratica in cui la percentuale in rapporto a quella teoria dev' essere maggiore e non di poco.

Considera che non mi interessa diventare un informatico e quindi fare un percorso da autodidatta tipo il corso di laurea in informatica. Ci sono materie, presenti nel corso di laurea in informatica, che non ci sono in ingegneria informatica, in ingegneria dei sistemi informatici, in ingegneria dell' informazione e nell' ingegneria elettronica.

Appunto. Stai mettendo troppa carne al fuoco, col rischio di creare un pastrocchio da cui non si esce. Secondo me dovresti dedicarti innanzitutto alla logica algoritmica, metterti su Python, andare su un sito tipo Project Euler ed implementare le soluzioni ai problemi ivi proposti. Dopo di che avrai almeno la capacità di analizzare, scomporre e risolvere i problemi.

Con la frase che ho scritto intendevo dire che per programmare non vado su Unix, Linux (e derivati) e non mi metto ad imparare cose riguardanti la programmazione su questi O.S. i relativi compilatori, assemblatori etc.. che girano su questi O.S. E' una decisione che avevo preso in passato.

Sto facendo una scaletta ed un percorso per non mettere troppa carne sul fuoco. Voglio utilizzare un metodo.

Il consiglio che mi hai dato con me non funziona. Poi i linguaggi come ad es. Python o Ruby non funzionano proprio con me per risolvere gli esercizi oppure realizzare programmini che mi vengono in mente perchè ad es. sono molto ad alto livello, sono molto astratti, molto espressivi etc...

Definizione sbagliata. Bare metal è qualunque pezzo di codice che gira direttamente interfacciandosi con l'hardware, senza mediazioni. Dunque i kernel dei sistemi operativi ( MS-DOS compreso ) sono programmi bare metal.
Certo che esistono https://wiki.osdev.org/Expanded_Main_Page

Ti ringrazio per avermi corretto e del fatto che ho imparato una cosa nuova. Il sito nel link l' ho messo ora tra i preferiti. ^^

ARM è una famiglia di architetture di processori e ci si può creare anche un notebook https://www.tomshw.it/novena-un-computer-portatile-hardware-open-source-44051
Ma il punto non è questo. Il Raspberry PI è un computer completamente programmabile alla pari di un PC. Non userà x86 ma non cambia il fatto che sia altrettanto istruttivo studiarne l'implementazione.
Linux e Windows girano su ARM. Compresi tanti programmi applicativi per questi due sistemi operativi.
In uno dei post precedenti hai scritto che t'interessa l'elettronica. Gli utilizzi maggiori del Raspberry riguardano proprio la costruzione di oggetti elettronici microcomputerizzati. La cosiddetta elettronica embedded.

Le architetture arm sono totalmente differenti rispetto a quelle Pre-X86, X86 ed X86-64. Anche i relativi assembly lo sono. Per pc intendevo queste 3 architetture.

Secondo me il Raspberry PI non è un pc. Il fatto che si possa programmare compreso anche in assembly beh è una cosa positiva (specie in assembly) però è totalmente diverso. Bisogna considerare anche i limiti hardware e questo vale anche in generale per le board ed i veri pc.

I sistemi operativi che girano sulle 3 piattaforme che ho menzionato non sono affatto compatibili con il Raspberry PI.
Sul Raspberry PI sono state create delle versioni apposite per ARM che quindi sono compatibili su ARM, sono ridotte per quanto riguarda determinate funzionalità, programmi etc..., sono molto più leggere etc...
Es. c'è Raspbian (basato su Debian Linux) oppure Windows 10 IoT (deriva da Windows 10 per pc).
Quasi tutti i programmi per pc non sono compatibili con il Raspberry PI. Il resto dei programmi girano grazie ad un emulatore.

Ti sei dimenticato che ti avevo corretto perchè dopo che avevo menzionato l' elettronica, tu hai pensato che mi riferissi all' embedded e all' IoT ma io poi ti ho spiegato che non mi riferivo all' embedded e all' IoT.
Comunque lasciamo perdere, nel mio caso, altre architetture, altri assembly, l' embedded e l' IoT. Andiamo avanti.

Ed in quel programma noto la totale mancanza di un ciclo, che semplificherebbe il codice enormemente. Ovviamente imparare ad usare i cicli partendo dall'Assembly è lavoro piuttosto oneroso mentalmente. Quindi perchè ti ostini ad usare lo strumento sbagliato? Tu sei nella fase di apprendimento e ti serve un linguaggio il più espressivo possibile ( ritiro in ballo Python ). Perchè vuoi farti del male? Perchè ostinarsi ad usare un bazooka per uccidere farfalle? Tu sei nella fase in cui devi plasmare il tuo cervello per pensare algoritmicamente e dovresti usare lo strumento che più ti semplifica la vita, non quello che te la rende un inferno.

Il programma l' ho fatto così perchè vado per gradi e non ho nessuna fretta. Sono contento e soddisfatto del programmino che ho realizzato ma dall' altra però avevo notato che è un po' ripetitivo e lungo ed infatti in seguito lo voglio assolutamente migliorare. Ad es. avevo pensato a creare una macro. Terrò presente anche l' aggiunta di un ciclo per ridurre la lunghezza del codice come mi hai consigliato.

Ti sei dimenticato qual' è stato il mio percorso di apprendimento da quando iniziai, fino ad ora e quindi cosa feci, quali problemi incontrai etc...
Io non avevo imparato ad usare i cicli partendo dall' assembly e nemmeno partendo dal C.

Purtroppo non hai capito qual' è lo strumento ed il percorso che sono giusti, adatti a me e che funzionano. Ti sono sfuggiti quali sono i miei obiettivi, interessi e gli altri problemi che ho.

Ma io non sto utilizzando nessun bazooka.

Secondo me, non c' è questo strumento che mi rende la vita un inferno.

Il livello di semplificazione e quello di complicazione variano a seconda dell' argomento presente nel linguaggio, della caratteristica presente nel linguaggio, della sintassi che ha quel linguaggio, della semantica che ha, della persona che c'è davanti, delle abitudini che ha, delle esigenze o/e obbiettivi che ha, del livello che ha questa persona etc...

Nel mio caso ad es. i linguaggi molto astratti, a livello molto alto o/e molto espressivi non mi semplificano affatto la vita, non funzionano con me, sono totalmente fuori strada e mi confondono. Per il resto l' ho scritto sopra e poi nell' ultima parte della risposta a DispatchCode.

L' 8008, la sua architettura e il suo assembly (emulatore cpu oppure un O.S. 8 bit su una VM) per determinate cose mi semplificano la vita rispetto all' 8086.

Prima, in questa discussione mi avevi dato l' ok sull' assembly e mi avevi consigliato, nel corso delle risposte, vari libri ed in più anche quello sull' architettura dei calcolatori e quello sugli argoritmi e strutture dati.

Ho trovato delle discussioni questo forum nella sezione programmazione ed ho letto diverse risposte. Ho fatto una cernita:

Opera Snapshot_2018-07-15_235508_www.tomshw.it.webpOpera Snapshot_2018-07-16_000253_www.tomshw.it.webpOpera Snapshot_2018-07-16_000718_www.tomshw.it.webpOpera Snapshot_2018-07-16_001548_www.tomshw.it.webpOpera Snapshot_2018-07-16_002211_www.tomshw.it.webpOpera Snapshot_2018-07-16_002519_www.tomshw.it.webpOpera Snapshot_2018-07-16_003338_www.tomshw.it.webpOpera Snapshot_2018-07-16_004353_www.tomshw.it.webpOpera Snapshot_2018-07-16_005241_www.tomshw.it.webpOpera Snapshot_2018-07-16_103140_www.tomshw.it.webpOpera Snapshot_2018-07-16_110450_www.tomshw.it.webpOpera Snapshot_2018-07-16_131940_www.tomshw.it.webpOpera Snapshot_2018-07-16_184825_www.tomshw.it.webpOpera Snapshot_2018-07-16_185912_www.tomshw.it.webp


Per il momento ho pensato di lasciar perdere la parte: dall' algoritmo al linguaggio di programmazione. Tra l' altro non credo di avere proprio un problema con questa parte (però non ci metto la mano sul fuoco). Mi dedico invece alla parte: dall' idea (o problema in determinati casi) all' algoritmo. Pensavo di dedicarmi ad es. all' introduzione agli algoritmi o/e agli algoritmi. Finisco di raccogliere libri/dispense elettroniche, farò una cernita, penserò ad un metodo didattico (perchè mi serve) e farò una scaletta.

Poi farò pratica sia perchè è necessaria e sia perchè ne ho bisogno visto che nel mio caso la percentuale della pratica è maggiore di quella della teoria. Suppongo che esistano ad es. libri intermedi e avanzati però li scanso e sinceramente non so se in seguito o nel futuro li prenderò in considerazione. Non so fino a che punto voglio arrivare però per ora l' importante per me è migliorare ed iniziare a fare algoritmi semplici poi si vedrà.

Ora ho capito a grandi linee cos'è un algoritmo a cosa serve, e perchè si studia. Stessa cosa credo anche per la struttura dati. al momento sono sono arrivato alla cima della punta dell' iceberg.
 
Ultima modifica da un moderatore:
Il titolo dice "Create your own interrupt",
Poi dice: "
DOS has left a few interrupts open for us to use if we would like, so let's grab one and point it at our code.
Once we have written the code for the interrupt, we can make a TSR to set the interrupt vector and then stay resident.

We write our code for the interrupt to do anything as long as we don't call another interrupt. We also can have the layout
like the other interrupts where there is a service number in AH. See the code for an example.

We use some similar code from Interrupt Vectors to find the first
unused interrupt. We will start with int 34h. On most machines, this interrupt is the first unused interrupt, while the ones
before are used for misc. things and we won't even bother them.

We then can set the interrupt vector to point to our code via the INT 21h service.

Then call service 31h of INT 21h to Terminate and Stay Resident."
Mi sembra abbastanza chiaro il significato, non crei nessun interrupt. Ne usi uno libero, già esistente e ci abbini il codice che vuoi tu.
Comunque, per me è inutile pensare agli interrupt, assembly, DOS, librerie e header e via cosi se non sai nemmeno a cosa servano le parentesi graffe in un linguaggio. Decidi un punto di partenza e da li parti. Se non sai cosa scegliere, guarda uno dei tanti corsi di laurea in informatica in italia e vedi le materie insegnate.
 
Nel libro ho visto ad es. un programma dove il while non ha lo scope quindi la differenza c'è ma devo capire ed imparare cosa cambia ai fini del programma.

Se il while ha una sola istruzione, non servono parentesi. Lo scope è comunque del while in quel caso.

Riguardo alla tabulazione sto all' inizio e sto piano piano facendo pratica trovando la mia strada. Ovviamente bisogna rispettare le regole e le libertà del rispetto linguaggio che si ha davanti.

In questa discussione mi avete detto che in C le due parentesi graffe all' interno di un funzione sono obbligatorie visto che servono al compilatore. Sulle altre parentesi graffe non mi avete detto nulla e quindi io pensavo che non fossero obbligatorie. Devo imparare in quali casi, se ci sono, non è obbligatorio inserire altre parentesi graffe. Sto ancoora all' inizio dei 2 libri (1a e seconda edizione).

Non devi limitarti ad apprendere "a macchinetta", ma a comprendere il significato di ciò che hai di fronte. Lo scope può essere di una funzione o di un ciclo, oppure di un costrutto condizionale (come l'if).

Queste cose le apprendi se inizi davvero a studiare un linguaggio. Poi le sintassi "vanno e vengono"...

Mi piacerebbe saperne di più e mi piacerebbe sapere cosa succede per i 64 bit però lascio perdere queste due cose ora perchè altrimenti metto altra carne sul fuoco e non va bene.

Ciò che ho descritto avviene proprio per i 64bit. Un 32bit esegue codice a 16bit.

Per gli header e le librerie .C ci sono per caso degli argomenti che non vanno fatti? Lo chiedo perchè non lo so e non voglio fare di testa mia.

Non so nello specifico a cosa ti riferisci. A quali argomenti fai riferimento?

Il fatto di pensarla diversamente o no ovviamente non era riferito a questa cosa qui.
Io prima facevo riferimento sia ai sistemi operativi che hanno fatto di più la storia e sia ai sistemi operativi Windows e Linux.
Poi ho fatto riferimento ai linguaggi che esistono per la programmazione di sistema, indipendentemente dalla loro fama (es. Rust).

Non so se tra 10 anni i sistemi operativi saranno scritti in Rust; posso solo dirti in cosa sono scritti ora, in generale.

Io penso sia al passato che al futuro e questo vale per tutte le cose che mi interessano o/e mi piacciono o/e mi incuriosiscono etc...
Ogni periodo storico ha i suoi pregi e difetti, ha cose belle e cose brutte. Queste cose sono pure soggettive.
Lo sapevo che eri simpatizzante assembly visto che sei l' autore della guida "CPU:Hardware e linguaggio macchina".
Per hobby o/e passatempo o/e piacere personale, se vuoi, puoi tranquillamente andare avanti con l' assembly e la scrittura di programmi :)
Non è la discussione giusta per parlare di queste cose. Andiamo avanti.

Invece è esattamente in topic: era tutto riferito all'attuale utilizzo, allo scopo del linguaggio in sè.

Ad es. Asm, al Bios, al chipset, ai driver, al bootloader, assemblatore, cpu, scheda video etc...

Io non parlo di Unix e Linux.
Pensa a Ms dos e a Windows fino ad es. Me (no 2000 e successivi)
So ad es. di non aver accesso a tutte la parti di un processore. Il resto lo devo/voglio imparare.
L' accesso all' hardware ed i sistemi operativi sono cose che voglio e devo imparare ^^

Aspetta che mi ripeto, precisando... :D
Se vuoi studiare per interesse, allora concordo pienamente.
Se ti riferisci alla programmazione vera e propria invece, le cose sono un pò diverse. Il BIOS non lo programmi tu, i chipset (quali chipset poi?) nemmeno, il bootloader... volendo potresti anche scriverlo, un assemblatore anche, programmare una CPU (? il microcode non lo programmi tu), la scheda video non la programmi a tua discrezione etc etc.
Per farti un'idea sulle schede video, dai solo un occhio a VGA (ai tempi del DOS, per intenderci).


Il livello di pesantezza e di difficoltà di ogni linguaggio di programmazione e dei relativi argomenti ed aspetti (sintassi e semantica compresi/e) è soggettivo e varia da persona a persona.

Perdonami, ma visto che non programmi, non puoi affermare cose come questa...
Puoi trovare più o meno difficile l'apprendimento di un linguaggio in base anche al paradigma di programmazione utilizzato; ma nessuno potrebbe sostenere che asm sia più semplice rispetto a Java o C#; già in C, devi preoccuparti della gestione della memoria, in asm devi preoccuparti di tutto. Ad esempio: un conto è implementare un grafo ed effettuare una ricerca usando Java, un altro conto è invece implementare un grafo in asm.

Dimentichi quei casi dove, secondo me, non c'è un problema ma ad es. un' idea che si vuole realizzare e mettere in pratica.

Da anni, quando posso, mi dedico a progetti privati. L'idea, quando si concretizza, già quando si è in fase di progettazione, ti porta inevitabilmente a scontrarti con qualche problema da risolvere; se vuoi vedere l'idea prendere forma, devi saper risolvere quei problemi.
Il software in generale, consente di risolvere problemi o semplificare operazioni (ad esempio una calcolatrice, tanto per fare un esempio stupido).

Il titolo dice "Create your own interrupt",
Poi dice: "
DOS has left a few interrupts open for us to use if we would like, so let's grab one and point it at our code.
Once we have written the code for the interrupt, we can make a TSR to set the interrupt vector and then stay resident.

We write our code for the interrupt to do anything as long as we don't call another interrupt. We also can have the layout
like the other interrupts where there is a service number in AH. See the code for an example.

We use some similar code from Interrupt Vectors to find the first
unused interrupt. We will start with int 34h. On most machines, this interrupt is the first unused interrupt, while the ones
before are used for misc. things and we won't even bother them.

We then can set the interrupt vector to point to our code via the INT 21h service.

Then call service 31h of INT 21h to Terminate and Stay Resident."

Ti è già stato fatto notare l'errore.
Esistono due tipi di interrupt: hardware e software. Sotto DOS è il PIC ad occuparsi dell'hardware (master e slave PIC); in seguto è nato l'APIC.
Quelli software li invochi tu, sotto DOS, usando INT. Queste routine (ISR, Interrupt Service Routine) sono installate dal BIOS e dal DOS in fase di startup. La tabella che le gestisce si chiama IVT (Interrupt Vector Table), che ha 256 entrate. Non sono tutte usate, infatti, come dice il testo che hai incollato tu stesso, l'utente può creare sue routine. Puoi anche sostituirne di esistenti - sempre sotto DOS.

Quali sono i limiti di una VM su cui ci è installato Ms dos?
Nel caso posso tranquillamente installare ms dos su una macchina fisica.

Posso scrivere nella memoria video (scrivendo in una porzione di memoria ben specifica) all' interno di Ms dos che gira su una macchina fisica?

Giorni fa ho scoperto che Ms dos ha le sue API (chiamate Ms Dos API) e che hanno origine dalle API dell' 86 dos.

Se ho detto delle inesattezze mi piacerebbe essere corretto.
Perchè è meglio se lo evito? Se ti riferisci al fatto che non ho il livello teorico/pratico adatto allora non c'è problema, sospendo questa cosa e la riprendo quando avro i requisiti.

Facendo ricerche ho saputo che anche il bios ha le sue API.
C'è qualcosa che non ha queste API? :D

Io ho fatto riferimento ad un emulatore, non ad una macchina virtuale.
Con un emulatore, dipende dall'implementazione specifica. Visto che emuli, l'importante è che ti comporti allo stesso modo... poi il funzionamento specifico, potrebbe anche non essere identico all'originale.

Ovviamente si, puoi. La memoria specifica ha un in dirizzo ben definito. Vale anche per gli emulatori, che devono per forza attenersi a queste regole per far funzionare i programmi che fanno girare (ne sono piuttosto sicuro, in quanto ne stavo scrivendo uno, che ho interrotto... e che sto provando a riprendere).

DOS ha appunto i servizi, per effettuare molte operazioni.

Ti dicevo di evitae in quanto non puoi farlo. La stampa la fai tramite ISR del DOS o del BIOS, o scrivendo appunto nella RAM Video (nell'area specifica).
Se ti riferisci al disegno delle lettere, dei caratteri, lascia perdere. Dicevo questo in quanto dovresti occuparti di disegnare i px su schermo (nell'ipotesi più semplice leggendo una bitmap).

Tutto ha delle API. Non potrebbe essere diversamente. Senza quelle routine, che sono a basso livello, l'interfacciamento con l'hardware sarebbe decisamente poco astratto. Ci sono parecchi livelli sotto al sistema operativo, come il microcodice.

I driver, che citavi sopra, non credere abbiano accesso diretto all'hardware. Quelli user mode, hanno gli stessi privilegi delle applicazioni comuni; gli altri, che girano in kernel mode, hanno maggiori privilegi ma sono in ring 1/2 (meno privilegiati del kernel, ma lo spazio di indirizzi è in realtà quello... ecco perchè, tanto per fare un esempio, quando crasha un driver sotto Windows (e quando sono buggati) compare la famosa BSOD (ed anche questa può comparire per diversi fattori specifici... ma ora si, sono OT)).
 
...
Io sono abituato alla matematica dove le parentesi si aprono a sinistra e si chiudono a destra, si aprono e si chiudono nella stessa riga e non si utilizzano 2 parentesi dello stesso tipo appiccicate. Ad es. in C la parentesi graffe sono un problema per me visto che mi fanno confondere/intrecciare gli occhi.

...
Nel mio caso non è solo questione di stili di scrittura. ...
Veramente no. Le parentesi anche nella matematica non devono necessariamente stare nella stessa riga, quando diventa troppo lunga si "va a capo" rispettando certe regole che occorre conoscere e rispettare.

I linguaggi di programmazione sono simili, hanno le loro regole, se NON le rispetti non fanno quello che tu voglia facciano (se va bene ti danno error di compilazione). Le regole non hanno uno "stile", se il linguaggio prevede le parentesi graffe, DEVI usare le parentesi graffe. E' la prima cosa che si impara in in linguaggio, il suo vocabolario (ossia le keyword, il "for" lo devi scrivere "for" e non "pippo"), la sua grammatica (come unire le parole chiavi per formare una istruzione), la sua sintassi. Lo "stile" si riferisce solo al modo di programmare, che dipende da persona a persona, per esempio c'e' chi preferisce usare un ciclo, altri preferiscono usare una forma ricorsiva, altri preferiscono creare una classe con un metodo di iterazione automatica e cosi' via.

Per le parentesi, la regola del C e' che per ogni parentesi aperta ne debba corrispondere una chiusa, e possono inserirsi tra loro a piacere. Il metodo classico e' quello di mettere le parentesi "corrispondenti" nella stessa colonna (ossia usando la stessa indentazione), in questo modo si "vede" subito ad occhio quali siano, vedi esempio sotto. Questo perche' a differenza di altri linguaggi, la indentazione nel C e' libera, in quanto le istruzioni vengono terminate dal punto e virgola (e quindi le puoi spezzare in piu' righe) e ogni "gruppo" di istruzioni e' racchiuso tra parentesi graffe. Queste sembrerebbero limitazioni forti, ma ti assicuro che rendono sia la scrittura la lettura del codice molto piu' facile che altri linguaggi. Prendi Python e Visual Basic per esempio, scrivere un programma senza un editore appositamente specializzato e' quasi impossibile, mentre in C puoi usare un semplice editore di testo.
Codice:
public void main()
{
    for(;;)
    {
        if()
        {
        }
        else
        {
        }
    }
}
 
Per le parentesi, la regola del C e' che per ogni parentesi aperta ne debba corrispondere una chiusa

E tutto quello che si trova tra due parentesi graffe corrispondenti è all'interno del medesimo scope, cioè contesto. Con questa puntualizzazione credo che cibachrome non abbia bisogno di altro per capire come, quando e dove mettere le parantesi. speriamo...
 
E tutto quello che si trova tra due parentesi graffe corrispondenti è all'interno del medesimo scope, cioè contesto. Con questa puntualizzazione credo che cibachrome non abbia bisogno di altro per capire come, quando e dove mettere le parantesi. speriamo...
si, ma non e' sempre cosi' semplice come sembra, questo e' uno degli aspetti del C (e dialetti) che non mi piace, ossia un formalismo vacillante.
Prendi questo esempio:
Codice:
int k[10];
for (int i = 0; i < 10; i++)
{
    k[i] = 0;
}
qui la variabile 'i' e' dichiarata nelle parentesi tonde (definizione) di un ciclo for, il cui "corpo" (contesto) e' invece nelle parentesi graffe. Qui sembrerebbe che la variabile 'i' sia definita (e quindi valida) solo all'interno delle parentesi tonde (la "definizione" del ciclo) mentre invece e' valida pure nel "corpo" (le parentesi graffe). Siamo quindi in n caso dove le parentesi "da sole" non definiscono uno "scopo" (contesto).
Questo perche' in questo casi "definizione" e "corpo" appartengono allo stesso contesto proprio come la definizione dei parametri di una funzione:
Codice:
int funzione(int parametro)
{
    int  i = parametro;
    //
}
Chi e' abituato a questa convenzione non ci fa caso, ma all'inizio si rimane confusi se si e' dei formalisti. Il C originale (K&R) infatti non prevedeva la dichiarazioni di variabili locale all'interno di un contesto che non fosse una funzione.

Ma questi sono sofismi :) occorrebbe parlarne con un bel boccale di birra in mano (o, essendo programmatori, una bella tazza di caffe' bollente, come sto facendo io adesso...)
 
qui la variabile 'i' e' dichiarata nelle parentesi tonde (definizione) di un ciclo for, il cui "corpo" (contesto) e' invece nelle parentesi graffe. Qui sembrerebbe che la variabile 'i' sia definita (e quindi valida) solo all'interno delle parentesi tonde (la "definizione" del ciclo) mentre invece e' valida pure nel "corpo" (le parentesi graffe).
In realtà non c'è ambiguità: nelle specifiche (e nei manuali del linguaggio) è detto che una variabile dichiarata in questo modo ha validità per tutta l'istruzione; per quanto riguarda il C, se non ricordo male, questo è vero solo dalla versione C99 (nel C di standard precedente la dichiarazione non si poteva fare). Invece per Java/C++ è sempre stato possibile la dichiarazione "al volo" nei cicli.
In Javascript è una baraonda (variabili dichiarate anche in corpi molto "interni" che risultano visibili ovunque)
 
Mah, a parte le nostre discussioni accademiche, direi che Chibachrome ha le idee parecchie confuse su molti argomenti e non li sta approfondendo seriamente. Come faccio ad esserne sicuro? Per questo motivo https://www.hwupgrade.it/forum/showpost.php?p=41368151&postcount=1

Dopo 4 anni non ha trovato modo di studiarsi un pò l'architettura x86? Purtroppo mi dà l'impressione di chi si approccia ad un problema partendo dalla conclusione che lui vorrebbe e poi cerca di ricostruire il percorso a ritroso.

Un pò come il discorso che un linguaggio X per lui è il male perchè a sentimento non gli piace la sintassi. Temo non comprenda che prima di lui sono venuti fior fiori di matematici ed ingegneri che l'informatica l'hanno creato partendo da interruttori e schede perforate. E le scelte che di volta in volta hanno fatto hanno un senso e che c'è un lungo tragitto evolutivo che ha portato agli strumenti e alle tecniche che abbiamo oggi. Davvero si può pensare di reinventare l'informatica senza minimamente studiare ( a fondo ) l'esistente? Siamo tutti noi meglio di Turing? Ne dubito.
 
Mah, a parte le nostre discussioni accademiche, direi che Chibachrome ha le idee parecchie confuse su molti argomenti e non li sta approfondendo seriamente. Come faccio ad esserne sicuro? Per questo motivo https://www.hwupgrade.it/forum/showpost.php?p=41368151&postcount=1

Dopo 4 anni non ha trovato modo di studiarsi un pò l'architettura x86? Purtroppo mi dà l'impressione di chi si approccia ad un problema partendo dalla conclusione che lui vorrebbe e poi cerca di ricostruire il percorso a ritroso.

Un pò come il discorso che un linguaggio X per lui è il male perchè a sentimento non gli piace la sintassi. Temo non comprenda che prima di lui sono venuti fior fiori di matematici ed ingegneri che l'informatica l'hanno creato partendo da interruttori e schede perforate. E le scelte che di volta in volta hanno fatto hanno un senso e che c'è un lungo tragitto evolutivo che ha portato agli strumenti e alle tecniche che abbiamo oggi. Davvero si può pensare di reinventare l'informatica senza minimamente studiare ( a fondo ) l'esistente? Siamo tutti noi meglio di Turing? Ne dubito.
Io immagino che sia questa la tipologia di ragionamento che fa di solito :asd:
83v7y91zud-ehi-io-ho-windows-7-a-32bit-ma-ho-scaricato-un-gioco-che-mi-chiede-64bit-come_b.webp
 
Update:

@Andretti60 alla fine avevo capito le parentesi e ti ringrazio per la spiegazione :)

Mah, a parte le nostre discussioni accademiche, direi che Chibachrome ha le idee parecchie confuse su molti argomenti e non li sta approfondendo seriamente. Come faccio ad esserne sicuro? Per questo motivo https://www.hwupgrade.it/forum/showpost.php?p=41368151&postcount=1

Dopo 4 anni non ha trovato modo di studiarsi un pò l'architettura x86? Purtroppo mi dà l'impressione di chi si approccia ad un problema partendo dalla conclusione che lui vorrebbe e poi cerca di ricostruire il percorso a ritroso.

Un pò come il discorso che un linguaggio X per lui è il male perchè a sentimento non gli piace la sintassi. Temo non comprenda che prima di lui sono venuti fior fiori di matematici ed ingegneri che l'informatica l'hanno creato partendo da interruttori e schede perforate. E le scelte che di volta in volta hanno fatto hanno un senso e che c'è un lungo tragitto evolutivo che ha portato agli strumenti e alle tecniche che abbiamo oggi. Davvero si può pensare di reinventare l'informatica senza minimamente studiare ( a fondo ) l'esistente? Siamo tutti noi meglio di Turing? Ne dubito.

Alla fine non c'è l' ho fatta con il C e l' ho abbondonato e non stavo diventando una bella persona e sarebbe stato peggio.

Avevo abbandonato la programmazione e mi sono interessato ad altro. Tra l' altro con l' architettura dell' 8086 e con il codice asm avevo visto che c' era altro sotto che non sapevo e dovevo studiare. Anche li mi sono arenato e tra l' altro una persona su un forum mi ha scoraggiato considerando il suo comportamente (non la conoscete questa persona). Poi mi è ritornata la voglia di programmare e creare programmi.
Avevo reiniziato con HTML5, per il lavori, e c'è stato tira e molla alla fine di nuovo l' ho abbondonato :(
Giorni fa ho visto Unreal Engine 4 e la programmazione di videogiochi 2D/3D.

Credo che potresti definirmi un esperto per quanto riguarda iniziare argomenti, percorsi per poi stufarmi. Vale anche per le stesse cose. Non è una cosa bella.

Io ho le idee confuse. Se poi si entra nei dettagli tecnici o addirittura vengo giudicato (parlo in generale) la confusione aumenta.
Più di un anno ho dato occhiate ai libri, ho iniziato a leggere, però poi ho abbondonato e mi sono stufato :(
Questo vale anche per altre materie/altri percorsi.
Idealizzo le cose.

Io non penso affatto che un linguaggio, un componente o una scheda siano il male.
Per es. il linguaggio C per me ha pregi e difetti. Però mi sono messo varie volte anche per ogni volta mi viene la curiosità ma poi ci sono delle cose che mi stanno sullo stomaco.
Per me un linguaggio (programmazione oppure markup) non è come un quadro. Bisogna leggere il codice, capire quello che c' è scritto, districarsi in mezzo il codice, studiarlo etc... Poi bisogna mettersi sui libri etc...
Ci sono parti di codice in C che per me (cosa soggettiva) sono intrecciate, sensa senso, mi trovo malissimo e specie quando devo scrivere. Poi anche l' approccio didattico che non condivido ma è una mia personale.
Ne posso rovinarmi il fegato, incalarmi etc... un linguaggio.
Questo vale, per me, anche per altri ambiti specie ad es. se riguarda la musica.

Se poi qualcuno riesce ad leggere/districarsi con il codice del C o/e programmare o ad andare avanti, meglio per lui.
Se puoi qualcuno a cui piace alla follia il C gli dico, beato lui ^^
Ad es. per il java o l' OOP non credo che le imparerò mai perchè non mi intessano. Stessa cosa vale per Arduino.
Io non giudino nessuno ed ognuno è libero di usare o/e imparare il linguaggio che vuole. Fosse anche Java o uno più astratto.

Sul C ad es. mi va bene che ci siano gli header ed il preprocessore. Su questo ad es. preferisco il C rispetto al Pascal. Però, mia opinione personale, non mi va bene che ci siano fin dall' inizio dei libri. Rispetto chi la pensa diversamente da me.

Uno dei problemi per me sono le parentesi graffe ad es. quando c'è una sottofunzione o addirittura una sottofunzione all' interno di un sottofunzione. Mi ci trovo male. Che devo fa oh.
Per certe cose il C non fa per me, che posso fare.
Poi ognuno decide che cosa fare come hobby o/e come passare il proprio tempo libero :)

Forse ci sarebbe un modo per impare delle cose riguardanti il C e che forse potrebbe permettermi di programmare in simil-C. Però di sicuro a molti non piacerà.
Quando ci sono delle cose che non mi piacciono e le faccio per forza o addirittura me la fanno fare per forza poi alla fine, vivo male la situazione etc.. finisco per odiare queste cose etc... Sinceramente questo non mi va.
Ad es. se non mi avessero obbligato a leggere o/e a studiare a quest' ora avrei un rapporto migliore con la lettura (è tanto che non finisco un libro) e non avrei un rapporto brutto con lo studio.

Io immagino che sia questa la tipologia di ragionamento che fa di solito :asd:

Meno male che non sono al livello di quella persona.
Hai immaginato male :asd:
 
Ultima modifica da un moderatore:
Idee confuse o meno, è quello che succede quando ti forzi a fare una cosa che ti interessa ma che non ti piace sul serio.
L'unica soluzione è....fare altro.
 
Pubblicità
Pubblicità
Indietro
Top