Dall'assembly ai linguaggi di alto livello

  • Autore discussione Autore discussione Utente 125751
  • Data d'inizio Data d'inizio
Pubblicità
Beh, Assembler e' semanticamente diverso da tutti i linguaggi :) ma il concetto di funzione e' lo stesso: si salva lo stack, ci si mettono i parametri usati dalla funzione, si salvi il puntatore di esecuzione sostituendolo con l'indirizzo della funzione (la implementazione e' diversa a seconda del assembler).

Si, ma ci sono delle differenze non da poco.

Innanzitutto lo scope. In assembly non esiste. Puoi accedere a tutti i dati da tutte le parti del programma, a patto di sapere dove trovarli.

Inoltre il concetto di funzione nei linguaggi ad alto livello si porta dietro una specifica semantica, cioè definisce dal punto di vista astratto cosa si può passare alla funzione, spessissimo tenendo traccia dei tipi dei dati passati, e come e cosa restituire all'uscita.

In assembly si può fare perchè si sfruttano gli strumenti messi a disposizione dalla cpu ( registri e/o stack ) ma non è prescritto come fare e cosa usare. Il come e il cosa fa parte del modello di programmazione in senso generale, ma non so se sia giusto dire che l'assembly indica quali regole seguire. E' l'ABI ad indicarle. E anche in questo caso è un consiglio e non un ordine, cioè opzionale, libertà che un qualsiasi linguaggio di alto livello non ti consente.

Io vedrei le call in assembly più come salto a sottoprogramma con meccanismo che tiene traccia del punto di ritorno, piuttosto che identiche al concetto di funzione. Poi alcuni linguaggi consento di ritornare delle tuple, cose che in assembly può chiaramente essere implementata ma non è definita nella semantica del linguaggio.

E infine c'è il fatto che non esiste il linguaggio assembly in quanto tale, ma esistono i vari assembly relativi alle varie famiglie di micro. Può sembrare una distinzione viziosa, ma è importante perchè ciò che ti dà uno non è detto che te lo diano gli altri. E il fatto che ci siano una miriade di assemblatori, ognuno che offre funzionalità di "alto livello" proprietarie, non aiuta. Voglio dire, esistono assemblatore che implementano il concetto di funzione come lo conosciamo nei linguaggi di alto livello, ma è una caratteristica dell'assemblatore non dell'assembly che implementa.
 
Riprendo il punto iniziale del discorso.
per interesse personale/hobbystico stavo cercando su Wiki, specie su quella .com, un linguaggio per Ms-dos (intendo il sistema operativo) oppure per Windows che sia adatto a me
Ma lo scopo finale del programmare è fare cosa ?

Perchè io ritengo serva uno scopo, non si programma per il solo gusto di farlo ma per creare qualcosa che prima non c'era.
Io ho cominciato perchè volevo fare i giochi che mi piacevano.
Adesso, oltre a quello che faccio per lavoro, programmo il software che mi serve. Se non mi serve niente di nuovo non programmo.

Sarà anche in base allo scopo finale che verrà scelto il linguaggio adatto.
Come hobby, quando programmo, ho scelto C#.
 
Giusto ma il mercato indirizza gli sforzi di milioni di programmatori, i quali realizzano anche strumenti di programmazione. Per cui non è detto che quello che cerchi esista già. Al che o lo crei ( sarebbe uno sforzo futile e titanico nel caso di un linguaggio di programmazione ) o accetti quello che c'è. Del resto i linguaggi differiscono nelle astrazioni e nella sintassi. Il primo punto può essere un problema, il secondo è solo questione di abituarsi.

Su quello che hai scritto tra parenti non sono totalmente d' accordo.

Per me il secondo punto non è solo questione di abituarsi.

Ad oggi è C il signore dell'embedded. C++ per progetti fatti con hardware un pò più capaci. Basic è inadatto, Pascal ha uno share piccolissimo, Ada è ignoto al 99% dei programmatori.

Le cose non stanno così. Comunque questa discussione non riguarda il settore embedded.

Nel caso dell'elettronica analogica c'è ben poco da programmare. Per le architetture x86 esiste tutto quanto fatto negli ultimi 40 anni.

Lo so e mi interessa.

L'unico linguaggio del genere è quello che ti crei tu.

Vero.
HLL potrebbe essere adatto a me.

Oppure forse Rexx o ABAP.

Non usare le funzionalità che non ti piacciono.

Non ne me intendo. Non so come si fa.

Beh visto che non hai necessità di creare programmi funzionanti, puoi aprire notepad e scrivere una serie di keyword prese da un linguaggio astratto che ti sei inventato.

Ma io sopra, nel poema che ho scritto, ho detto che il programma che scriverò si deve compilare e deve funzionare. Devo modificare anche il relativo compilatore.

Il linguaggio è il modello teorico, compilatore ed interprete sono programmi che implementano il linguaggio.

Ho capito.

Perchè non vuoi fare pratica. L'informatica non si studia nozionisticamente.

Io sopra ho scritto che non io non studio perchè non mi piace farlo. Avevo pure lasciato l' università.

Varie volte avevo pensato di iscrivermi ad informatica oppure ad ingegneria informatica oppure ad ingegneria elettronica ma non fanno per me e stessa cosa per l' università in generale.

Pochissimi anni fa ho preso il libro CCENT per preparami, fare l' esame e conseguire il titolo ma non sono mai andato oltre l' inizio e non ho mai prenotato l' esame. Ho mollato.

Io invece vado sul web per cercare informazioni, leggere un po', dare un' occhiata sul web per imparare qualcosina, imparare cose che mi servono per la pratica e questi giorni mi sto docuamentando maggiormente per rispondere a questa discussione.

Se qualcuno mi interrogasse sulla teoria dell' informatica andrei male visto non ho una preparazione teorica ma ho solo poche informazioni sparse.

Sopra ho scritto che preferisco la pratica alla teoria.

Mi sono messo a fare delle prove scrivendo un semplice programmino in C su Notepad 2 usando TDM-GGC come compilatore.

L' altro giorno ho utilizzato, per provare, uno di quei siti in inglese che puoi scrivere il codice, compilarlo online e vedere il risultato.

Anni passati facevo pratica con gli esempi dei tutorial relativi ad es. all' Asm, Python, Basic e C++.

Come ho scritto dopo o modifico un pochino uno dei linguaggi che ho indicato oppure ne cerco uno simile o anche quasi al mio modo di pensare o/e ragione etc..

Invece un linguaggio che sia uguale o quasi al mio modo di pensare non c'è. Se voglio me lo dovrò creare.

Perchè? Pascal e C sono in grado di fare le stesse cose. Ciò che dà totale libertà ad un linguaggio sono i puntatori e la relativa aritmetica. Entrambi sono supportati sia da Pascal che da C.

Forse, è per la sua rigidità?

Ed infine si può inserire codice Assembly in un programma Pascal. Direi proprio che si può fare di tutto.

Questa l' ho scoperta pochissimi giorni fa ed è una cosa positiva.

Ci sono altrettanti guru che hanno spiegato perchè invece preferiscono Pascal a C. Un esempio concreto è la codifica delle stringhe.

Questa 2 cose non le sapevo.

Mi sa che non stiamo parlando della stessa cosa quando ti riferisci alle librerie. Una libreria è un file esterno ( .o, .so, .dll, .a ) contenente codice macchina in formato oggetto. Questo codice viene linkato al binario principale quando si compila il programma e si crea l'eseguibile. C e C++ necessitano delle informazioni sugli oggetti esterni, informazioni presenti nei file .h, che devono essere inclusi tramite #include. Ma nessuno t'impedisce di non utilizzare nessunissima libreria esterna e scrivere tutto quello che ti serve nel tuo codice.

Io di librerie conosco quelle .dll e quelle .h I file .h sono delle librerie e non contengono codice macchina.

Da quello che leggo mi piace che il file .h che viene incluso nel programma è una libreria.

Visualizza allegato 296162

https://www.google.it/search?client...-ab..0.13.1253...0i67k1j0i131k1.0.2eONyCj-cis

Il riferimento era all'ambito embedded, dove sfido chiunque a trovare un processore x86. Esistono un paio di board amatoriali e qualche oscuro sistema di controllo della Siemens et similia. Ma niente su larga scala. In passato erano diffuse le cpu 8051 di Intel, ma non erano x86.

Un processore (MPU) Pre X86, X86 ed X64 non c' entrano nulla con il mondo embedded. Sono general purpose.

L' 8051 è un microcontrollore (MCU) ad 8 bit ma c' erano altri compresi anche i modelli successivi Intel.
CI sono produttori (non Intel) che hanno MCU basati sull' 8051.

Esistono anche MCU Intel X86.

Comunque stiamo andando OT.

Non potrebbe mai esserci, perchè il mattone base di tutte le astrazioni è il concetto di funzione.

Ti riferisci anche alla sintassi?


Avevi citato QuickBasic che non è Qbasic. Qbasic è una versione ridotta e senza compilatore di QuickBasic.

Errore mio.

Significa che senza aggiunte esterne hanno tutti le stesse potenzialità.

Ok.

Non dice niente.

C'è una tabella con dei linguaggi di programmazione OS system. Altro non so.


Non mi è chiaro cos'hai fatto allora.

L' ho poi spiegato nel quote che c' era sotto.

Cioè creare un linguaggio derivato da un altro. Java deriva da C e C++. Nim deriva da Pascal. Go deriva da C, C++ e Java.

Non intendo proprio un linguaggio derivato da un altro perchè la cosa sarebbe più complessa. Intendo una specie di dialetto del C che si sostituisce al C ed utilizza il compilatore del C che viene un pochino/un po' modificato.

Totalmente fuori strada. Stai confondendo il linguaggio come modello di macchina virtuale, con le funzionalità implementate dalla libreria standard e da librerie di terze parti e col compilatore/interprete.

E' un po' arabo questo.

Non necessariamente. Usando le macro LISP si può di fatto implementare un linguaggio ex novo sfruttando il compilatore LISP per compilarlo. Per questo LISP è ancora oggi ritenuto l'apice della piramide.

Non lo sapevo.

Ad es. l' Algol, il Fortran, Cobol, Pascal e Basic derivano dal Lisp?

Occorrono enormi conoscenze. Comunque esiste un libro considerato la bibbia dei compilatori, dal titolo "Compilers: Principles, Techniques & Tools".

Ma è una cosa meno difficile rispetto a creare un proprio linguaggio di programmazione + un proprio compilatore?

Io voglio solo modificare un pochino il compilatore a la sintassi del linguaggio. Probabilmente ho un pochino sopravvalutato la cosa.

Vado a cercare il libro che mi hai consigliato ^^

Non sono affermazioni un pò presuntuose? In tanti anni ho potuto constatare che avere una mentalità aperta e cercare di capire il perchè i progettisti hanno fatto determinate scelte ( piuttosto che fissarsi e dire che hanno sbagliato perchè a nostro giudizio è fatto male ), alla fine paga e ci arricchisce intellettualmente.

Non c'è presunzione da parte mia :)

Quello che ho detto sopra vuole dire che per me (opinione personale) non è importante Solo che il programma debba funzionare. Non credo che sia l' unico a pensarla così.
Chi invece la pensa diversamente, io lo rispetto ed è libero di pensarla come vuole.

Se io devo Solo guardare che il programma funzioni e basta ignorando tutto il resto abbandonerei il programma ed il relativo linguaggio perchè è una cosa che semplicemente non mi interessa e non mi piace. Stessa cosa vale se devo scrivere un programma da zero.

Io sopra (nel poema) ho scritto che ogni programmatore (ma vale anche per ogni progettista) che ha creato un linguaggio di programmazione oppure un programma ha ed aveva (mi riferisco anche a quelli del passato) una o più ragioni per avere scritto la sintassi, la semantica etc.. in un determinato modo anzichè in altro. C'è una o più ragioni se ha fatto determinate scelte piuttosto che altre.

Nel paper che ho linkato sopra, uno dei due creatori del C spiega perchè non gli piace il Pascal. Io non l' ho letto però credo che ritenga che una o più cose siano per lui sbagliate. Io però non ho una posizione in merito e mi piacere documentarmi meglio considerando anche quelli che a cui piace il Pascal ma non il C.

Io non ho che qualcuno ha sbagliato. Tra l' altro il concetto di giusto e sbagliato è relativo e non assoluto. Ogni persona ha un giudizione ed un opinione diversa.

Ci sono persone ad es. che non gli piace il C ma il linguaggio Rust. E così via...

Es. questo ti spiega perchè odia il linguaggio C:

http://xahlee.info/comp/why_i_hate_C_lang.html

Io sto cercando di avere una mentalità come minimo un po' aperta e di mettermi nei panni dei programmatori e dei progettisti senza essere presuntuoso.

Mi hai fatto ricordare questa citazione:

"Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela ciascuno. Ma se tu hai un’idea, ed io ho un’idea, e ce le scambiamo, allora abbiamo entrambi due idee. "

Mi piacerebbe che, anche nei miei confronti, avessi una mentalità aperta :)

Per me un linguaggio di programmazione e il codice di un programma sono per certi aspetti come un lingua. Però capisco che ci sono persone che la pensano diversamente da me e rispetto il loro pensiero.

A me LISP sembrava un'assurdità a prima vista. Poi l'ho studiato, usato per un pò e ne ho compreso l'immensa grandezza, ben nascosta dietro una sintassi che sembra ( a prima vista ) folle. Anzi, lì la sintassi proprio non c'è.

Invece a me non sembra un' assurdità il Lisp e la sua sintassi non mi sembra affatto folle. Questo non vuol dire che per me il Lisp sia un' assurditò e che la sua sintassi sia folle.

Per me esiste la sintassi in Lisp visto che è un linguaggio di programmazione.

Quando lo guardo mi sembra di stare a fare matematica. Non è una cosa negativa.

Per 1 o forse 2 cose mi ricorda un po' l' asm.

Il lisp non rientra tra i miei interessi. Poi per il futuro chi lo sa.

Perchè non esiste il concetto di variabile in Assembly e ogni istruzione può accedere ad aree di memoria arbitrarie. Per cui l'assemblatore non ha modo di conoscere in quali aree di memoria si trovano quali dati.

Ho capito.

E si può fare anche in altri modi, usando ulteriori rappresentazioni intermedie.

Mi hai messo la curiosità. Tipo? ^^

No, in Assembly si possono definire solo gli elementi nelle sezioni dati statiche. Niente è specificabile per quanto riguarda i dati nel heap. Inoltre si può solo specificare la dimensione in bit di una variabile, non il tipo. Per Assembly un boolean e un byte sono la stessa cosa. Per Pascal no.

Non conosco le sezioni dati statiche e i dati nell' heap.

Allora la variabile c'è in assembly. L' hai nominata :D

Riguardo alle ultime due frasi: perchè in Asm sono la stessa cosa ed in Pascal no?


Il Pascal è un linguaggio ad alto livello e quindi è astratto.

Il modello di programmazione del x86 è diverso da quello di una cpu ARM. Non esiste il registro AX/EAX/RAX nei processori ARM. Quindi se nel tuo linguaggio usi quei nomi dei registri, quando poi andresti a compilare per ARM, il compilatore che dovrebbe fare? Non può fare le magie.

Io attualmente so che l' asm X86 non è compatibile con l' asm arm.

Io non ho arm e quindi non vado a compilare per arm.

Ti sfugge il fatto che di una libreria ( nel caso di linking statico ) viene incluso solo il codice effettivamente usato.

Questo non lo sapevo. Non so nemmeno cos'è il linking statico.

Pure in C le librerie sono codice macchina. In Pascal si chiama Unit.

Qieste cose non le sapevo.

Solo perchè la libreria standard implementa più funzionalità? Ci sono linguaggi che implementano pure la grafica nella loro libreria standard e la includono nel programma forzatamente, senza darti la possibilità di non includerla. Ma ti fanno contento perchè tu non devi mettere #include "pippo.h" e sei convinto che in realtà non stai includendo nessun codice esterno. SBAGLIATO!

Io fino ad ora ero convinto che ad es in Pascal, Basic, Cobol, Python etc.. non ci fosse nessun codice esterno da include in un programma. In questi linguaggi da quello che hai scritto deduco che il tutto avviene in automatico iin modo che chi scrive il programma non debba includere nessun codice esterno all' interno del programma. Mi hai aperto gli occhi su questa cosa. Nemmeno immaginavo che accadesse una cosa del genere.

Ho un dubbio:

dato questo programma in asm 8086 con Tasm

Codice:
.model small
.stack
.data

Message db "Hello World!$"     ; message to be display

.code

mov dx,OFFSET Message     ; offset of Message is in DX
mov ax,SEG Message     ; segment of Message is in AX
mov ds,ax         ; DS:DX points to string

mov ah,9         ; function 9 - display string
int 21h         ; call dos service
mov ax,4c00h         ; return to dos DOS
int 21h

END start         ;end here

Questo programma se ho capito bene dovrebbe stampare il messaggio all' interno delle virgolette (simbolo del dollaro compreso) che si trova nella riga dove c'è Messagge db.

In C invece il programma Hello world apparentemente sembra più corto. Però da quello che mi hai detto non c'è obbligo di scrivere uno o più librerie ma chi scrive il programma sarà costretto a scrivere il contenuto che si trova dentro la libreria .h all' interno del programma.

Non so se bisogna inserire per forza tutto il contenuto del rispetto file .h oppure solo una parte.

Però se ad es. uno dovesse inserire tutto il codice contenuto della libreria stdio.h direttamente all' interno del programma Hello World scritto in C allora il programma sarebbe più lungo rispetto all' assembly.

Se non ricordo male uno dei motivi per cui sono stati creati i primi linguaggi ad alto livello (es, anni 70 ed 80) era proprio quello di fare programmi più corti rispetto al rispetto programma scritto in asm.

Ho visto però che il programma in C ha qualche istruzione singola in più:

https://www.geeksforgeeks.org/print-hello-world-c-without-using-header-file/

Non include nessuna libreria.

In un altro sito ho visto invece che si possono includere altre 2 librerie:

C:
#include <sys/syscall.h>
#include <unistd.h>

int _start() {
  syscall(__NR_write, 1, "hello world\n", 12);
  syscall(__NR_exit, 0);
  return(0);
}

Mi sono informato ed ho scoperto che con le Api (che riguardano Windows) il programma Hello World in C è molto più lungo e che bisogna includere la libreria windows.h.

Scrivendo un programma in Asm con Tasm bisogna scrivere anche le direttive del Tasm ma ci sono una o più librerie che vengono incluse forzatamente nel programma?

E comunque Cobol supporta librerie esterne, e supporta il linking con librerie C-style tramite FFI.

Queste due cose non le sapevo.

Facendo ora una ricerca ho trovato ad es. questo:

https://supportline.microfocus.com/Documentation/books/sx60/printf.htm

Riguarda quello che hai detto, giusto?

Dappertutto. Intanto sono quei millemila file .dll che trovi sparsi sull'hard disk. Poi ci sono librerie di terze parti disponibili su github e altri siti simili. Per Javascript/Nodejs esiste NPM, per .NET esiste NuGet.

C'è un mondo da scoprire ^^

Il Tasm ha file .dll? oppure ha altri file sorgenti?

Nel compilatore del C (i file del C++ non li considero) le pile di codice già scritto da altri li trovo solo nei file .dll e nei file .h?

Eh no. CMP sta per Compare cioè confronta. Il confronto in C/C++ è dato da ==
L'if in Assembly è implementato da una delle tante istruzioni di salto condizionato esistenti.#include <sys/syscall.h> #include <unistd.h> int _start() { syscall(__NR_write, 1, "hello world\n", 12); syscall(__NR_exit, 0); return(0); }

Se non mi sbaglio in linguaggio che hai scritto in C dovrebbe fare delle chiamate.

Visualizza allegato 296221

In questo programma ci sono le etichette che in asm sono facoltative.

Il "Se" che è un etichetta e sarebbe l' "If". Però è stato messo a sinistra di di CMP. Io ho pensato che CMP fosse il corrispettivo di If in C.

Mai visto una CPU distrutta via software. Ho visto schede grafiche e di rete distrutte, ma mai CPU.

Anche scrivendo in Asm su Ms dos (non cmd) che gira fisicamente su un pc vintage se si fanno errori nello scrivere il linguaggio la cpu non si danneggia?

Nè l'uno nè l'altro. La presenza del goto indica proprio che non c'è struttura.

program continue: mi ha tratto in inganno :(

Nel Quick Basic e nel Pascal c'è il goto però i programmi sono strutturati. Forse il fatto che ci sia goto in un programma non è sufficiente a dire che è non-strutturato oppure strutturato.

Quel procedure indica una subroutine, per cui è strutturato.

non lo sapevo.

C'è begin ed end che indicano che il linguaggio è strutturato.
Però come mai quel procedure indica che è una subroutine?

La routine dov'è? :boh:

Mica tutti i linguaggi te lo fanno fare. C non lo permette ad esempio.

Intendo ad es. questo:

C:
#include <stdio.h>

#define IN  1    /* inside a word */
#define OUT 0    /* outside a word */


/* count lines,words, and characters in input */
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);
}

@DispatchCode

C'è il blocco main però all' interno c'è il sottoblocco while e al suo internet c'è il sottoblocco else if. Dico perchè ci sono 6 parentesi che come tu mi hai detto indicano al compilatore dove inizia e finisce il blocco o/e il sottoblocco.

Purtroppo non mi ci trovo, mi si storcono/intrecciano gli occhi, ci sono delle cose cose relative al codice che io non condivido, non hanno senso ed infine non mi piace.
Poi per fare pratica mi sono scritto l' intero programma, poi l'ho compilato e funzionare pure. Però mentre lo scrivevo e alla fine sono rimaste le cose che ho scritto le frase precente ed in più un po' l' ho pure odiato. Io non voglio arrivare ad odiare una cosa.

Io ed il C non siamo compatibili, siamo su due pianeti diversi.

Sicuramente l' ANSI C ed i creatori del C hanno avuto uno o più motivi per fare determinate scelte su questo linguaggio e questo lo considero e lo rispetto come considero e rispetto le svariate persone che usano o/e studiano o/e anche amano questo linguaggio. Però davanti al mio monitor chi deve programmare in C, scrivendo il codice, e chi deve leggere, capire e guardare i programmi scritti in c, la bibbia del C etc... sono io mica loro o te o qualcun' altro.

Es. davanti al tuo monitor ci sei tu a programmare in un determinato linguaggio, a leggerlo, a capirlo etc.. e non il creatore o/i creatori di questo linguaggio etc...

Stesso discorso vale per altre persone, per altri programmatori, sviluppatori etc...

Es. Richie aveva a disposizione dei linguaggo di programmazione a quel tempo però ha deciso di creare un suo linguaggio di programmazione per determinati motivi. Per quello che ho letto finora questi motivi li condivido.

Una delle cose che ha detto il creatore di Python in un intervista è stata questa: "I remembered all my experience and some of my frustration with ABC. I decided to try to design a simple scripting language that possessed some of ABC's better properties, but without its problems. So I started typing. I created a simple virtual machine, a simple parser, and a simple runtime. I made my own version of the various ABC parts that I liked. I created a basic syntax, used indentation for statement grouping instead of curly braces or begin-end blocks, and developed a small number of powerful data types: a hash table (or dictionary, as we call it), a list, strings, and numbers."

Si può anche citare il creatore del Pascal e di altri linguaggi, il creatore del C++, i due ricercatori universitari che hanno inventato il Dartmouth Basic etc...

Non prenderla per il verso sbagliato ma questo dimostra che a queste persone non interessava Solo che il programma funzionasse, che hanno fatto tanta pratica (ovviamente hanno studiato), che non si sono abituate ad uno o più linguaggi che avevano sottomano, che delle cose riguardanti uno o più linguaggi di programmazione che avevano sottomano non gli andavano proprio bene, non gli piacevano e che conta Anche la sintassi.

Capisco di non essermi spiegato al meglio in diverse risposte dato che non ho un livello tecnico adatto per affrontare questi discorsi.

Però il fatto di voler cercare, per me, questo linguaggio di programmazione ha un senso logico e ci sta tutto. Questo linguaggio dev' essere simile o quasi al mio modo di pensare/ragionare, deve avere le caratteristiche che ho indicato (tralasciando gli errori tecnici), dev' essere un po' più leggibile del linguaggio C, nel complesso mi deve piacere (non sto parlando di perfezione) la sua struttura, la sua sintassi, la sua logica etc... , deve avere più pro che contro, dev' essere un linguaggio in cui mi trovo benino o bene (non pretendo di più) a leggerlo, capirlo, a scrivere i programmi (anche lunghi) e che deve avere pochissimi difetti.
Il concetto di pro e contro è soggettivo.

In queste cose che ho scritto non c'è nessuna presunzione.

Codice:
int main() {
    printf("Hello World\n");
    return 0;
}

c'è un solo blocco ed è il main.

Quindi non c'è una sottofunzione o un sottoblocco all' interno di main? Lo chiedo per imparare.

Modulare proprio no. Per modulare s'intende questo https://en.wikipedia.org/wiki/Modular_programming

Strutturato nemmeno, perchè la struttura implica la separazione dei blocchi, che ha come elemento fondamentale lo scope, cioè la finestra dentro la quale il codice può vedere le variabili. In Assembly tutto è visibile ed accessibile da tutte le parti. Per questo è non strutturato.

Con "Modulare" intendevo la programmazione modulare. Non so qual'è il termine corretto per indicare quando un programma rientra nella programmazione modulare.

Non è la tabulazione che crea la struttura. Il problema è che tu continui a limitarti all'estetica. Non è qualche rientro in più nel listato del sorgente a cambiare cosa le istruzioni possono o non possono fare, nè a stabilire quale modello di programmazione il linguaggio implementa.

Ci sono delle volte, o più, in cui la tabulazione non modifica quello che le istruzioni possono o non possono fare e non modifica il paradigma del linguaggio.

Ad es. nel C si possono aggiungere spazi vuoti, lasciare una o più righe vuote, mandare a capo delle istruzioni ed il programma non darà mai errore e funzionerà visto al compilatore queste cose non le calcola proprio.

Fin' ora tra le varie cose io ho imparato che l' Assembly puro ed il Dartmouth/ GW Basic sono non-strutturati perchè non hanno begin e end oppure le parentesi apri e chiudi, sono un unico blocco perchè non hanno righe vuote e non hanno spazio a sinistra. Ora ho imparato che è tutto è visibile ed accessibile da tutte le parti.

Se mi dici che anche nei linguaggi non strutturati si possono fare le cose che ho scritto nella penultima frase (quella del C) perchè all' assemblatore oppure al compilatore non gli importa nulla allora mi hai insegnato una cosa che prima non sapevo ed hai corretto un informazione errata che avevo imparato.

Nel Pascal le variabili stanno in alto e qualsiasi parte del programma che si trova nella parte centrale può accedere al blocco in alto che è .VAR. Però è un linguaggio strutturato visto che ha begin ed end e non solo per l' inizio e la fine del programma ma anche per i vari blocchi e sottoblocchi.

Invece nell' assembly con un assemblatore ho ancora dei dubbi.

Visualizza allegato 296221

C'è un end che indica la fine del programma all' assemblatore,
Forse .Model Small indica anche l' inizio del programma all' assemblatore. (al posto di Small ci può anche essere Tiny etc...)

C'è la seprazione dei blocchi (mi riferisco alla direttive dell' assemblatore) dove all' interno c'è l' assembly puro.

All' interno dei blocchi però non ci sono begin e end (come avviene ad es. in Pascal), non ci sono le parentesi graffe apri e chiudi (come avviene ad es. in C, C++ e Rust) e non conta la tabulatzione o/e l' indentazione come avviene invece in Python. Qualsiasi punto del programma che si trova all' interno di .STARTUP è accessibile a .DATA.

Non so se l' hai capito, ma vorrei capire per bene la differenza tra linguaggio strutturato, non-strutturato e tra la programmazione modulare in maniera tale da non confondermi più.

Vorrei anche capire le differenze tra l' assembly puro e l' assembly con l' assemblatore per quanto riguarda i paradigmi di programmazione. Al momento l' assembly con l' assemblatore mi sembra un po' strutturato oppure meno non-strutturato considerando i motivi che ho scritto prima.
 
Non offenderti, ti prego, ma da come porti avanti questa discussione, e come ho visto in altre a cui anch'io avevo partecipato, l'idea che mi sono fatto è che tu dici di avere una 'mentalità aperta" ma invece sei il risultato "malsano" della rete.. come uno che si sente un po' medico perché avrebbe voluto esserlo, e così dà consigli su cure e diagnosi documentandosi su internet sbirciando travi siti professionali (dove capisce poco o niente, quindi non può approfondire) e quindi "documentandosi" in quelli non seri.
Fortunatamente il tuo ambito di interessi comporta meno rischi e le cose di cui pensi di essere esperto restano confinate.. ma l'atteggiamento è lo stesso.

Per sostenere quello che intendi sostenere tu (che non è assolutamente chiaro, quindi ognuno si fa un suo film) hai conoscenze troppo scarse, ti manca completamente la teoria e non hai nemmeno pratica. Proponi link di documenti che non hai nemmeno letti, solo il titolo. Vai a leggere su Wikipedia (altra cosa da prendere con le pinze) per rispondere ai threads riportando col copia-incolla affermazioni di cui non sai nemmeno il significato, poi se ti spiegano dici.. "ah, non sapevo.. adesso ho capito.. vado ad informarmi".

Ciò che intendo dire, e la tua esperienza personale, che hai ben presentato qui sopra, lo dimostra: è che non possiedi "metodo". Purtroppo questo è il limite più pesante, perché ti impedisce di imparare e acquisire in maniera costruttiva: ciò che si percepisce è un'accozzaglia di nozioni e informazioni slegate tra loro che ti consentono sempre una via d'uscita dal ragionamento logico. Se anche il tuo interlocutore facesse così, invece di attenersi alla razionalità del discorso, sarebbe un dialogo assurdo, senza alcun senso e infinito!
Senza tenere in considerazione ti che sembra mancarti ogni senso dell'ironia (che richiede nozioni e intelligenza) per cui i discorsi sono anche poco colorati.

Per tornare IT..

Se vuoi farti un linguaggio che rispecchi il tuo modo di pensare (e già qui la vedo dura, per quanto detto sopra) potresti impegnarti un po', per una volta, e inventartelo.
Lascia stare l'idea di modificare (un pochino!?!) un compilatore, che è cosa difficilissima. Piuttosto inizia a scrive un semplice "pre-compilatore" tuo da zero, che è cosa molto più facile. Un programma che trasforma il "tuo modo di scrivere" in codice C, Pascal, Ada o quant'altro..

Ma sentire dire al "primo che passa per strada" che Kernighan e Ritchie hanno scritto una porcheria ...e stare pure a dargli retta, sinceramente non è certo dimostrazione di apertura mentale, ma sicuramente una stupidaggine che offende la scienza e il mondo..

Inviato dal mio Nexus 5 utilizzando Tapatalk
 
Ci credo ancora :lol:



Ma io sopra, nel poema che ho scritto, ho detto che il programma che scriverò si deve compilare e deve funzionare. Devo modificare anche il relativo compilatore.

Non hai idea della complessità di ciò che stai dicendo di voler fare...

Io invece vado sul web per cercare informazioni, leggere un po', dare un' occhiata sul web per imparare qualcosina, imparare cose che mi servono per la pratica e questi giorni mi sto docuamentando maggiormente per rispondere a questa discussione.

Se qualcuno mi interrogasse sulla teoria dell' informatica andrei male visto non ho una preparazione teorica ma ho solo poche informazioni sparse.

Sopra ho scritto che preferisco la pratica alla teoria.

Mi sono messo a fare delle prove scrivendo un semplice programmino in C su Notepad 2 usando TDM-GGC come compilatore.

Ma cosa significa "imparare cose che mi servono per la pratica"? Non è tanto questione di teoria dell'informatica, ma di studiare e comprendere le cose che utilizzi. Ed in questo caso copiare del codice in rete, mettere assieme qualcosa, e farlo funzionare... non è sufficiente, così come andare a tentativi.
La pratica è essenziale, ma ci sono concetti ed argomenti che non si possono non sapere, e senza studio andrai sempre un pò "a caso".
I commenti che seguiranno alle tue domande/affermazioni, dovrebbero farti capire che basterebbe aprire un libro e studiare o almeno leggere qualcosa per chiarirsi un pò di aspetti. :)

Io di librerie conosco quelle .dll e quelle .h I file .h sono delle librerie e non contengono codice macchina.

Da quello che leggo mi piace che il file .h che viene incluso nel programma è una libreria.

Stai confondendo un pò le cose...
Il file ".h", che è tipico del C, è l'header. Un programma in C (o C++) può funzionare anche senza file header, non c'è nessun obbligo in tal senso. Sono utili quando scrivi una libreria che ha determinate funzionalità che devono essere poi utilizzate da terzi. In questo modo hai strutture/variabili e dichiarazioni di funzioni in un file (header) che verrà incluso in un sorgente; in tal modo si evitano pure inconsistenze.

Le librerie dll sono dinamiche, come dice il nome stesso. Sono tipiche dell'OS Windows. La libreria dinamica offre funzionalità ad un programma durante la sua esecuzione. La libreria può anche essere inclusa dal programma stesso durante l'esecuzione (usando ad esempio LoadLibrary, che fa parte della WinAPI).

La particolarità delle DLL è che una volta caricate in memoria possono anche essere condivise da più programmi, evitando così di caricare un'istanza nuova della stessa per ogni programma che ne fa richiesta.

Non intendo proprio un linguaggio derivato da un altro perchè la cosa sarebbe più complessa. Intendo una specie di dialetto del C che si sostituisce al C ed utilizza il compilatore del C che viene un pochino/un po' modificato.

Vuoi fare qualcosa di simile a Scala quasi...
In questo caso però il codice viene trasformato in bytecode (usando il compilatore di Java) e poi interpretato. In pratica è un linguaggio compatibile con la JVM.

Ma è una cosa meno difficile rispetto a creare un proprio linguaggio di programmazione + un proprio compilatore?

Io voglio solo modificare un pochino il compilatore a la sintassi del linguaggio. Probabilmente ho un pochino sopravvalutato la cosa.

No, sicuramente hai un tantino sottovalutato la cosa.

Io sto cercando di avere una mentalità come minimo un po' aperta e di mettermi nei panni dei programmatori e dei progettisti senza essere presuntuoso.

In realtà, leggendoti, pare il contrario (mi riferisco alla mentalità). I programmatori ed i progettisti hanno dato vita a linguaggi per risolvere problemi che altri linguaggi non riuscivano a risolvere (oppure si, ma non in modo semplice).

Io fino ad ora ero convinto che ad es in Pascal, Basic, Cobol, Python etc.. non ci fosse nessun codice esterno da include in un programma. In questi linguaggi da quello che hai scritto deduco che il tutto avviene in automatico iin modo che chi scrive il programma non debba includere nessun codice esterno all' interno del programma. Mi hai aperto gli occhi su questa cosa. Nemmeno immaginavo che accadesse una cosa del genere.

In automatico non avviene nulla. Ciascun linguaggio ha un'API, e di norma - in generale - mette a disposizione cose come: operazioni di I/O da tastiera e da file, strutture dati (stack, alberi, array dinamici, mappe...), algoritmi di ordinamento, funzioni per operare sulle stringhe (dallo split ad altro), multithreading, alcuni linguaggi anche il supporto grafico (non è il caso ad esempio di C++/C, che fanno uso di librerie esterne... come le Qt, ad esempio). Questo solo per fare alcuni esempi.

Sta poi al programmatore includere la libreria di cui necessita: se hai un numero N di elementi da memorizzare, che cambia nel tempo, ha senso utilizzare un array dinamico (come un vector in C++ o un ArrayList in Java). Che senso avrebbe, lasciando da parte motivi didattici, riscrivere questa funzionalità? Poco o niente. Ecco perchè esistono già funzionalità che il linguaggio mette a disposizione.
Il C è uno di quelli che mette a disposizione meno, rispetto a tanti altri. L'API di C++ è immensa, ad esempio.

Ho un dubbio:

dato questo programma in asm 8086 con Tasm

Codice:
       .model small
.stack
.data

Message db "Hello World!$"     ; message to be display

.code

mov dx,OFFSET Message     ; offset of Message is in DX
mov ax,SEG Message     ; segment of Message is in AX
mov ds,ax         ; DS:DX points to string

mov ah,9         ; function 9 - display string
int 21h         ; call dos service
mov ax,4c00h         ; return to dos DOS
int 21h

END start         ;end here

Questo programma se ho capito bene dovrebbe stampare il messaggio all' interno delle virgolette (simbolo del dollaro compreso) che si trova nella riga dove c'è Messagge db.

In C invece il programma Hello world apparentemente sembra più corto. Però da quello che mi hai detto non c'è obbligo di scrivere uno o più librerie ma chi scrive il programma sarà costretto a scrivere il contenuto che si trova dentro la libreria .h all' interno del programma.

Non so se bisogna inserire per forza tutto il contenuto del rispetto file .h oppure solo una parte.

Viene stampato a video "Hello World!", ma senza il dollaro. Quello si chiama carattere terminatore (serve a capire dove termina la stringa). L'esempio che hai preso comunque è di un programma che gira sotto DOS, e non è esattamente identico ad uno che gira sotto Windows; quindi già un confronto di questo tipo non è propriamente corretto.

Sembra tu non abbia mai aperto un file header... :D
Esempio, in winnt.h, tra le tante dichiarazioni e direttive, trovi cose come:
C:
typedef struct _IMAGE_SECTION_HEADER {
    BYTE Name[IMAGE_SIZEOF_SHORT_NAME];
    union {
        DWORD PhysicalAddress;
        DWORD VirtualSize;
    } Misc;
    DWORD VirtualAddress;
    DWORD SizeOfRawData;
    DWORD PointerToRawData;
    DWORD PointerToRelocations;
    DWORD PointerToLinenumbers;
    WORD NumberOfRelocations;
    WORD NumberOfLinenumbers;
    DWORD Characteristics;
} IMAGE_SECTION_HEADER,*PIMAGE_SECTION_HEADER;

Questa struttura rappresenta una sezione definita nell'header di un EXE.
Quando viene incluso il file header puoi utilizzare questa ed altre strutture e dichiarazioni.

Però se ad es. uno dovesse inserire tutto il codice contenuto della libreria stdio.h direttamente all' interno del programma Hello World scritto in C allora il programma sarebbe più lungo rispetto all' assembly.

L'hello world in C sono 2 righe:
C:
#include <stdio.h>

int main()
{
    printf("Hello World!");
    return 0;
}

In assembly non finisci più di scrivere...

Codice:
include  c:\masm32\include\masm32rt.inc


.data
helloWorld        db           "Hello World!", 0

.data?
charWritten       LPDWORD      ?


.code
start:

    push        STD_OUTPUT_HANDLE
    call        GetStdHandle
    
    push        offset      charWritten
    push        12
    push        offset      helloWorld
    push        eax
    call        WriteConsole

    push        0
    call        ExitProcess

END    start



Scrivendo un programma in Asm con Tasm bisogna scrivere anche le direttive del Tasm ma ci sono una o più librerie che vengono incluse forzatamente nel programma?

Intendi quando viene assemblato, o quando viene eseguito?

Nel compilatore del C (i file del C++ non li considero) le pile di codice già scritto da altri li trovo solo nei file .dll e nei file .h?

Per il C++ è lo stesso discorso, comunque.
Sopra ho già risposto in merito ai file header, ed alle dll. Il codice scritto da altri è il sorgente (.c o altro, in base al linguaggio). L'header non viene compilato.

Non prenderla per il verso sbagliato ma questo dimostra che a queste persone non interessava Solo che il programma funzionasse, che hanno fatto tanta pratica (ovviamente hanno studiato), che non si sono abituate ad uno o più linguaggi che avevano sottomano, che delle cose riguardanti uno o più linguaggi di programmazione che avevano sottomano non gli andavano proprio bene, non gli piacevano e che conta Anche la sintassi.

Dimostra solo che il linguaggio è uno strumento, e che ci sono strumenti adatti per svolgere certi compiti e non altri; dimostra anche il fatto che la maggior parte dei sistemi operativi sono scritti in C e/o C++, con parti di assembly (dove non si può fare diversamente, ed usato inline quando si può).

Ci sono delle volte, o più, in cui la tabulazione non modifica quello che le istruzioni possono o non possono fare e non modifica il paradigma del linguaggio.

Ad es. nel C si possono aggiungere spazi vuoti, lasciare una o più righe vuote, mandare a capo delle istruzioni ed il programma non darà mai errore e funzionerà visto al compilatore queste cose non le calcola proprio.

La tabulazione non ha nulla a che vedere con il paradigma del linguaggio...

Vorrei anche capire le differenze tra l' assembly puro e l' assembly con l' assemblatore per quanto riguarda i paradigmi di programmazione. Al momento l' assembly con l' assemblatore mi sembra un po' strutturato oppure meno non-strutturato considerando i motivi che ho scritto prima.

Usi un pò termini messi assieme, come viene... :lol:
Che vuol dire la prima frase su assembly puro ed assembly con l'assemblatore? E poi non c'è un nesso con i paradigmi di programmazione.

L'assemblatore riceve in input un sorgente in assembly e lo assembla, producendo poi il codice macchina. E' più semplice rispetto ad un compilatore.

Ho scritto un pò di fretta, ma spero si sia compreso tutto.
 
Non offenderti, ti prego, ma da come porti avanti questa discussione, e come ho visto in altre a cui anch'io avevo partecipato, l'idea che mi sono fatto è che tu dici di avere una 'mentalità aperta" ma invece sei il risultato "malsano" della rete.. come uno che si sente un po' medico perché avrebbe voluto esserlo, e così dà consigli su cure e diagnosi documentandosi su internet sbirciando travi siti professionali (dove capisce poco o niente, quindi non può approfondire) e quindi "documentandosi" in quelli non seri.
Fortunatamente il tuo ambito di interessi comporta meno rischi e le cose di cui pensi di essere esperto restano confinate.. ma l'atteggiamento è lo stesso.

Per sostenere quello che intendi sostenere tu (che non è assolutamente chiaro, quindi ognuno si fa un suo film) hai conoscenze troppo scarse, ti manca completamente la teoria e non hai nemmeno pratica. Proponi link di documenti che non hai nemmeno letti, solo il titolo. Vai a leggere su Wikipedia (altra cosa da prendere con le pinze) per rispondere ai threads riportando col copia-incolla affermazioni di cui non sai nemmeno il significato, poi se ti spiegano dici.. "ah, non sapevo.. adesso ho capito.. vado ad informarmi".

Ciò che intendo dire, e la tua esperienza personale, che hai ben presentato qui sopra, lo dimostra: è che non possiedi "metodo". Purtroppo questo è il limite più pesante, perché ti impedisce di imparare e acquisire in maniera costruttiva: ciò che si percepisce è un'accozzaglia di nozioni e informazioni slegate tra loro che ti consentono sempre una via d'uscita dal ragionamento logico. Se anche il tuo interlocutore facesse così, invece di attenersi alla razionalità del discorso, sarebbe un dialogo assurdo, senza alcun senso e infinito!
Senza tenere in considerazione ti che sembra mancarti ogni senso dell'ironia (che richiede nozioni e intelligenza) per cui i discorsi sono anche poco colorati.

Per tornare IT..

Se vuoi farti un linguaggio che rispecchi il tuo modo di pensare (e già qui la vedo dura, per quanto detto sopra) potresti impegnarti un po', per una volta, e inventartelo.
Lascia stare l'idea di modificare (un pochino!?!) un compilatore, che è cosa difficilissima. Piuttosto inizia a scrive un semplice "pre-compilatore" tuo da zero, che è cosa molto più facile. Un programma che trasforma il "tuo modo di scrivere" in codice C, Pascal, Ada o quant'altro..

Ma sentire dire al "primo che passa per strada" che Kernighan e Ritchie hanno scritto una porcheria ...e stare pure a dargli retta, sinceramente non è certo dimostrazione di apertura mentale, ma sicuramente una stupidaggine che offende la scienza e il mondo..

Inviato dal mio Nexus 5 utilizzando Tapatalk

Ti sei fatto un' idea sbagliata di me per certe cose.

Io non ho mai detto di avere una mentalità aperta. Sopra ho scritto che sto cercando di avere come minino la mentalità un po' aperta e di mettermi nei panni dei vari programmatori, sviluppatori etc.. e ci sono riusciuto.

Nell' ultima risposta ho riportato esempi tra cui una parte dell' intervista di quello che ha detto il creatore di Python. L' intervista l' ho letta e non è stata presa da wiki.
Condivido in pieno ed apprezzo il fatto che hanno creato il loro linguaggio di programmazione a modo loro etc...

Ho detto più volte che ognuno di loro ha avuto una o più ragioni per scrivere il linguaggio in un certo modo ed ho pure detto che questo lo rispetto. Ogni persona è diversa, non siamo tutti uguali.

Ho scritto chiaramente più di una volta che su molte cose sono ignorante, non ho il livello tecnico adatto, non conosco tutti i termini giusti e che ogni volta per rispondere a questa discussione è stato difficile etc...

Ho scritto che non ho la mentalità del programmatore, etc...Ho scritto che sono un neofita.

Non ho mai detto che gli autori del C hanno scritto una porcheria oppure che hanno fatto uno sbaglio. Non è giusto mettermi in bocca parole che non ho detto.

I creatori del C e l' ANSI C hanno avuto le loro ragioni affinchè il linguaggio sia così. Questo lo rispetto perchè ogni persona è diversa, ognuno ha una mentalità/prospettiva diversa, ognuno ha i suoi interessi etc...

Per me il C ha i suoi pro ed i suoi contro come ogni linguaggio di programmazione. Però ci sono delle cose ad es. del C che non condivido, mi trovo male per determinate cose e non mi permettono di imparare questo linguaggio e di fare pratica scrivendo i programmi. Ma tengo in considerazione il fatto che ci sono altre persone che per una o più cose si trovano male con il C, tengo in considerazione il fatto che ci sono svariate persone a cui piace questo linguaggio etc...Rispetto queste personelo odiano, come ci sono persone a cui piace o addirittura quelle che lo amano alla follia. Ci sono delle del Pascal che Ritchie nel 1981 non condivide.

Una delle cose che apprezzo del C ed il fatto che non sia proprio un linguaggio ad alto livello visto che per determinate cose è vicino all' assembly e all' hardware.
Un' altra cosa che apprezzo del C è il fatto che sia meno legato all' hardware e quindi puoi essere compilato su qualsiasi cpu X86 e X86-64 e diversi sistemi operativi.
Per quanto riguarda gli array non usa

Quello che ho detto non era assolutamente un offesa verso la scienza ed il mondo.

Da quello che hai detto sembra che devo amare il C e mi devo trovare per bene per forza ad imparare e fare pratica.

Come ho scritto sopra, io leggo e do un occhiata ai siti web (che sono tanti), ai libri in pdf, alle dispense universitarie e non, ai forum, alle guide online ed guardo i video/playlist.

Poi in più c'è anche Wiki.com che pensavo fosse veritiera rispetto a Wiki.it ma poi ho scoperto che non è proprio così e quindi la prenderò veramente con pinze.

Preferisco usare più di uno strumento per imparare.
Però il problema è che non ho una scaletta precisa e quindi leggo tante cose ed alla fine mi rimangono in testa delle informazioni, dei frammenti, confusione etc...e questa cosa è sbagliata. Poi non mi devo distrarre a guardare cercare altre riguardanti l' informatica e gli altri interessi che ho. Devo mettere dei paletti, dei limiti, fare un percorso preciso perchè altrimenti sarà deleterio per me.

In una discussione passata (quella sul linguaggio B/C) mi ricordo che a differenza di questa avevo una mentalità più chiusa, non mi sono messo nei panni dei programmatori e dei sviluppatore e facevo un po' il professore sulla cattedra ma per certe cose avete frainteso.

In questa discussione la mia mentalità non è la stessa di allora e meno male. Però ammetto che era necessario da parte mia, un livello di conoscenze tecniche maggiore per trattare questi argomenti difficili. A saperlo avrei rimandato l' apertura di questa discussione.

Poi per certe cose Pabloski ha capito quello che intendevo mentre tu come al solito per diverse cose hai dimostrato di non avere una mentalità aperta, senza offesa.

Sul fatto invece che hai tanti anni di esperienza, che hai tante conoscenze in questo settore e probabilmente continui ad informarti, beato te ^^

Meno male che hai detto che non ho metodo, che e mi hai datto i consigli finali riguardanti l' IT e questo lo apprezzo :)

@Mursey
@DispatchCode

A me non interessano gli algoritmi, il saper risolvere i problemi e diverse cose che riguardano la scienza dell' informatica. A me ad es, non interessa diventare un programmatore software.

Mi interessa capire come funziona il computer, dall' elettronica passando per il binario, l' esadecimale fino ai linguaggi di alto livello che ho menzionato. Tra i miei interessi c'è l' Assembly sintassi Intel e le architetture Pre X86, l' elettronica. C'è l' interesse verso i compilatori, assemblatori e gli interpreti di certi linguaggi. C'è interesse verso la programmazione a basso livello e l' hardware.

Non posso nemmeno lontanamente pensare di creare un mio linguaggio di programmazione ora visto il mio livello.

Modificare un pochino/un po' un compilatore, secondo me, è meno difficile rispetto a modificarne metà o quasi tutto. Pensa quanto invece sarebbe difficile scrivere da zero o quasi un compilatore. Per questo motivo che l' ho detto più di una volta.

Però anche solo un pochino forse richiede un livello tecnico ed una preparazione che non ho. In questo caso abbandono quest' idea.

Non sapevo il nome tecnico ma anche a me era venuto l' idea di creare questo pre-compilatore. Ho avuto ora la conferma che sia una cosa meno difficile e più fattibile per me ora. Riguardo a questa cosa pensavo: se un compilatore converte il linguaggio ad alto livello in codice macchina forse sarebbe più semplice per me creare un pre-compilatore che converta un preciso programma scritto in un linguaggio X in assembly sintassi Intel e che poi TASM lo riesce ad assemblare e a far funzionare.

Per il resto continuerò ad es. con l' architettura 8086 ed 8008. Continuerò con i rispettivi assembly sintassi Intel perchè per certe cose mi trovo bene.e perchè ho dei progetti che vorrei realizzare.

Sono indeciso invece su HLA e Pascal. Se mi butto su un linguaggio devo andare oltre al codice visto che è astratto e io vorrei capire come si è arrivati a quel punto per capire bene il tutto e non credere alla magia.

Io ho aperto questa discussione anche per avere consigli perchè non voglio come ho fatto in passato mollare un linguaggio o addirittura la programmazione perchè per dei motivi non riesco ad andare avanti. Avevo iniziato con python ed ero arrivato fino ai dizionari. Poi sono passato al Qbasic e dopo un po' l' ho abbandonato. Poi l' ho ripreso e riabbandonato. Stessa cosa con Python. Avevo iniziato il C++ perchè ha delle differenze rispetto al C ma poi ho scoperto che per certe cose è C-like e quindi l' ho mollato. Avevo iniziato con Cobol e dopo pochissimo l' ho abbandonato.
Avevo iniziato con l' assembly ma dopo l' ho abbandonato per dei motivi come ad es. delle cose sono difficile e sia perchè pensavo che partire dall' elettronica fosse un approccio migliore. Però la strada è lunghissima e prima che arriva al livello adatto passeranno gli anni e quindi ho deciso di riprendere l' assembly e l' architettura dei calcolatori.
 
Le cose non stanno così. Comunque questa discussione non riguarda il settore embedded.

Eh no stanno proprio così https://stackify.com/popular-programming-languages-2018/

"C is also the most popular language for embedded systems in cars, electronics, and other devices"

Ad oggi comincia a muoversi qualcosa, con i vari micropython e javascript più o meno castrati per stare nei limiti dell'hardware embedded.



Non ne me intendo. Non so come si fa.

Semplicemente non si usa. Funzioni annidate? No grazie, non le uso.

Ma io sopra, nel poema che ho scritto, ho detto che il programma che scriverò si deve compilare e deve funzionare. Devo modificare anche il relativo compilatore.

Ti dico semplicemente che non puoi. Non hai il know-how per realizzare una cosa del genere. E per acquisirlo dovrai per forza di cose studiare vari linguaggi e diventarne un discreto utilizzatore, cosa che potrebbe aprirti gli occhi sulla futilità di creare un linguaggio nuovo per sole ragioni estetiche.

Io invece vado sul web per cercare informazioni, leggere un po', dare un' occhiata sul web per imparare qualcosina, imparare cose che mi servono per la pratica e questi giorni mi sto docuamentando maggiormente per rispondere a questa discussione.

Pessimo approccio. Mi sento di suggerirti quanto già scritto da rctimelines. Non puoi pretendere di imparare a programmare spiluccando qua e là sul web. Occorre uno studio serio e decine di migliaia di ore di pratica.

Se qualcuno mi interrogasse sulla teoria dell' informatica andrei male visto non ho una preparazione teorica ma ho solo poche informazioni sparse.

E allora scordati di modificare un linguaggio o crearne uno tuo. Programmare un semplice software è fattibile anche per chi è a digiuno di teoria, ma pensare di fare lo stesso con un linguaggio è impossibile. C'è una quantità disumana di teoria ( oltretutto roba matematica di altissimo livello ) dietro un linguaggio, compilatore o interprete.

Come ho scritto dopo o modifico un pochino uno dei linguaggi che ho indicato oppure ne cerco uno simile o anche quasi al mio modo di pensare o/e ragione etc..

Ma il punto è che intendi per modo di pensare o ragionare. Come dicevo LISP è il più flessibile dei linguaggi ad oggi esistenti e tramite le macro consente di creare costrutti di programmazione arbitrari. In questo senso può essere plasmato per avvicinarsi al proprio modo d'interfacciarsi ma i problemi. Ma in generale si usa questa caratteristica per rendere il linguaggio più adatto ad affrontare il tipo di problema da risolvere. Riguardo il modo di pensare del programmatore, è lui a doversi adattare sia al linguaggio sia al problema.

Forse, è per la sua rigidità?

No. Pascal non ha nessuna rigidità. Pascal offre un modello di programmazione come fa qualsiasi altro linguaggio. E' rigoroso, non rigido.

Io di librerie conosco quelle .dll e quelle .h I file .h sono delle librerie e non contengono codice macchina.

I .h sono header file non librerie. Gli header file esistono in C e C++ allo scopo di indicare la struttura delle funzioni presenti in una libreria esterna, affinchè un programma possa utilizzarla.

Un processore (MPU) Pre X86, X86 ed X64 non c' entrano nulla con il mondo embedded. Sono general purpose.

Pure la stragrande maggioranza dei processori e dei microcontrollori usati nell'embedded sono general purpose.

Ti riferisci anche alla sintassi?

No.

Non intendo proprio un linguaggio derivato da un altro perchè la cosa sarebbe più complessa. Intendo una specie di dialetto del C che si sostituisce al C ed utilizza il compilatore del C che viene un pochino/un po' modificato.

Il tutto senza però voler conoscere prima il C? Come dire che uno decide di modificare una BMW senza conoscere come sono realizzati i motori BMW.

Ad es. l' Algol, il Fortran, Cobol, Pascal e Basic derivano dal Lisp?

No, ma tutte le funzionalità che i vari linguaggi hanno, che stanno introducendo o che introdurranno nei prossimi anni, esistono già in LISP. La programmazione funzionale è cosa nota da decenni nel mondo LISP, ma è novità assoluta nel mondo dei linguaggi mainstream.

Ma è una cosa meno difficile rispetto a creare un proprio linguaggio di programmazione + un proprio compilatore?

Io voglio solo modificare un pochino il compilatore a la sintassi del linguaggio. Probabilmente ho un pochino sopravvalutato la cosa.

Si, è estremamente complesso e richiede una conoscenza profonda del linguaggi che si andrà a modificare e dalla codebase del compilatore su cui mettere le mani.

"Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela ciascuno. Ma se tu hai un’idea, ed io ho un’idea, e ce le scambiamo, allora abbiamo entrambi due idee. "

Ma mi pare di capire che tu non vuoi avere niente a che fare con linguaggi che ritieni inadeguati. Oltretutto li giudichi dopo averli usati per quanto tempo? Un linguaggio è un'entità complessa ed occorrono mesi ( per i più semplici ) per comprenderne la logica.

Per me un linguaggio di programmazione e il codice di un programma sono per certi aspetti come un lingua. Però capisco che ci sono persone che la pensano diversamente da me e rispetto il loro pensiero.

Certo che un linguaggio è una lingua, formale e matematica ma sempre lingua è. E ogni lingua è creata per esprimere determinati concetti in maniera non ambigua, efficiente e completa. Ma questo significa che il rapporto esiste tra linguaggio e problema, non tra linguaggio e mentalità del programmatore. Quest'ultimo deve studiare, capire entrambe le entità e sfruttare il linguaggio per risolvere al meglio il problema. Cioè il programmatore dev'essere flessibile, non può irrigidirsi e buttare a mare linguaggio dopo linguaggio solo perchè non gli piace.

La sintassi è francamente questione di lana caprina. Non stiamo dipingendo quadri, stiamo creando opere ingegneristiche. La semantica è questione più significativa, ma una semantica inadeguata ti porta solo a fare il giro più lungo, ma siccome i linguaggi comuni sono tutti Turing completi, comunque ti consentono di implementare la soluzione per qualsiasi tipo di problema.


Per me esiste la sintassi in Lisp visto che è un linguaggio di programmazione.

Sintassi nel campo dei linguaggi formali ha uno specifico significato. Nel caso di LISP si parla di s-espressioni e il linguaggio non fa differenza tra statement, espressioni, dati e codice.

Mi hai messo la curiosità. Tipo? ^^

Tipo convertire il tutto in C e poi compilarlo con un compilatore C tradizionale. Oppure usare ( cosa che fanno tutti i linguaggi moderni ) un'intermediate representation. I compilatori tradizionali invece usano gli AST. In ogni caso nessuno trasforma istruzioni mnemomiche direttamente in codice macchina ( tranne l'assembly ).



Allora la variabile c'è in assembly. L' hai nominata :D

Ma non si chiama variabile, perchè non porta appiccicate informazioni sul tipo dei dati. La variabile assembly è un alias di un'area di memoria, cioè una stringa che viene trasformata in fase di assembling in un numero che indica una locazione in memoria.


Riguardo alle ultime due frasi: perchè in Asm sono la stessa cosa ed in Pascal no?

Perchè non esiste il concetto di tipo di dato in Assembly.


Il Pascal è un linguaggio ad alto livello e quindi è astratto.

E Assembly? Perchè non sarebbe astratto? Ma dopotutto tutto quello che gira in un computer è astratto, visto che non si tratta di oggetti fisici. Come vedi certi termini non hanno alcun significato nell'ambito informatico.

Io non ho arm e quindi non vado a compilare per arm.

Chi fa un linguaggio in genere non lo crei in modo che possa girare solo su x86.

Questo non lo sapevo. Non so nemmeno cos'è il linking statico.

Appunto. Sono troppe le cose che non conosci per poter esprimere giudizi su linguaggi e modelli di programmazione. Non sarebbe opportuna studiare con umiltà le basi, poi fare pratica con un certo numero di linguaggi e magari solo dopo tirare le somme? Quello che voglio farti capire è che ad oggi non hai gli strumenti minimi per poter arrivare ad una conclusione. Stai mettendo il carro davanti ai buoi.

Io fino ad ora ero convinto che ad es in Pascal, Basic, Cobol, Python etc.. non ci fosse nessun codice esterno da include in un programma.

Il che sarebbe una follia.

In questi linguaggi da quello che hai scritto deduco che il tutto avviene in automatico iin modo che chi scrive il programma non debba includere nessun codice esterno all' interno del programma. Mi hai aperto gli occhi su questa cosa. Nemmeno immaginavo che accadesse una cosa del genere.

No. C'è la libreria standard che è inclusa automaticamente, anche dai compilatori C. Le altre sono a carico del programmatore.

Non so se bisogna inserire per forza tutto il contenuto del rispetto file .h oppure solo una parte.

Lo vedi che ti mancano le basi? Perchè cerchi di risolvere un non problema con una furbata? Un header file contiene sono le firme delle funzioni e poco altro. Il codice sta altrove. E questo codice potrebbe include altro codice ( tramite il meccanismo del linking ) presenti in altri file e librerie. Quindi che fai? Vai in giro a copia-incollare roba? E per risolvere cosa? Levare un paio di #include?

Però se ad es. uno dovesse inserire tutto il codice contenuto della libreria stdio.h direttamente all' interno del programma Hello World scritto in C allora il programma sarebbe più lungo rispetto all' assembly.

Premesso che in stdio.h non c'è il codice ( come già detto sopra ). Ma poi perchè tutta? Se usi una funzione ti serve una funziona non tutte le millemila che ci sono nella libreria standard.

Se non ricordo male uno dei motivi per cui sono stati creati i primi linguaggi ad alto livello (es, anni 70 ed 80) era proprio quello di fare programmi più corti rispetto al rispetto programma scritto in asm.

Veramente era per semplificare la vita dei programmatori e rendere possibile la creazione di software più complesso.


In un altro sito ho visto invece che si possono includere altre 2 librerie:

C:
#include <sys/syscall.h>
#include <unistd.h>

int _start() {
  syscall(__NR_write, 1, "hello world\n", 12);
  syscall(__NR_exit, 0);
  return(0);
}

Non saltare di sito in sito. Hai idea di cos'è una sycall? Ecco, quel programma usa le syscall direttamente. E poi perchè fissarsi con questa cosa della lunghezza? Che poi il programma Assembly che hai postato usa i servizi del DOS per visualizzare del testo. Un tipico programma C usa una serie di funzioni offerte dalla libc, che è creata in modo da poter girare su vari OS. Il programma C che hai postato richiama le system call di un non meglio specificato sistema operativo. Cioè stai confrontando pere con ananas. Che senso può mai avere una cosa del genere?

Scrivendo un programma in Asm con Tasm bisogna scrivere anche le direttive del Tasm ma ci sono una o più librerie che vengono incluse forzatamente nel programma?

No, gli assembler non includono niente automaticamente. Ma queste perchè l'Assembly non è un linguaggio dotato di una libreria standard.
 
Non sapevo il nome tecnico ma anche a me era venuto l' idea di creare questo pre-compilatore. Ho avuto ora la conferma che sia una cosa meno difficile e più fattibile per me ora. Riguardo a questa cosa pensavo: se un compilatore converte il linguaggio ad alto livello in codice macchina forse sarebbe più semplice per me creare un pre-compilatore che converta un preciso programma scritto in un linguaggio X in assembly sintassi Intel e che poi TASM lo riesce ad assemblare e a far funzionare.

Per il resto continuerò ad es. con l' architettura 8086 ed 8008. Continuerò con i rispettivi assembly sintassi Intel perchè per certe cose mi trovo bene.e perchè ho dei progetti che vorrei realizzare.

No, non è così. Non è meno difficile, fa un'altra cosa. Il preprocessore è quello che trovi in C/C++ e che, tra le altre cose, si occupa dell'espansione delle macro. Riprendendo il tuo codice precedente:

C:
#include <stdio.h>

#define IN  1    /* inside a word */
#define OUT 0    /* outside a word */

/* count lines,words, and characters in input */
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);
}

Il preprocessore espande quelle #define, che sono solo delle "etichette", trasformandolo in:

C:
main()
{
    int c, n1, nw, nc, state;

    state = 0
    n1 = nw = nc = 0;
    while (( c = getchar()) != (-1)) {
        ++nc;
        if (c == '\n')
            ++n1;
        if (c == ' ' || c == ''\n || c == '\t')
            state = 0;
        else if (state == 0) {
            state = 1;
            ++nw;
        }
    }
     printf("%d %d %d\n", n1, nw, nc);
}

Ma poi: perchè scrivere un programma che converta da linguaggio X ad assembly? Posto che è completamente inutile, è anche complesso; se il linguaggio X è ad oggetti, che fai? Per non parlare del modo in cui scegliere registri e/o memoria...
Inoltre il compilatore, tra le tante cose, ottimizza il codice prima di generare il codice macchina. E' più ottimizzato il codice di un compilatore (specialmente utilizzando opportuni flags) rispetto a quello generato da un assembler e scritto da un programmatore.

Sono indeciso invece su HLA e Pascal. Se mi butto su un linguaggio devo andare oltre al codice visto che è astratto e io vorrei capire come si è arrivati a quel punto per capire bene il tutto e non credere alla magia.

Capire il tutto, che significa?

Io ho aperto questa discussione anche per avere consigli perchè non voglio come ho fatto in passato mollare un linguaggio o addirittura la programmazione perchè per dei motivi non riesco ad andare avanti. Avevo iniziato con python ed ero arrivato fino ai dizionari. Poi sono passato al Qbasic e dopo un po' l' ho abbandonato. Poi l' ho ripreso e riabbandonato. Stessa cosa con Python. Avevo iniziato il C++ perchè ha delle differenze rispetto al C ma poi ho scoperto che per certe cose è C-like e quindi l' ho mollato. Avevo iniziato con Cobol e dopo pochissimo l' ho abbandonato.
Avevo iniziato con l' assembly ma dopo l' ho abbandonato per dei motivi come ad es. delle cose sono difficile e sia perchè pensavo che partire dall' elettronica fosse un approccio migliore. Però la strada è lunghissima e prima che arriva al livello adatto passeranno gli anni e quindi ho deciso di riprendere l' assembly e l' architettura dei calcolatori.

C++ è C-like, così come Java, C# ed altri ancora.
Partire dall'elettronica non è tutto. L'elettronica è utile per avere alcuni fondamenti, e questi vanno appresi - normalmente - prima di assembly stesso. Stesso discorso per le basi di numerazione. Dovessi anche studiare il Millman, non implicherebbe facilità nell'apprendimento di assembly o di altri aspetti collegati alla programmazione.

Se hai trovato subito ostacoli, significa che hai fatto il passo più lungo della gamba. Non è una buona idea, se non si conosce la programmazione, partire direttamente da assembly.

Inoltre lascia che mi ripeta: va bene studiare asm 8086 per iniziare ad avvicinarsi ad asm e prendere un pò di confidenza con il linguaggio; tuttavia scrivere programmi per 8086 seri, al giorno d'oggi, e che girano su DOS, va ben oltre l'inutilità. Riguardati l'esempio che ti ho mostrato sopra.

Per concludere, nel caso dell'hello world in C, il compilatore (GCC, usando MinGW), genera questo:

Codice:
CPU Disasm
Address   Hex dump          Command                                  Comments
004013C0  /$  55            PUSH EBP                                 ; helloworld.004013C0(guessed void)
004013C1  |.  89E5          MOV EBP,ESP
004013C3  |.  83E4 F0       AND ESP,FFFFFFF0                         ; DQWORD (16.-byte) stack alignment
004013C6  |.  83EC 10       SUB ESP,10
004013C9  |.  E8 42060000   CALL 00401A10
004013CE  |.  C70424 643040 MOV DWORD PTR SS:[LOCAL.4],OFFSET 004030 ; /format => "Hello World!"
004013D5  |.  E8 A6080000   CALL <JMP.&msvcrt.printf>                ; \MSVCRT.printf
004013DA  |.  B8 00000000   MOV EAX,0
004013DF  |.  C9            LEAVE
004013E0  \.  C3            RETN

e come puoi vedere usa la funzione printf di MSVCRT.
 
Ho detto più volte che ognuno di loro ha avuto una o più ragioni per scrivere il linguaggio in un certo modo ed ho pure detto che questo lo rispetto. Ogni persona è diversa, non siamo tutti uguali.

Però non è che gli autori dei linguaggi li scrivano "a sentimento". Un nuovo linguaggio nasce per risolvere un problema ingegneristico importante e sentito. Rust, ad esempio, è nato per consentire la scrittura di codice nel quale siano assenti alcune classi di bug.

Però ci sono delle cose ad es. del C che non condivido, mi trovo male per determinate cose

Per curiosità, quali sono? A parte gli header file.

non mi permettono di imparare questo linguaggio e di fare pratica scrivendo i programmi.

Pure la matematica risulta fastidiosa e richiede sforzo. Però poi ne vale la pena.

Ma tengo in considerazione il fatto che ci sono altre persone che per una o più cose si trovano male con il C, tengo in considerazione il fatto che ci sono svariate persone a cui piace questo linguaggio

"Esistono due tipi di linguaggi: quelli di cui tutti si lamentano e quelli che nessuno usa", Stroustrup, creatore del C++. Non esiste un programmatore che ama ogni singola caratteristica di un dato linguaggio.

Una delle cose che apprezzo del C ed il fatto che non sia proprio un linguaggio ad alto livello visto che per determinate cose è vicino all' assembly e all' hardware.

E se ti dicessi che si può rendere C# o Java o anche Python vicini all'hardware?

Però il problema è che non ho una scaletta precisa e quindi leggo tante cose

Ed è questo che ti sta fregando.

A me non interessano gli algoritmi, il saper risolvere i problemi e diverse cose che riguardano la scienza dell' informatica. A me ad es, non interessa diventare un programmatore software.

Ci vuole pratica per capire certi argomenti, ma bisogna scrivere programmi per fare pratica e ci vuole una buona conoscenza degli algoritmi e delle strutture dati per scrivere programmi.

Mi interessa capire come funziona il computer, dall' elettronica passando per il binario, l' esadecimale fino ai linguaggi di alto livello che ho menzionato.

In questo caso https://www.amazon.it/Architettura-dei-calcolatori-approccio-strutturale&tag=tomsforum-21

Ma il resto che hai citato rientra nell'ambito della programmazione e quindi https://www.amazon.it/Introduzione-agli-algoritmi-strutture-dati&tag=tomsforum-21

Modificare un pochino/un po' un compilatore, secondo me, è meno difficile rispetto a modificarne metà o quasi tutto. Pensa quanto invece sarebbe difficile scrivere da zero o quasi un compilatore. Per questo motivo che l' ho detto più di una volta.

Sbagli. Modificare un software di quella complessità richiede l'averne studiato e compreso l'architettura e quindi letto il codice. In molti casi scrivere un software da zero è più semplice.

Non sapevo il nome tecnico ma anche a me era venuto l' idea di creare questo pre-compilatore. Ho avuto ora la conferma che sia una cosa meno difficile e più fattibile per me ora. Riguardo a questa cosa pensavo: se un compilatore converte il linguaggio ad alto livello in codice macchina forse sarebbe più semplice per me creare un pre-compilatore che converta un preciso programma scritto in un linguaggio X in assembly sintassi Intel e che poi TASM lo riesce ad assemblare e a far funzionare.

Se hai quest'intenzione, allora serviti di LLVM. Ma ritorniamo sempre alle solite, cioè non hai le basi per poter fare una cosa del genere. E il C e C++ sono dei must know per questo genere di attività.

Se mi butto su un linguaggio devo andare oltre al codice visto che è astratto e io vorrei capire come si è arrivati a quel punto per capire bene il tutto e non credere alla magia.

https://www.amazon.it/Compilers-Principles-Techniques-International-Economy&tag=tomsforum-21

https://www.amazon.it/Linkers-Loaders-John-R-Levine&tag=tomsforum-21

Inoltre stai mettendo troppa carne al fuoco. Se fai il saltimbanco ti confondi solamente. Scegli una tecnologia ed esplorala a fondo. Ti piace l'embedded? Bene microPython o Espruino. Ma ancora meglio compra una board Raspberry e programmala in Python. Hai bisogno di conoscere praticamente queste tecnologie, non basta leggere articoli e blog post. Bisogna fare.

"In matematica non esistono vie regie", Euclide. Per l'informatica vale lo stesso.

Avevo iniziato con python ed ero arrivato fino ai dizionari. Poi sono passato al Qbasic e dopo un po' l' ho abbandonato.

E hai sbagliato. Non devi saltare di palo in frasca e non devi abbandonare al primo ostacolo.

ad es. delle cose sono difficile

Altrimenti perchè sono stati inventati altri linguaggi?

Però la strada è lunghissima e prima che arriva al livello adatto passeranno gli anni e quindi ho deciso di riprendere l' assembly e l' architettura dei calcolatori.

Decisione sensata. Ma devi fare pratica.
 
Da come lo dice sembra che la scelta sia personale. Non penso che tu abbia voluto dire cio', per cui rettifico: in campo professionale non si sceglie un linguaggio (o qualsiasi altra cosa) solo perche' piace, c'e' tutta una serie di fattori che occorre tenere conto. A volte c'e' piu' di una scelta, a volte la scelta perfetta non esiste. Anche nel campo amatoriale dovrebbe essere cosi', se uno conosce solo un linguaggio ovvio e' limitato a quello, altrimenti sceglie quello che meglio si appresta allo scopo. Faccio un esempio stupido: un amatore per hobby puo' decidere di costruire una sedia in legno, in casa ha un coltellino svizzero e usa quello, mentre un professionista usera' tutta una serie di strumenti diversi, usera' un martello per piantare chiodi (anche se basterebbe il tacco di una scarpa) e un cacciavite per mettere viti (anche se basta la lama di un coltello).

Io volevo dire che ogni persona ha la libertà di scegliere cosa fare. Ogni persona ha una o più ragioni per fare una o più scelte.

E' vero che a volte c'è più di una scelta. La scelta perfetta non credo esista.

Concordo sul fatto che su uno sceglie solo un linguaggio è limitato solo a quello. Questo ha pregi e difetti.

Concordo sull' esempio che hai fatto che tra l' altro non mi pare stupido.

Sia l' amatore che il professionista possono decidere che legno usare, che attrezzi usare, che cosa acquistare, che colore deve avere la sedia, posso scegliere che cosa studiare etc... Ogni scelta ha i suoi pro ed i suoi contro.

Scusa, con tutto il rispetto, mi pare tu sia ferrato su molti concetti ma qui hai detto troppe imprecisazioni, o non ti sei spiegato bene. Come quando precedentementi dissi che il Assembly non esistono funzioni o strutture.
Stai piu' attento quando ti esprimi per favore. Confondi le idee ai neofiti.

Con rispetto dico: meno male che sei intervenuto :)

Riprendo il punto iniziale del discorso.

Ma lo scopo finale del programmare è fare cosa ?

Perchè io ritengo serva uno scopo, non si programma per il solo gusto di farlo ma per creare qualcosa che prima non c'era.
Io ho cominciato perchè volevo fare i giochi che mi piacevano.
Adesso, oltre a quello che faccio per lavoro, programmo il software che mi serve. Se non mi serve niente di nuovo non programmo.

Sarà anche in base allo scopo finale che verrà scelto il linguaggio adatto.
Come hobby, quando programmo, ho scelto C#.

Delle cose le ho scritte sopra dove ti ho menzionato.
Aggiungo: delle volte mi viene solo lo sfizio, altre volte invece ho visto un progetto di un' altra persona che voglia realizzare, altre cose mi viene a mente un progetto da realizzare, mentre altre volte c'è la necessità di avere una determinata funzione o/e risolvere un determinato problema che si presenta. Altre volte sento il bisogno di realizzare/ creare una qualcosa.

Es. ho riscoperto una vecchia discussione sull' altro forum (dove ci sei pure tu) del 2014 ed ho ancora la necessità in Ms dos 6.22 di premere un tasto sulla tastiera oppure di scrivere un comando che permette di spegnere il pc. Ora mi è venuto in mente anche un altro tasto oppure un altro comando che permetta di riavviare questo s.o.
Uno dei miei interessi è l' Ms Dos. Giorni fa mi è rivenuta la nostalgia e mi sono venuti in mente ricordi passati. Mi riferisco anche al Gw Basic, al Qbasic, ai giochi 2D. Mi era rivenuto in mente il sogno che avevo di imparare i comandi dell' ms dos compresi anche quelli che si utilizzano ne cmd di windows sia dentro all' s.o e sia fuori usando il cd/dvd.

Sono un sognatore, come minimo spesso idealizzo le cose, ed ho la tendenza ad attirare (come una calamita) progetti, creati da altri oppure che ho pensato io, che o non sono alla mia portata oppure che sono distati tanti/tantissimi km (è una metafora). Questo vale anche per l' elettronica.

Ad es. ci sono volte in cui mi viene in mente di voler creare , un gioco 2D ad 8 bit (retrogame) oppure di creare un s.o. monotasking bicolore tipo ms dos 5.00 - 6.22. Delle volte invece mi piacerebbe creare un IA, oppure un umanoide, una rete neurale, il machine learning etc... Mi vengono in mente ad es. D3BO, mi viene in mente il film Transcendence, il film Humandroid, il film Cortocircuito, il film Her etc...
Oppure creare dei portali web tipo quello nella serie tv: Wisdom of the Crowd – Nella rete del crimine . Non mi riferisco ad un portale che riguarda il crimine.
Oppure ad una portale tipo quello nella serie tv APB. Non mi riferisco ad un portale che riguarda la polizia.
Questi due portali hanno uno scopo ben preciso, hanno un utilità maggiore rispetto a FB oppure ad instagram. Non sto criticando FB ed instagram.


Non c'è bisogno di dirmi che anche nel prossimo futuro non potrò fare nulla di quello che ho menzionato in questa risposta. So bene che con le scarse conoscenze che ho, con il mio livello tecnico attuale, ora non vado da nessuna parte e quindi non potrò mai fare nulla. Infatti sono solo dei sogni e basta. Ci sono abituato a rimanere deluso.

Chissà se nel lontano futuro una delle cose riuscirò a realizzarle oppure se rimarranno sempre solamente un sogno.


Concordo con te sul fatto che ci deve essere uno scopo.

Nel mio caso ora se dovessi scegliere un linguaggio con lo scopo preciso di imparare a programmare in generale, imparare gli algoritmi ed imparare a risolvere problema allora so sincero, non lo farei perchè non sono interessato e non è quello che voglio.

Sono più interessato alla programma hardware. Es, Programmare su pc la cpu, il bios, il chipset etc... Creare driver etc...
Non sono interessato a programmare in .NET oppure su JVM. Non mi interessa programmare dietro diversi livelli di astrazione che non permettono l' accesso all' hardware.

Per alcune cose mi trovo nel periodo storico sbagliato :D

Come mai non programmi più in basic per hobby? La mia è solo una curiosità.


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

Già. Ho voglia di imparare, conoscere, chiarire i dubbi, e ricevere consigli adatti a me e non mollare un linguaggio di programmazione o/e la programmazione come è successo più volte in passato.

Quando hai tempo, un po' di righe al giorno, se ti va potresti leggere anche il resto e rispondermi tipo la prossima settimana o quella dopo ancora :)

Purtroppo, o per fortuna, è così. Lo smartphone che hai in mano (il processore, intendo) è più probabilmente un ARM che un Intel.

Vero. Se devo essere sincero preferisco di più i pc, i server e le workstation agli smarphone ed ai tablet^^

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).

Secondo me è importante a livello didattico e dall' altra vorrei scavare nel basso livello visto che c'è l' interesse e vorrei capire.

Mi interessa la programmazione hardware.

Printf va benino.
Poi serve per modificare un pochino/ un po' la sintassi ad es. del C in maniera tale che per me, senza offesa per nessuno, sia almeno un po' sopportabile e quindi mi permette di imparare questo linguaggio, di leggere/capire i programmi, di fare pratica scrivendo i programmi. Se non faccio questo purtroppo devo lasciar perdere il C ed andare su un altro linguaggio di programmazione.

Quello che ha creato Python l' ha dovuto fare perchè con il linguaggio ABC aveva ad es. frustazione e c' erano delle cose che non gli andavano bene.

Io invece sono un neofita però nel corso degli ultimi anni ci ho provato tante volte con il C ma nulla da fare :( Anche questi giorni e ieri ci ho provato scrivendo anche i programmi-esempi sul libro ma alla fine mi è salito un po' l' odio.

Non sto criticando il linguaggio C.

Però ogni persona è diversa: ognuno

fatico un pò a comprendere questo attaccamento alla sintassi... sull'essere o meno strutturato, ho visto che ti hanno già risposto.

Da parte una parte perchè non ho il giusto livello tecnico per spiegarmi al meglio e dall' altra su certe cose la vedo diversamente.

Io fin' ora ho espresso delle mie opinioni personali, senza criticare o offendere il linguaggio C, i suoi creatori, la scienza etc... Ma evidentemente, secondo qualcuno, mi devo per forza trovare bene con il linguaggio C, mi devo per forza trovare bene a programmare in C, mi devo per forza trovare bene a leggere e a capire i linguaggi C.

Ogni persona è diversa, non siamo tutti uguali, ogni persona ha i suoi interessi, la sua mentalità, i suoi gusti, le sue opinioni personali.
La cosa importante è esprimere queste cose con rispetto e senza offendere :)

In un linguaggio, per me conta Anche la sintassi. Questo vale sia per leggere il programma, capire quello che c' è scritto e sia per fare pratica scrivendo programmi in un determinato linguaggio.

Mi rendo conto che ci sono altre persone che la pensano diversamente su questo punto però ognuno è libero di pensarla come vuole :)

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...).

Non conosco bene i linguaggi ad alto livello per capire la tua seconda frase e l' ultima frase.

So benissimo che gli esempi che riporto sono dell' 8086 16 bit e che girano sul DOS :)
L' altro ieri ho installato Ms dos 6.22 su una VM ^^

Tra i miei interessi c'è l' informatica vintage.

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. [/QUOTE]

Opera Snapshot_2018-06-19_181010_www.youtube.com.webp

Qui invece CMP fa la sottrazione?
L' ultima parte non l' ho capito e sono arrivato ad EFLABS. TEST.


Comunque 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.[/QUOTE]

Non è vero che non ho mai affrontato la programmazione.
Ho iniziato nel 2014. Il resto già l' ho scritto. Sono pure arruginito e leggendo su internet tante cose ho un po' di confusione.

Se trovo un linguaggio adatto allora lo porterò fino alla fine^^

Ad essere sincero io non ho la mentalità del programmatore e non ragiono a macchinetta.
A me non interessa diventare programmatore software e nemmeno come hobby. Da quello che hai scritto mi ricorda il corso di laurea in informatica. Anche per hobby non mi interessa questo indirizzo a parte alcuni argomenti.

Per il resto l' ho scritto oggi, nei messaggi di sopra.

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. ;)

Volevo dire che a me non interessa essere preparato per un interrogazione sulla teoria.
Però io non escludo la teoria.
Io leggo sui libri in pdf, dispende universitarie e non, guide, blog, forum ed i video/playlist su youtube che hanno una durata variabile.

All' università ad es. ad informatica di fa molta teoria oppure c'è quasi tutta teoria. Nemmeno per hobby sono interessato a quest' approccio.

La teoria rispetto alla pratica, nel caso è inferiore al 50%.
Le cose che interessano a me sono collegate ad es. all' architettura dei calcolatori, elettronica, programmazione, matematica, fisica, etc...

Forse era un bel periodo in fondo (io non ero ancora nato)... ora come ora, sarà l'astrazione, la mentalità o altro, 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).

Quoto quello che hai scritto.
Come minimo per delle cose io vado controrrente e non perchè sono un alternativo. Questa scelta è in disaccordo a molte persone però a me va bene :)
 
Ultima modifica da un moderatore:
Ecco, come al solito, ora il thread ha perso capo e coda.. se mai li ha avuti.
Ognuno potrebbe entrare e iniziare a rispondere random ai vari pezzettini in cui tutti i discorsi sono stati frantumati.
L'incompetenza e la mancanza di metodo dell'OP hanno disseminato tutto di altre argomentazioni, salti di palo in frasca, digressioni fantasiose.. il motivo che lega, piuttosto che quella che prima ho erroneamente definito "apertura mentale", in realtà è l'anarchia pura: ognuno può fare come gli piace meglio, siamo tutti liberi di farci piacere le cose ecc..

Purtroppo non è precisamente così.


Inviato dal mio Nexus 5 utilizzando Tapatalk
 
Senza citazioni e per precisare:

Non ho detto che deve piacerti per forza il C. Ritengo che tu non abbia competenze paragonabili a chi hai citato, per dire se ti piace o non ti piace. Perché, nell'ambito di ciò di cui stiamo parlando, anche quello che viene definito senso estetico sottostà a competenze tecniche.. ma ovviamente, con il tuo metodo di informarti sulle cose, questo piccolo particolare non lo sai.

Poi ti dico, te lo avevo già detto in passato e anche più sopra: nel modo in cui procedi non ne verrai mai fuori dignitosamente perché, per affrontare i problemi ciclopici che hai nominato devi partire dalle basi e perseverare anche sulle cose che ti annoiano.

Infine, quando mi riferivo al pre-processore intendevo tutt'altra cosa. La traslazione non avviene tra un linguaggio x e assembly. Ma tra il tuo linguaggio "perfetto" e un altro linguaggio di alto livello che sia compilabile.. non è cosa difficilissima.

Inviato dal mio Nexus 5 utilizzando Tapatalk
 
Come mai non programmi più in basic per hobby? La mia è solo una curiosità.
Lo facevo sul Commodore 64 all'inizio ma sia il linguaggio che il sistema erano troppo limitati.
Io volevo poter usare i sottoprogrammi e le funzioni quindi amavo il Simon's Basic.

Quindi sono passato a Visual Basic 6 e mi ha dato molte soddisfazioni.
Adesso sono su C# che sento una evoluzione naturale di quello che facevo in Visual Basic.
 
Io volevo poter usare i sottoprogrammi e le funzioni quindi amavo il Simon's Basic.

E ne approfitto perchè https://en.wikipedia.org/wiki/Simons'_BASIC

Da cui l'OP potrà notare come il Simon's Basic implementa delle keyword ( che poi sono funzioni ) che gestiscono aspetti che il Basic ufficiale del C64 non contemplava. Spero che questa riflessione lo aiuti a comprendere cos'è veramente un linguaggio e perchè qualcuno ha sentito il bisogno di crearlo.
 
Non hai idea della complessità di ciò che stai dicendo di voler fare...

Ora un pochino c'è ho visto che ho fatto delle ricerche su internet ed ho letto quello che avete scritto.
Accantono questa cosa, non c'è problema.

Ma cosa significa "imparare cose che mi servono per la pratica"? Non è tanto questione di teoria dell'informatica, ma di studiare e comprendere le cose che utilizzi. Ed in questo caso copiare del codice in rete, mettere assieme qualcosa, e farlo funzionare... non è sufficiente, così come andare a tentativi.
La pratica è essenziale, ma ci sono concetti ed argomenti che non si possono non sapere, e senza studio andrai sempre un pò "a caso".
I commenti che seguiranno alle tue domande/affermazioni, dovrebbero farti capire che basterebbe aprire un libro e studiare o almeno leggere qualcosa per chiarirsi un pò di aspetti. :)

Imparare cose che servono per fare la pratica. Bisogna leggere e capire le cose che si utilizzano.
Poi imparare anche un minimo di cose di teorica che riguardano i concetti e le definizioni.

Copiare del codice in rete, mettere assieme qualcosa, e farlo funzionare... riguarda il linguaggio C e serviva per farvi capire che per me non conta Solo l' estetica edi motivi per cui non riesco ad andare avanti con questo linguaggio.

Come ho scritto sopra io leggo anche i libri in pdf. In questo thread ho nominato più di una volta la bibbia del C. Ho sia la prima versione che la seconda che ho iniziato a leggere ho visto l' esempio sul libro che ho postato ma come al solito non riesco ad andare avanti con questo linguaggio. Ho visto anche gli esempio su internet.

Ho i libri sull' assembly, sull' architettura dei calcolatori etc...

Se si tratta di leggere in maniera approfondita (non superficiamente) non c'è problema.
Riguardo allo studio, nulla fare. E' uno dei grossi limiti che mi porto da anni. Capisco in pieno che non è una bella cosa.

Stai confondendo un pò le cose...
Il file ".h", che è tipico del C, è l'header. Un programma in C (o C++) può funzionare anche senza file header, non c'è nessun obbligo in tal senso. Sono utili quando scrivi una libreria che ha determinate funzionalità che devono essere poi utilizzate da terzi. In questo modo hai strutture/variabili e dichiarazioni di funzioni in un file (header) che verrà incluso in un sorgente; in tal modo si evitano pure inconsistenze.

Le librerie dll sono dinamiche, come dice il nome stesso. Sono tipiche dell'OS Windows. La libreria dinamica offre funzionalità ad un programma durante la sua esecuzione. La libreria può anche essere inclusa dal programma stesso durante l'esecuzione (usando ad esempio LoadLibrary, che fa parte della WinAPI).

La particolarità delle DLL è che una volta caricate in memoria possono anche essere condivise da più programmi, evitando così di caricare un'istanza nuova della stessa per ogni programma che ne fa richiesta.

Anche sul libro del C avevo capito che fosse librerie ed ora a quanto pare no.

Varie cose che non so le cerco su google e sui libri, dispense etc..

Ho capito quello che hai detto :)
Vado a cercarmi la definizione di libreria statica.

Vuoi fare qualcosa di simile a Scala quasi...
In questo caso però il codice viene trasformato in bytecode (usando il compilatore di Java) e poi interpretato. In pratica è un linguaggio compatibile con la JVM.

No.
Riguarda la storia di modificare un pochino il compilatore per modificare un pochi la sintassi. Però è troppo difficile per me quindi la lascio perdere.

No, sicuramente hai un tantino sottovalutato la cosa.

Hai ragione però è comprensibile.

In realtà, leggendoti, pare il contrario (mi riferisco alla mentalità). I programmatori ed i progettisti hanno dato vita a linguaggi per risolvere problemi che altri linguaggi non riuscivano a risolvere (oppure si, ma non in modo semplice).

Io sto rispettando i diversi linguaggi, i programmatori etc.. Mi sto mettendo nei loro panni e capisco che hanno avuto dei motivi per creare i loro linguaggi e per fare certe scelte rispetto ad altre. Io non sto giudicando nessuno.

Es. ad un programmatore va bene la programmazione ad oggetti, ad un altro no. Ad un programmatore non gli va bene un determinato linguaggio mentre gliene va bene un altro. Etc..

Su certe cose la penso diversamente, ho opinioni diverse però rispetto chi la pensa diversamente da me.

La seconda frase non credo che valga per tutti.
Per me. è un opinione personale, conta Anche la sintassi sia per leggere, capire il programmare, sia per impararlo e sia fare la pratica che dev' essere tanta. Rispetto chi la pensa diversamente su questa cosa e non impongo a qualcuno che la debba pensare come me.

Es. ci sono persone che sono andare sul C perchè il Pascal per loro è rigoroso ed un linguaggio didattico.
Mentre ci sono altre persone che non sono andare sul Pascal ed evitano il C.
Etc...

C'è chi si trova bene su Python ad es. e c'è chi invece si trova male su un altro linguaggio e quindi rimane su Python.
Non ci vedono nulla di male.
Non capisco cosa ci sia di male nel fatto che ognuno abbia una visione diversa, dei gusti/interessi diversi, e che ha esigenze diverse.

Ad es. nel C le parentesi graffe per i blocchi all' interno di una funzione, ad una persona gli devono andare bene/piacere per forza? Mi riferisco anche anche alla pratica e quindi a scrivere i programma. Questa non è una mancanza di rispetto verso il linguaggio C o i programmatori del C.


In automatico non avviene nulla. Ciascun linguaggio ha un'API, e di norma - in generale - mette a disposizione cose come: operazioni di I/O da tastiera e da file, strutture dati (stack, alberi, array dinamici, mappe...), algoritmi di ordinamento, funzioni per operare sulle stringhe (dallo split ad altro), multithreading, alcuni linguaggi anche il supporto grafico (non è il caso ad esempio di C++/C, che fanno uso di librerie esterne... come le Qt, ad esempio). Questo solo per fare alcuni esempi.

Sta poi al programmatore includere la libreria di cui necessita: se hai un numero N di elementi da memorizzare, che cambia nel tempo, ha senso utilizzare un array dinamico (come un vector in C++ o un ArrayList in Java). Che senso avrebbe, lasciando da parte motivi didattici, riscrivere questa funzionalità? Poco o niente. Ecco perchè esistono già funzionalità che il linguaggio mette a disposizione.
Il C è uno di quelli che mette a disposizione meno, rispetto a tanti altri. L'API di C++ è immensa, ad esempio.


Diverse cose che hai scritto non l' ho capite perchè purtroppo le devo imparare.
Per la domanda mi pare di averti risposto nella precedente risposta.

Viene stampato a video "Hello World!", ma senza il dollaro. Quello si chiama carattere terminatore (serve a capire dove termina la stringa). L'esempio che hai preso comunque è di un programma che gira sotto DOS, e non è esattamente identico ad uno che gira sotto Windows; quindi già un confronto di questo tipo non è propriamente corretto.

Mi ero dimenticato che fosse per Ms-dos oppure per il cmd fino ad Xp.

Ho capito quello che hai scritto.

Sembra tu non abbia mai aperto un file header... :D

Invece li ho aperti. Ero convinto che fossero librerie e quindi mi sono messo a rimuovere le parentesi graffe all' interno dei blocchi e sottoblocchi di funzione in maniera tale da poter scrivere leggere, i programmare, fare pratica senza le parentesi graffe. Poi dopo avrei fatto altre piccole modifiche per rendere il C, per me un po' sopportabile. Ma non è una critica.

Ad es. c'è a chi vanno bene le parentesi graffe per aprire e chiudere un blocco di funzione o un sottoblocco e c'è ìnvece a chi non vanno bene. In questo caso non c'è nessuna mancanza di rispetto o offesa se a qualcuno non gli stanno bene le parantesi graffe per i blocchi ed i sottoblocchi relativi alle funzioni.

Mi riferisco anche alla pratica quindi allo scrivere i programmi.

Es. Python non c'è l' ha.

Esempio, in winnt.h, tra le tante dichiarazioni e direttive, trovi cose come:
C:
typedef struct _IMAGE_SECTION_HEADER {
    BYTE Name[IMAGE_SIZEOF_SHORT_NAME];
    union {
        DWORD PhysicalAddress;
        DWORD VirtualSize;
    } Misc;
    DWORD VirtualAddress;
    DWORD SizeOfRawData;
    DWORD PointerToRawData;
    DWORD PointerToRelocations;
    DWORD PointerToLinenumbers;
    WORD NumberOfRelocations;
    WORD NumberOfLinenumbers;
    DWORD Characteristics;
} IMAGE_SECTION_HEADER,*PIMAGE_SECTION_HEADER;

Questa struttura rappresenta una sezione definita nell'header di un EXE.
Quando viene incluso il file header puoi utilizzare questa ed altre strutture e dichiarazioni.

Un po' ho capito.



L'hello world in C sono 2 righe:
C:
#include <stdio.h>

int main()
{
    printf("Hello World!");
    return 0;
}

In assembly non finisci più di scrivere...

Codice:
include  c:\masm32\include\masm32rt.inc


.data
helloWorld        db           "Hello World!", 0

.data?
charWritten       LPDWORD      ?


.code
start:

    push        STD_OUTPUT_HANDLE
    call        GetStdHandle

    push        offset      charWritten
    push        12
    push        offset      helloWorld
    push        eax
    call        WriteConsole

    push        0
    call        ExitProcess

END    start

Io mi riferisco al programma Hello World in C senza includere una libreria e quindi a scrivere il contenuto della libreria all' interno del programma. Includendo una libreria il programma ovviamente è più corto. Vorrei solo capire questo argomento.

Intendi quando viene assemblato, o quando viene eseguito?

In tutti e due i casi.

Per il C++ è lo stesso discorso, comunque.
Sopra ho già risposto in merito ai file header, ed alle dll. Il codice scritto da altri è il sorgente (.c o altro, in base al linguaggio). L'header non viene compilato.

Dimostra solo che il linguaggio è uno strumento, e che ci sono strumenti adatti per svolgere certi compiti e non altri; dimostra anche il fatto che la maggior parte dei sistemi operativi sono scritti in C e/o C++, con parti di assembly (dove non si può fare diversamente, ed usato inline quando si può).

Secondo me quello che hai scritto è generalizzato.
Chi ha creato ogni linguaggio ha deciso anche come doveva essere la sintassi.
Es. il creatore di Python nonsi è ispirato al C per quanto riguarda le parentesi graffe. Non ha messo la funzione main o int main. Non ha incluso librerie etc.. Questo dimostra qualcosa.

Il creatore del C non si è ispirato a Pascal e tra l' altro ha scritto i motivi per cui non gli piace questo linguaggio.
anche io ho tutto il diritto di scrivere i motivi per cui non mi piace il linguaggio C, senza offendere e senza mancare di rispetto.

Se dico che per dei motivi a me non piace il linguaggio C, rispettando le opinioni degli altri e senza imporre il mio pensiero a nessuno, non offendo e non manco di rispetto a linguaggio e ai suoi creatori.

Prima invece i sistemi operativi venivano scritti solo in Ams. Poi dopo per le parti non critiche veniva utilizzato il C. Poi il C ha preso ancora più piede ma ci sono delle parti in Asm.
Altri linguaggi sono stati utilizzati per creare sistemi operativi. Es. il Pascal. Il successo di un linguaggio di programmazione rispetto ad un altro non credo che riguarda questo discorso.

La tabulazione non ha nulla a che vedere con il paradigma del linguaggio...

Pabloski mi ha detto che su Python la tabulazione o/e forse anche l' indentazione sostituiscono ad es. begin ed end presenti nel pascal.

Che vuol dire la prima frase su assembly puro ed assembly con l'assemblatore? E poi non c'è un nesso con i paradigmi di programmazione.

L'assemblatore riceve in input un sorgente in assembly e lo assembla, producendo poi il codice macchina. E' più semplice rispetto ad un compilatore.

Ho scritto un pò di fretta, ma spero si sia compreso tutto.

Assembly puro ed assembly che contiene nel programma le direttive dell' assemblatore.

Pabloski mi ha detto che entrambi sono non-strutturati.
Io vorrei capire ed imparare la differenza tra i due perchè un programma in assembly con le direttive dell' assemblatore contiene dei blocchi.


Invece è fattibile creare un programma 16 bit che converta un programma 16 bot scritto in linguaggio A (creato da me) in un linguaggio assembly 8086 e che poi venga in automatico assemblato da Tasm è fattibile?
Questo programma dovrà funzionare solo con 1 o 2 programmi e basta.

Se invece dovessi creare un programma che converta qualsiasi programma scritto nel linguaggio A in assembly e che poi venga assemblato in automatico da Tasm allora mi sembra più difficile.

Credo che sia più facile che il programma venga convertito in assembly e che poi ci pensa Tasm a convertirlo in codice macchina perchè altrimenti la cosa sarebbe più complessa giusto?


P.S. non c'è nessuna fretta. Leggi quello che ho scritto e scrivi con calma :D
 
Ultima modifica da un moderatore:
Pubblicità
Pubblicità
Indietro
Top