Caspita, non vedevo una discussione con post così lunghi da qualche anno penso. Avrei voluto rispondere questa mattina, ma purtroppo non mi era possibile.
Partecipo, giusto per dire la mia, e chiedo venia se mi ripeto quando magari ci sono già state risposte a qualche parte, ma leggere tutto il thread è difficoltoso... :D
I pc, i server e le workstation non fanno parte del settore embedded ed ovviamente nenemmeno di quello Iot.
Non è vero che nell' ambito elettronico l' archettura x86 praticamente non esiste.
Poi non è vero che è tutto dominato da Arm e Avr.
Purtroppo, o per fortuna, è così. Lo smartphone che hai in mano (il processore, intendo) è più probabilmente un ARM che un Intel.
Dove si trovano queste pile ci codice già scritto da altri?
Le pile di codice di terzi sono tutte le API che andrai ad utilizzare quando programmerai. Che senso ha reimplementare, ad esempio, la printf del C (a parte scopi didattici)? Posto che in qualche modo dovrai stampare su console, o leggere/scrivere un file... e che quindi dovrai interfacciarti con un'API da qualche parte (magari con il sistema operativo stesso).
Inoltre non ho considerato le call come funzioni vere e proprie, in quanto molto diverse semanticamente dalle funzioni implementate nei linguaggi astratti.
Semanticamente saranno anche diverse, ma in pratica la chiamata ad una funzione è una CALL che faresti in assembly. Le funzioni quindi esistono anche in asm, solo con meno livelli di astrazione; poi che non ci sia una corrispondenza tra CALL/RET... questo è vero.
Intendo dire che la CALL alla funzione A è 'solo' il cambio di indirizzo in IP/EIP/RIP ed un salto (visto il cambio di indirizzo) a quell'indirizzo. Quando avviene il RET, in teoria, ci potrebbe essere qualsiasi altro indirizzo in ESP e saltare quindi altrove.
Oltretutto una funzione ha comunque un prologo ed un epilogo. Quindi non condivido in toto questa parte.
Questo qui per me è strutturato e modulare visto che non tutte le righe hanno la stessa tabulazione ed più mov ax etc.. ed Int 21H si trovano all' interno di START:; etc... di ends
Se fosse stato un programma non-strutturato ogni riga di istruzione avrebbe avuto la stessa tabulazione e non ci sarebbe nessun sottoprogramma (o come si chiama).
@Cibachrome fatico un pò a comprendere questo attaccamento alla sintassi... sull'essere o meno strutturato, ho visto che ti hanno già risposto.
START è solo il punto di ingresso, è l'etichetta del blocco in questione. Normalmente il programma inizia l'esecuzione, ma come si fa con linguaggi ad alto livello, lo svolgimento è all'interno di altre funzioni (e file). Oltretutto gli esempi che riporti sono dell'8086 (16bit) e girano sotto al DOS; INT 21h, che è il vettore dei servizi del DOS.
Per fortuna le chiamate avvengono in maniera differente ora (non che interagire con la WinAPI sia comodissimo...).
CMP in Asm non corrisponde a == in C. In C è If.
Eh no. CMP sta per Compare cioè confronta. Il confronto in C/C++ è dato da ==
Ni. Per amor di precisione: CMP, compare, effettua una sottrazione - ed il risultato viene scartato - e l'esito provoca un cambiamento di alcuni bit in EFLAGS. TEST è analogo, ma effettua una AND.
Poi si utilizza solitamente una delle tante istruzioni di salto condizionato, che leggono bit specifici e decidono se "jump is taken" oppure no.
Comunque
@Cibachrome visto che mi è parso di capire che non hai mai affrontato la programmazione... scegli un linguaggio che ti interessa, ed inizia a studiare (oltre che a far tanta pratica). Quando ne conoscerai bene uno, apprenderne altri - anche se meno bene - non sarà così complesso. La parte più importante rimane in ogni caso la mentalità, il modo di pensare (come ho già detto in altri interventi più e più volte), la capacità di risolvere problemi.
Più sopra, non ricordo bene in quale post, ho visto che sei un tipo che passa alla pratica e che non ama molto la teoria. Permettimi di dirti invece che non è sufficiente leggere qua e là interventi su blog, forum o seguire qualche video da 10 minuti su youtube. La teoria è parte integrante, considerando che la disciplina in questione attinge da un sacco di altri grandi settori (ad esempio, matematica) e che l'informatica stessa... è enorme. ;)
Anche peggio, non avevamo neanche una tastiera, solo una riga di interruttori per digitare l'istruzione in binario, piu' un pulsante di invio e uno di run, erano i primi anni 80. Ci scrissi un controllore di temperatura, usando una resistenza e una convertitore DAC. Non c'era nemmeno monitor o stampante, si sperava che quello che si era scritto fosse corretto. e ovviamente nessuna memoria statica, tutte le volte che lo si assendeva partiva da zero. Per lo meno era un processore a 8 bit e non 32 o 64, altrimenti sarei ancora la' a pigiare pulsanti. Non ricordo che computer fosse, forse auto costruito nel laboratorio della universita'.
Ho sentito qualche storia tipo questa... ho conosciuto qualche programmatore attorno - attualmente - ai 65/70 anni, e e ne ha raccontate di ogni. :D
Forse era un bel periodo in fondo (io non ero ancora nato)... ora come ora, sarà l'astrazione, la mentalità o atro, ma si sta perdendo un pò quel livello di competenze un pò più approfondito, e tanti programmatori finiscono per utilizzare cose senza avere la più pallida idea di come funzionino, o fregandosene completamente (anche di aspetti che meriterebbero di essere approfonditi, almeno per sapere la loro esistenza, prima di scrivere del codice).
