U
Utente 125751
Ospite
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à.
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.