Dall'assembly ai linguaggi di alto livello

  • Autore discussione Autore discussione Utente 125751
  • Data d'inizio Data d'inizio
Pubblicità
Non ho capito il paragone con il C che tra l' altro in passato gli avevo dato solo un' occhiattina e non è sufficiente per capire il paragone.

Si riferisce alla rappresentazione in memoria delle stringhe. Se tu hai una stringa "Pippo", come fai a sapere quando termina? Il processore vede solo celle di memoria contigue, per cui ci dev'essere qualcosa che gli dica quando una stringa termina. In C questo qualcosa è il codice 0 ( non il simbolo che digiti sulla tastiera che ha codice 48, ma proprio il valore 00000000 binario ). Altri linguaggi invece prepongono la dimensione alla stringa. Cioè "5Pippo", 5 sempre come valore binario e non il numero 5 che si digita sulla tastiera, ovviamente ho dovuto scrivere il 5 della tastiera perchè il valore binario non verrebbe visualizzato dal csm del forum. Gw-basic riserva i primi 3 caratteri ( non so perchè abbiano fatto così, Pascal codifica la lunghezza in maniera più compatta ) per la lunghezza della stringa.

Il tipo di ritorno? Questa non la so.

Non esistono tipi di ritorno in Gw-basic, perchè è a tipizzazione dinamica e le funzioni che supporta sono di fatto della lambda e non le classiche funzioni "typed" dei normali linguaggi. Ovviamente ritorna il valore di una variabile intera farà della funzione una funzione che ritorna un intero. Ma ripeto, il tipo di ritorno viene calcolato dal linguaggio.


Wiki.com dice che l' Assembly come paradigma è imperativo e non-strutturato mentre sul Dartmouth e GW-basic dice che è non-strutturato. Da questo deduco che hanno in comune il fatto che sono linguaggi non strutturati.

Si e no. Gw-basic supporta alcuni costrutti che consentono di creare strutture nel programma. Gosub invoca una subroutine, anche se da nessuna parte c'è un modo per definire in maniera distinta e visibile con facilità l'inizio e la fine di una subroutine. Questo s'intende per non strutturato.

Comunque tutti i linguaggi citati sono imperativi, cioè vogliono ordini ( sotto forma di istruzioni ) da eseguire strettamente nella sequenza stabilita dal programmatore.
 
Un riassunto di tutta la domanda-argomentazione?
Vuoi sapere su che linguaggio focalizzarti?

In questi ultimi giorni ho imparato altre cose sui diversi linguaggi di programamazione, sulla sintasi e semantica etc... per fornirti più elementi possibili però ho ancora tantissimo da imparare e ci saranno altri elementi che non posso forniti perchè al momento non li conosco.

Provo a fare un riassunto.
Per la seconda domanda: si

Mi interessa l' assembly (sintassi Intel su cpu Intel) e piano piano lo voglio continuare però sto cercando un linguaggio di programmazione che:

  1. prenda spunto per determinate cose ad es. dall' Assembly (sintassi Intel con tasm), dal Cobol, dal Pascal, dal Dartmouth Basic/GwBasic e dal C.
  2. non sia proprio a basso livello come appunto l' assembly (non intendo il codice macchina)
  3. non abbia i limiti del Quick Basic, del Pascal, del Cobol o di Python.
  4. non preveda il richiamo di una o più librerie nel programma. Quindi credo che non debba avere ad es. un preprocessore.
  5. non abbia o non preveda l' uso obbligatorio delle parentesi per aprire e chiudere un blocco di funzione ed di un prototivo della funzione o/e all' interno della funzione
  6. non abbia un blocco di funzione con le parentesi all' interno di un altro blocco di funzione
  7. non si aspetti che una o più funzioni debbano per forza restituire qualcosa.
  8. non abbia la keyword "void" tra parentesi
  9. non ci sia l' obbligo ogni volta di mettere "begin" come accade ad es. nel Pascal.
  10. abbia le istruzioni aritmetiche e quelle di controllo uguali oppure molto simili a quelle dell' assembly sintassi Intel.
  11. abbia anche abbreviazioni mnemoniche
  12. sia general purpose



Si riferisce alla rappresentazione in memoria delle stringhe. Se tu hai una stringa "Pippo", come fai a sapere quando termina? Il processore vede solo celle di memoria contigue, per cui ci dev'essere qualcosa che gli dica quando una stringa termina. In C questo qualcosa è il codice 0 ( non il simbolo che digiti sulla tastiera che ha codice 48, ma proprio il valore 00000000 binario ). Altri linguaggi invece prepongono la dimensione alla stringa. Cioè "5Pippo", 5 sempre come valore binario e non il numero 5 che si digita sulla tastiera, ovviamente ho dovuto scrivere il 5 della tastiera perchè il valore binario non verrebbe visualizzato dal csm del forum. Gw-basic riserva i primi 3 caratteri ( non so perchè abbiano fatto così, Pascal codifica la lunghezza in maniera più compatta ) per la lunghezza della stringa.

Anche il Cobol credo che proponga la dimensione alla strinza se non ricordo male.

Ho capito quello che hai scritto :)


Non esistono tipi di ritorno in Gw-basic, perchè è a tipizzazione dinamica e le funzioni che supporta sono di fatto della lambda e non le classiche funzioni "typed" dei normali linguaggi. Ovviamente ritorna il valore di una variabile intera farà della funzione una funzione che ritorna un intero. Ma ripeto, il tipo di ritorno viene calcolato dal linguaggio.

Ho fatto ricerche in questi giorni tra le varie cose sono andato a vedere ad es. la tipizzazione dinamica, statica e cos'è una funzione lamba. E' un po' un casino :(

L' assembly ha le funzioni lambda?

Il C++ c'è l' ha mentre il C ed il Pascal?


Ho cercato su internet "funzioni typed" ma mi mostra i tipi di funzioni che ad es. in C sono 4.

In assembly ci sono le funzioni typed?


QUOTE="pabloski, post: 6850134, member: 21773"]
Si e no. Gw-basic supporta alcuni costrutti che consentono di creare strutture nel programma. Gosub invoca una subroutine, anche se da nessuna parte c'è un modo per definire in maniera distinta e visibile con facilità l'inizio e la fine di una subroutine. Questo s'intende per non strutturato.

Comunque tutti i linguaggi citati sono imperativi, cioè vogliono ordini ( sotto forma di istruzioni ) da eseguire strettamente nella sequenza stabilita dal programmatore.[/QUOTE]

L' assembly è non strutturato?

Però il C si discosta visto che introduce anche le funzioni. Ci sono la parentesi per aprire e chiudere un blocco di funzione, un blocco di funzione all' interno di un blocco di funzione e forse anche una subroutine.
Il C è meno imperativo rispetto all' assembly e credo anche al Bobol, Dartmouth Basic/GW Basic e forse anche al Pascal giusto?
 
Ultima modifica da un moderatore:
Mi interessa l' assembly (sintassi Intel su cpu Intel) e piano piano lo voglio continuare però sto cercando un linguaggio di programmazione che

Mi pare che però tu stia cercando di incollare due estremi. Cioè l'assembly non ha nessuna delle caratteristiche che hai citato in quella lista. A questo punto non capisco ( se è l'assembly il tuo focus ) a che ti serve un altro linguaggio?

prenda spunto per determinate cose ad es. dall' Assembly (sintassi Intel con tasm), dal Cobol, dal Pascal, dal Dartmouth Basic/GwBasic e dal C.

Alla fin fine prendono tutti spunto da LISP. Tranne Assembly che è una rappresentazione mnemonica del linguaggio macchina e quindi non implementa elementi astratti.

non abbia i limiti del Quick Basic, del Pascal, del Cobol o di Python.

Ogni linguaggio ha dei limiti, ma con tutti i linguaggi Turing-completi si può fare di tutto. Python semmai ha un limite tecnico di non essere compilabile AOT. Ma questo non implica nulla se non in casi molto particolari.

non preveda il richiamo di una o più librerie nel programma. Quindi credo che non debba avere ad es. un preprocessore.

Tranne C e C++, quasi tutti gli altri non hanno questa stramberia che è il preprocessore. E per librerie, beh, dipende da te che scrivi il programma. Una libreria è una raccolta di codice che fa delle cose e questo codice è già scritto. Se non vuoi usare librerie, semplicemente devi scrivere tu tutto il codice di cui necessiti. Ma a che pro?

non abbia o non preveda l' uso obbligatorio delle parentesi per aprire e chiudere un blocco di funzione ed di un prototivo della funzione o/e all' interno della funzione

Python non usa parentesi per i blocchi. Ma usa la tabulazione. Alla fin fine dev'esserci un modo per dire al compilatore/interprete che lì c'è un blocco. E no, senza blocchi hai un linguaggio non strutturato e perdi automaticamente il 90% dei meccanismi di alto livello che distinguono i linguaggi "normali" dall'assembly.

non abbia un blocco di funzione con le parentesi all' interno di un altro blocco di funzione

La capacità di innestare blocchi è un plus non un minus.

non si aspetti che una o più funzioni debbano per forza restituire qualcosa.

C e C++ usano void in questo caso.

non abbia la keyword "void" tra parentesi

Void tra parantesi, intendi un parametro di tipo void? Int pure va specificato tra parentesi. Ma non capisco perchè ti fissi con questi dettagli sintattici. Alla fin fine per realizzare programmi bisogna scrivere tantissimo, tanto da consumare la tastiera ( no, non scherzo ).

non ci sia l' obbligo ogni volta di mettere "begin" come accade ad es. nel Pascal.

Ci sarà un altro modo, ma devi dirgli dove inizia e finisce un blocco. Il computer non può entrare nella tua testa ed immaginare cosa volevi fare.

abbia le istruzioni aritmetiche e quelle di controllo uguali oppure molto simili a quelle dell' assembly sintassi Intel.

Nessun linguaggio lo fa, per il semplice motivo che in assembly non esiste il concetto di tipo di variabile. Si opera su stringhe di bit, applicando delle operazioni definite dal linguaggio macchina. Il codice assembly non distingua tra int, short, long.

abbia anche abbreviazioni mnemoniche

Why? Le istruzioni dei comuni linguaggi sono ad un livello molto più alto rispetto al linguaggio macchina ed è questo che li rende produttivi.

sia general purpose

Ovvero Turing-completo.



L' assembly ha le funzioni lambda?

No, l'assembly non ha nemmeno il concetto di funzione. In assembly salti in determinati punti della memoria, in maniera assoluta o al verificarsi di una condizione, e in quei punti l'esecuzione riprende. Puoi simulare una funzione/procedura passando i parametri tramite registri o stack, ma è una simulazione. Non esiste in assembly il concetto di funzione!

Il C++ c'è l' ha mentre il C ed il Pascal?

No. C e Pascal sono linguaggi strettamente procedurali. E non è un male.

Il concetto di lambda viene dalla matematica e dalla programmazione funzionale. Tutti i linguaggi moderni posseggono simili astrazioni, alcune ne posseggono molte altre.

Ma il punto è che non esiste un linguaggio che in assoluto sia migliore degli altri.

Ho cercato su internet "funzioni typed" ma mi mostra i tipi di funzioni che ad es. in C sono 4.

In assembly ci sono le funzioni typed?

Typed significa tipizzato. E' riferito al modello di tipizzazione del linguaggio ( forte, debole ). Non c'è un riferimento diretto alle funzioni.


L' assembly è non strutturato?

E' il più famoso dei linguaggi non strutturati.

Però il C si discosta visto che introduce anche le funzioni. Ci sono la parentesi per aprire e chiudere un blocco di funzione, un blocco di funzione all' interno di un blocco di funzione e forse anche una subroutine.
Il C è meno imperativo rispetto all' assembly e credo anche al Bobol, Dartmouth Basic/GW Basic e forse anche al Pascal giusto?

No. Imperativo significa che il linguaggio esegue le istruzioni passo-passo, così come vengono elencate dal programmatore. Perchè esistono linguaggi che modificano l'ordine di esecuzione dei comandi, ovvero il programmatore specifica cosa vuole ma poi è il linguaggio a decidere come ottenere quel risultato.

I linguaggi dichiarativi ad esempio sono così.

Ma il punto centrale relativo al confronto assembly-c, è che l'assembly non è un linguaggio nel senso matematico della parola. Un linguaggio definisce un modello di programmazione, cioè una macchina virtuale immaginaria che contiene tipi di dati ( variabili ), blocchi, comandi/parole chiave, meccanismi di accesso e gestione della memoria.

L'assembly non ha assolutamente niente di tutto questo. E' una traduzione, in un qualcosa di un pò più comprensibile, del linguaggio macchina, cioè del modello di programmazione del microprocessore ( hardware ).

Per cui ogni linguaggio implementa il suo modello di programmazione, che deriva dal ramo teorico, matematico. Il modello del C è usato nella stragrande maggioranza dei linguaggi comuni, ma esistono modelli diversi implementati da linguaggi come Smalltalk ( per esempio ).

Basti notare che già se si prende il solito modello di memoria, abbiamo questa situazione http://canonical.org/~kragen/memory-models/

Ed è solo il modo per piazzare, leggere e manipolare i dati in memoria.
 
Mi pare che però tu stia cercando di incollare due estremi. Cioè l'assembly non ha nessuna delle caratteristiche che hai citato in quella lista. A questo punto non capisco ( se è l'assembly il tuo focus ) a che ti serve un altro linguaggio?

Credo (spero di non sbagliare alla grande) che l' assembly rispetti il punto 3, 4,5,6,7,9,10,11 e 12.

Capisco che sono due estremi però io volevo soltanto capire le differenze per quanto riguarda la sintassi (o forse anche la semantica) tra i vari linguaggi come ad es: Assembly, C, Algol, Fortran, Pascal, Cobol, Python, Dartmouth Basic (compilato), Gw Basic, Quick Basic e Aida. Perchè questo? Beh perchè così poi posso farvi capire le caratteristiche che deve avere il linguaggio che cerco. Questo linguaggio sarà adatto a me.

Ogni persona è diversa, ognuno ha esigenze, gusti e mentalità diversa. Esistono tantissimi linguaggi di programmazione compresi anche quelli che sono conosciuti da poche forse pochissime persone nel mondo.

L' assembly e l' elettronica sono il mio focus però mi rendo conto che il percorso è molto più lungo di quanto avevo previsto e che sto trovando un po' difficoltà a capire delle cose riguardanti l' architettura del 8086, l' assemblatore ed un po' astrazione che per ora vedo. L' 8086 (e il suo assembly) lo metterò in pausa per il momento per dedicarmi ad un altro assembly Intel considerando anche uno o due progetti. Però per questo semmai aprirò una discussione apposita perchè non voglio incasinare/allungare questa discussione.

In parallelo cerco un linguaggio che non sia a basso livello come l' assembly, che sia meno complesso, che richieda meno conoscenze dell' architettura hardware, che non abbia a che fare con i bit e che richieda meno tempo prima di poter scrivere dei programmi etc... (non sto pensando ai videogiochi o ad un sistema operativo), che rispetti le caratteristiche che ho menzionato sopra e che mi permette di esprimere anche solo un pochino me stesso e la creatività.


Alla fin fine prendono tutti spunto da LISP. Tranne Assembly che è una rappresentazione mnemonica del linguaggio macchina e quindi non implementa elementi astratti.

Riguardo alla prima frase: non mi pare che tutti i linguaggi tranne l' assembly prendano spunto dal Lisp.

Ogni linguaggio ha dei limiti, ma con tutti i linguaggi Turing-completi si può fare di tutto. Python semmai ha un limite tecnico di non essere compilabile AOT. Ma questo non implica nulla se non in casi molto particolari.

Ho trovato la pagina di Wiki in inglese su Turing-completi però la cosa come minimo un po' complicata.

Anche il GW-basic ed il Quick basic sono interpretati.

Ogni linguaggio ha i suoi pro e contro ed i suoi limiti che non sono uguali per tutti.

Il linguaggio C non ha i limiti che hanno il Pascal, i vari Basic, Python e Cobol. Il linguaggio C è compilato (Python, Gw Basic e Quick Basic no) quindi è più veloce, più potente, si possono fare più cose, non è didattico come i vari Basic, il Pascal e Python, è più difficile, permette sotto centri aspetti di entrare a contratto con l' hardware ed è general purpose a differenza di Cobol oppure Algol oppure Fortran.

Un aspetto che mi piace del C è proprio la marea di cose che può fare. Per es. driver, bootloader ed altri programmi a basso livello (o quasi) ma anche un livello un po' più alto, poi sistemi operativi, videogiochi ed è molto usato anche nel settore embedded.

Tranne C e C++, quasi tutti gli altri non hanno questa stramberia che è il preprocessore. E per librerie, beh, dipende da te che scrivi il programma. Una libreria è una raccolta di codice che fa delle cose e questo codice è già scritto. Se non vuoi usare librerie, semplicemente devi scrivere tu tutto il codice di cui necessiti. Ma a che pro?

Anche secondo me è una stramberia.

Ma io intendevo che il linguaggio che cerco non deve avere l' obbligo di inserire per forza una o più librerie per scrivere un programma.

Ad es. l' assembly, il Pascal, Python e Cobol non hanno questo obbligo. Es. in Python per chi vuole (la cosa non è obbligatoria) può tranquillamente importare ad es. una libreria per la GUI e quindi creare un programma con la gui oppure importare "pygame" e creare un videogioco (non ai livelli di uno creato in C++).

Python non usa parentesi per i blocchi. Ma usa la tabulazione. Alla fin fine dev'esserci un modo per dire al compilatore/interprete che lì c'è un blocco. E no, senza blocchi hai un linguaggio non strutturato e perdi automaticamente il 90% dei meccanismi di alto livello che distinguono i linguaggi "normali" dall'assembly.


Anche il Dartmouth Basic e il Gw Basic non sono strutturati eppure sono linguaggi ad alto livello di cui il primo è compilato. Hanno dei meccanismi di alto livello.

Mentre i linguaggi ad alto livello strutturati hanno in più, altri meccanismi di alto livello rispetto ai due Basic che ho menzionato io.

Credo che anchel' assembly con l' assemblatore (es. Tasm) usa la tabulazione o/e anche l'indentazione. Giusto?



La capacità di innestare blocchi è un plus non un minus.

Non ho detto che sia un minus oppure un plus.

Non mi piace (è un' opinione/gusto personale) che ci sia un blocco di istruzioni all' interno di un altro blocco di istruzioni che poi in più introduce altre due parentesi (apri e chiudi) oppure

Ho scoperto a malincuore che non basta eliminare tutte le parentesi graffe da tutte le librerie del C presenti all' interno del compilatore per poter scrivere in C un blocco di funzione senza le parentesi apri e chiudi.
Ho usato uno di quei programmi che permette di selezionare i file e di scrivere cosa eliminare all' interno di essi.
Eliminare le parentesi graffe dalle librerie del C era solo il primo passo :)

C e C++ usano void in questo caso.

Si vero. Ci può anche essere scritta un' altra istruzione al posto del void però nel linguaggio ma il punto è che: cerco se ci sono una o più funzioni non si devono per forza aspettare di restituire qualcosa.


Void tra parantesi, intendi un parametro di tipo void? Int pure va specificato tra parentesi. Ma non capisco perchè ti fissi con questi dettagli sintattici. Alla fin fine per realizzare programmi bisogna scrivere tantissimo, tanto da consumare la tastiera ( no, non scherzo ).

Intendo voip come parametro, però vale anche con in t come parametro.
Poi ho visto delle volte in cui c'è il voip all' inizio della funzione e poi il void come parametro. Tutti e due nella stessa riga.

Io capisco che a moltissime persone questa cosa piace e lo rispetto. Se devo essere totalmente sincero a me non piace.

Ci sono dei dettagli sintattici di uno o più linguaggi che a te non piacciono ? :)

Riguardo all' ultima frase quello che hai detto è estremamente vero e per me non c'è nessun problema se c'è la necessità di scrivere tantissimo anzi a me va bene.


Ci sarà un altro modo, ma devi dirgli dove inizia e finisce un blocco. Il computer non può entrare nella tua testa ed immaginare cosa volevi fare.

Un altro modo sicuramente ci sarà per dirglielo.

Nell' assembly (non mi riferisco a quello puro) non ci sono parentesi apri e chiudi oppure i marcatori per indicare dove inizia e finisce un blocco. Sarei curioso di sapere il perchè ^^


Nessun linguaggio lo fa, per il semplice motivo che in assembly non esiste il concetto di tipo di variabile. Si opera su stringhe di bit, applicando delle operazioni definite dal linguaggio macchina. Il codice assembly non distingua tra int, short, long.

Mi accorgo che dovevo specificare meglio perchè purtroppo hai frainteso quello che ho scritto.

Le istruzioni aritmetiche e quelle di controllo, uguali oppure molto simili a quelle dell' assembly sintassi Intel, nel linguaggio ad alto livello che cerco saranno a differenza dell' assembly, istruzioni ad alto livello. Saranno quindi astratte e non avranno niente a che fare con i registri e con i bit.


Riguardo al discorso della variabili in assembly. Con un assemblatore, es. Tasm si dichiarano le variabili all' interno .DATA e all' interno di STARTUP si fanno le varie operazioni con le variabili ed i registri. Non si possono fare le operazioni tra 2 variabili se una delle 2 non si trova in un registro.

Nel Pascal, che è un linguaggio ad alto livello, c'è il compilato e ad es. le variabili non hanno nulla a che fare con i registri ed i bit. Ad es. non bisogna affatto preoccuparsi di dichiarare la dimensione in bit di una o più variabili cosa che invece va fatta in assembly con un assemblatore.

Why? Le istruzioni dei comuni linguaggi sono ad un livello molto più alto rispetto al linguaggio macchina ed è questo che li rende produttivi.

Mi sono reso conto ora che avrei doluto aggiungere un altro frase per spiegare quello che intendevo dire. Purtroppo hai interpretato diversamente però ora ti spiego.

Per me le abbreviazioni mnemoniche sono delle abbreviazioni di una o più istruzioni che fanno ricordare l' istruzione o le istruzioni (non abbreviate) oppure l' istruzione/le istruzioni tradotte in italiano.

Però c'è da dire che:

A) nell' assembly sono una corrispondenza 1:1 del codice esadecimale e del codice binario. Sono istruzioni a basso livello e non c'è di mezzo il compilatore oppure l' interprete. Non c'è astrazione. Hanno a che fare con i byte ed i registri. (se mi sono dimenticato altro aggiungilo pure^^).


B) nei linguaggi ad alto livello come ad es. il C, il Pascal e Gw Basic e Quick Basic la situazione è opposta rispetto al punto 1, visto che le "abbreviazione mnemoniche" (è meglio forse mettere il tutto tra virgoletta perchè probabilmente il termine non è corretto a livello informatico per quanto riguarda gli HLL) sono abbreaviazione di una o più istruzioni astratte e quindi ad alto livello, non hanno a che fare con i byte ed i registri, non c'è corrispondenza 1:1 etc... e c'è un compilatore che converte il codice in assembly e poi in codice macchina (con il compilatore) oppure prima in codice pseudo-assembly e poi in codice macchina tramite un interprete.

Es. nei due Basic che ho menzionato: CLS , che sta per clear screen
Anche in pascal c'è un abbreviazione di clear screen che è diversa da CLS.

Nel C ci sono ad es. queste abbreviazioni:

https://stackoverflow.com/questions...-the-str-function-abbreviations-acronyms-mean


Es. nell' assembly c'è CMP però ci può essere in linguaggio ad alto livello CMP ma che a differenza nell' assembly sia un abbreviazione "mnemonica" astratta ad alto livello che non abbia a che fare con i bit ed i registri ma che fa la comparazione tra due variabili che non hanno a che fare con i registri ed i bit.

Sono un neofita e ho un po' di difficoltà per il momento a spiegare questi concetti che non sono semplici visto il mio livello.




Ovvero Turing-completo.

Ad es. il cobol, l' Algol ed il Fortran non sono general purpose.



No, l'assembly non ha nemmeno il concetto di funzione. In assembly salti in determinati punti della memoria, in maniera assoluta o al verificarsi di una condizione, e in quei punti l'esecuzione riprende. Puoi simulare una funzione/procedura passando i parametri tramite registri o stack, ma è una simulazione. Non esiste in assembly il concetto di funzione!

In assembly a differenza degli altri linguaggi non c'è la distinzione tra procedure e funzioni.


No. C e Pascal sono linguaggi strettamente procedurali. E non è un male.

Il concetto di lambda viene dalla matematica e dalla programmazione funzionale. Tutti i linguaggi moderni posseggono simili astrazioni, alcune ne posseggono molte altre.

Ma il punto è che non esiste un linguaggio che in assoluto sia migliore degli altri.

Infatti non ho mai pensato o detto che un linguaggio sia in assoluto migliore degli altri. Io penso e credo che ogni linguaggio hai i suoi pro ed i suoi contro.


Typed significa tipizzato. E' riferito al modello di tipizzazione del linguaggio ( forte, debole ). Non c'è un riferimento diretto alle funzioni.

Buono a sapersi. Ho imparato una cosa nuova ^^

E' il più famoso dei linguaggi non strutturati.

Invece con ad es. Tasm quando si scrive un programma ci sono anche le istruzioni che non hanno parte dell' assembly puro ma appartengono all' assemblatore. In questo caso il linguaggio è sempre non strutturato?

Ad es. con il Pascal e l' Ada noto che i programmi possono essere o un po' strutturati oppure più strutturati. Nel secondo caso c'è un blocco di istruzioni all' interno di un altro blocco di istruzioni. Nell' assembly con ad es. Tasm (non assembly puro) non c'è un blocco di istruzioni all' interno di un altro blocco di istruzioni.


No. Imperativo significa che il linguaggio esegue le istruzioni passo-passo, così come vengono elencate dal programmatore. Perchè esistono linguaggi che modificano l'ordine di esecuzione dei comandi, ovvero il programmatore specifica cosa vuole ma poi è il linguaggio a decidere come ottenere quel risultato.

I linguaggi dichiarativi ad esempio sono così.

Ma il punto centrale relativo al confronto assembly-c, è che l'assembly non è un linguaggio nel senso matematico della parola. Un linguaggio definisce un modello di programmazione, cioè una macchina virtuale immaginaria che contiene tipi di dati ( variabili ), blocchi, comandi/parole chiave, meccanismi di accesso e gestione della memoria.

L'assembly non ha assolutamente niente di tutto questo. E' una traduzione, in un qualcosa di un pò più comprensibile, del linguaggio macchina, cioè del modello di programmazione del microprocessore ( hardware ).

Per cui ogni linguaggio implementa il suo modello di programmazione, che deriva dal ramo teorico, matematico. Il modello del C è usato nella stragrande maggioranza dei linguaggi comuni, ma esistono modelli diversi implementati da linguaggi come Smalltalk ( per esempio ).

Basti notare che già se si prende il solito modello di memoria, abbiamo questa situazione http://canonical.org/~kragen/memory-models/

Ed è solo il modo per piazzare, leggere e manipolare i dati in memoria.

Ho capito la differenza tra i linguaggii imperativi e dichiarativi.

Nei linguaggii imperativi ci sono anche i comandi giusto?


Ho visto che il modello di programmazione è diverso in Smalltalk però come si chiama questo modello? E' dichiarativo?


Ho visto il modello di memoria nei diversi linguaggi che ci sono nel link che hai postato. Peccato che l' argomento è complesso per me :(
 
Ultima modifica da un moderatore:
Credo (spero di non sbagliare alla grande) che l' assembly rispetti il punto 3, 4,5,6,7,9,10,11 e 12.

ehhh no

il punto 3 no, perchè pascal consente di fare qualsiasi cosa, alla pari dell'assembly
il punto 4 nemmeno, dato che il concetto di libreria non è relativo al linguaggio...esistono programmi c, pascal, rust che non richiamano nessuna libreria...voglio anche precisare che il preprocessore non c'entra niente con le librerie
il punto 7 è mal posto, visto che assembly non ha la nozione di funzione
il punto 9 idem, perchè assembly non è strutturato
il punto 12 nemmeno, perchè tutti i linguaggi che hai citato sono general purpose

Questo linguaggio sarà adatto a me.

Futile esercizio. L'unico linguaggio perfetto è quello che crei tu. E nemmeno. Stroustrup ( inventore del C++ ) ritiene che il suo linguaggio sia diventato un mostro.

Ogni persona è diversa, ognuno ha esigenze, gusti e mentalità diversa.

Certamente. E infatti esistono vari paradigmi di programmazione. Ma le tipologie esistenti non soddisfanno appieno nessuno, questo perchè in ingegneria non esiste la perfezione ma solo i trade-off.

Se vuoi un linguaggio veramente diverso e simil-assembly in quanto ad assenza di sintassi, prova LISP.

Esistono tantissimi linguaggi di programmazione compresi anche quelli che sono conosciuti da poche forse pochissime persone nel mondo.

Poi però ci fai ben poco perchè non hanno un'ecosistema sviluppato. Scrivere software è costosissimo e il più grande valore è l'aver tantissime librerie belle e pronte da utilizzare.


L' assembly e l' elettronica sono il mio focus però mi rendo conto che il percorso è molto più lungo di quanto avevo previsto e che sto trovando un po' difficoltà a capire delle cose riguardanti l' architettura del 8086

E non ti servirà a molto, perchè in ambito elettronico/embedded/iot l'architettura x86 praticamente non esiste. E' tutto dominato da ARM e AVR.

In parallelo cerco un linguaggio che non sia a basso livello come l' assembly, che sia meno complesso, che richieda meno conoscenze dell' architettura hardware, che non abbia a che fare con i bit e che richieda meno tempo prima di poter scrivere dei programmi etc...

Esistono board che supportano Python, ma in generale il linguaggio che chiedi è il C.


Riguardo alla prima frase: non mi pare che tutti i linguaggi tranne l' assembly prendano spunto dal Lisp.

Molti concetti li hanno copiati da LISP. Tutta la programmazione funzionale che tanto fa figop di questi tempi è scopiazzata da LISP. Assembly è l'unico che non ha nulla di LISP, dato che non implementa astrazioni.

Anche il GW-basic ed il Quick basic sono interpretati.

Quick basic ha un compilatore.

Il linguaggio C non ha i limiti che hanno il Pascal, i vari Basic, Python e Cobol.

Pascal non ha i limiti ed è compilato. Era usato per la didattica perchè rigoroso non perchè scarso.

Un aspetto che mi piace del C è proprio la marea di cose che può fare. Per es. driver, bootloader ed altri programmi a basso livello (o quasi) ma anche un livello un po' più alto, poi sistemi operativi, videogiochi ed è molto usato anche nel settore embedded.

C++, D, Pascal, Rust, Ada, Nim, Swift, Red, Oberon, Modula sono tutti linguaggi che hanno out of the box le stesse capacità del C. Esistono anche sistemi operativi scritti in Java, Python, C#. Solo che i linguaggi in questione vanno adattati per poter essere utilizzati come linguaggi di programmazione di sistema.


Ma io intendevo che il linguaggio che cerco non deve avere l' obbligo di inserire per forza una o più librerie per scrivere un programma.

Ma in C non hai nessun obbligo in questo senso. Se non vuoi usare librerie esterne, semplicemente devi scrivere da te tutto il codice che ti serve.

in Python per chi vuole (la cosa non è obbligatoria) può tranquillamente importare ad es. una libreria per la GUI e quindi creare un programma con la gui oppure importare "pygame" e creare un videogioco (non ai livelli di uno creato in C++).

Ma stai comunque usando una libreria di terze parti.


Anche il Dartmouth Basic e il Gw Basic non sono strutturati eppure sono linguaggi ad alto livello di cui il primo è compilato. Hanno dei meccanismi di alto livello.

Ovviamente. Ma pure l'HL Assembly è di alto livello ( relativamente all'Assembly ), ma certamente non è alto livello rispetto a Python. Il concetto di alto livello è relativo non assoluto.


Credo che anchel' assembly con l' assemblatore (es. Tasm) usa la tabulazione o/e anche l'indentazione. Giusto?

No, Assembly segue il flusso dell'istruzione, una dopo l'altra.


Non mi piace (è un' opinione/gusto personale) che ci sia un blocco di istruzioni all' interno di un altro blocco di istruzioni che poi in più introduce altre due parentesi (apri e chiudi)

Senza il grado di complessità possibile del software diminuisce. Esiste una ragione per cui si è fatto così.

Ho scoperto a malincuore che non basta eliminare tutte le parentesi graffe da tutte le librerie del C presenti all' interno del compilatore per poter scrivere in C un blocco di funzione senza le parentesi apri e chiudi.

Non ho capito. Hai modificato i sorgenti dei compilatore??? Eliminando a casaccio parentesi graffe? Cioè distruggendo completamente l'organizzazione del programmazione?


Eliminare le parentesi graffe dalle librerie del C era solo il primo passo :)

Per ottenere un software che non fa quello che dovrebbe fare. Quelle parentesi non stanno lì per ragioni estetiche.

Si vero. Ci può anche essere scritta un' altra istruzione al posto del void però nel linguaggio ma il punto è che: cerco se ci sono una o più funzioni non si devono per forza aspettare di restituire qualcosa.

Una funzione restituisce qualcosa. E' il concetto di funzione matematica, non lo si può modificare a casaccio. Alcuni linguaggi implementano le procedure come funzioni che non restituiscono nulla. Di questi alcuni impongono che venga specificato ciò ( tramite void ), altri gestiscono la cosa implicitamente ( python ).


Intendo voip come parametro, però vale anche con in t come parametro.
Poi ho visto delle volte in cui c'è il voip all' inizio della funzione e poi il void come parametro. Tutti e due nella stessa riga.

E quindi? Si sta solo dicendo che la funzione restituisce un tipo void ( cioè niente ) e che uno o più parametri di input sono di tipi void ( cioè accettano qualsiasi tipo ). Non vedo che problema sia avere void in più posto nella stessa riga. Non è cacofonia.

Io capisco che a moltissime persone questa cosa piace e lo rispetto. Se devo essere totalmente sincero a me non piace.

Ci sono dei dettagli sintattici di uno o più linguaggi che a te non piacciono ? :)

In questo caso si opta per un altro linguaggio. Fino ad oggi non ho mai usato un linguaggio che non avesse delle brutture. Ma si può benissimo convivere con queste inconsistenze. Quello che conta è che il software scritto faccia ciò che si suppone debba fare.



Un altro modo sicuramente ci sarà per dirglielo.

Certo. E infatti altri linguaggi usano altri marcatori. Ma sono questioni di pura sintassi, non capisco perchè fissarsi così tanto su banalità del genere. Con la pratica diventa naturale e gli IDE addirittura automatizzano la definizione/manipolazione dei blocchi di codice.

Nell' assembly (non mi riferisco a quello puro) non ci sono parentesi apri e chiudi oppure i marcatori per indicare dove inizia e finisce un blocco. Sarei curioso di sapere il perchè ^^

Perchè l'assembly non implementa il concetto di blocco. Un programma assembly inizia all'indirizzo XXXX e procedere linearmente, istruzione dopo istruzione, scendendo verso il basso ed eseguendo tutto quello che incontra lungo la strada.



Le istruzioni aritmetiche e quelle di controllo, uguali oppure molto simili a quelle dell' assembly sintassi Intel, nel linguaggio ad alto livello che cerco saranno a differenza dell' assembly, istruzioni ad alto livello. Saranno quindi astratte e non avranno niente a che fare con i registri e con i bit.

Cioè ADD xx, yy invece di xx+yy? Sicuro che ti convenga? Non per dire ma quello che stai dicendo è implementato dai vari intermediate languages dei compilatori e delle macchine virtuali ( vedi LLVM, o l'IL di .NET ).


Riguardo al discorso della variabili in assembly. Con un assemblatore, es. Tasm si dichiarano le variabili all' interno .DATA e all' interno di STARTUP si fanno le varie operazioni con le variabili ed i registri. Non si possono fare le operazioni tra 2 variabili se una delle 2 non si trova in un registro.

Ma non sono variabili, sono locazioni di memoria riservate per metterci dentro qualcosa. Il qualcosa è noto solo al programma e non all'assemblatore. In una locazione riservata con dw ci puoi mettere un numero a 16 bit con segno, uno senza segno, 2 caratteri ASCII o un carattere Unicode UTF-16. Ma l'assemblatore non lo sa, il compilatore invece ti chiedo di specificare che cosa c'andrà messo in quei 16 bit di memoria.

Nel Pascal, che è un linguaggio ad alto livello, c'è il compilato e ad es. le variabili non hanno nulla a che fare con i registri ed i bit. Ad es. non bisogna affatto preoccuparsi di dichiarare la dimensione in bit di una o più variabili cosa che invece va fatta in assembly con un assemblatore.

Si e no. La corrispondenza tra sorgente ed eseguibile non c'è, altrimenti verrebbe meno lo scopo principale del linguaggio stesso. Ma sulla dimensione c'è, infatti Pascal supporta i tipi di dati integer ( 32 bit ), shortint ( 8 bit ), smallint ( 16 bit ), ecc... Quindi la quantità di memoria riservata dipende dal tipo della variabile specificato nel codice sorgente.


Mi sono reso conto ora che avrei doluto aggiungere un altro frase per spiegare quello che intendevo dire. Purtroppo hai interpretato diversamente però ora ti spiego.


A) nell' assembly sono una corrispondenza 1:1 del codice esadecimale e del codice binario. Sono istruzioni a basso livello e non c'è di mezzo il compilatore oppure l' interprete. Non c'è astrazione. Hanno a che fare con i byte ed i registri. (se mi sono dimenticato altro aggiungilo pure^^).

Eh magari. In realtà nei processori moderni quelle istruzioni sono nomi di procedure ( contenute nel microcodice ). Il vero linguaggio macchina è un altro ed è noto solo al produttore del processore. Ma comunque questo è un altro discorso.

B) nei linguaggi ad alto livello come ad es. il C, il Pascal e Gw Basic e Quick Basic la situazione è opposta rispetto al punto 1, visto che le "abbreviazione mnemoniche" (è meglio forse mettere il tutto tra virgoletta perchè probabilmente il termine non è corretto a livello informatico per quanto riguarda gli HLL) sono abbreaviazione di una o più istruzioni astratte e quindi ad alto livello, non hanno a che fare con i byte ed i registri, non c'è corrispondenza 1:1 etc... e c'è un compilatore che converte il codice in assembly e poi in codice macchina (con il compilatore) oppure prima in codice pseudo-assembly e poi in codice macchina tramite un interprete.

Ovvio. Lo scopo di un linguaggio di programmazione ad alto livello è offrire un modello di programmazione ( una specie di macchina virtuale ) che sia più facile da usare per l'uomo e sia sufficientemente astratta da poter rendere i programmi scritti per essa portabili su diverse architetture di processori/calcolatori elettronici. Un ARMv7 non ha il set di registri di un x86, per cui se esponi i registri x86 e li rendi manipolabili direttamente, rendi il tuo linguaggio non utilizzabile su macchine ARM. Quindi a che serve un simile linguaggio?



No quelle sono un'altra cosa. Sono delle funzioni di utilità fornite dalla libreria standard del linguaggio per semplificare la vita ai programmatori. Puoi benissimo scriverti a manina tutte le funzioni per manipolare le stringhe invece di usare string.h. Poi però impiegherai 20 volte il tempo che avresti impiegato per scrivere il tuo programma.

Ma quelle funzioni non hanno nulla a che vedere col processore o col modello di programmazione del linguaggio. Il software che usiamo non è che riscrive da zero tutto, ma sfrutta pile di codice già scritto da altri per implementare funzionalità comuni.

Es. nell' assembly c'è CMP però ci può essere in linguaggio ad alto livello CMP ma che a differenza nell' assembly sia un abbreviazione "mnemonica" astratta ad alto livello che non abbia a che fare con i bit ed i registri ma che fa la comparazione tra due variabili che non hanno a che fare con i registri ed i bit.

CMP significa COMPARE, in C è ==

Non capisco perchè CMP sarebbe più semplice di ==

Ad es. il cobol, l' Algol ed il Fortran non sono general purpose.

Ma sono Turing completi. Comunque Algol è anche general purpose ( se ho capito cosa intendi ), tant'è che ci sono sistemi operativi scritti in Algol.



In assembly a differenza degli altri linguaggi non c'è la distinzione tra procedure e funzioni.

No, non ci sono proprio nè procedure nè funzioni.



Infatti non ho mai pensato o detto che un linguaggio sia in assoluto migliore degli altri. Io penso e credo che ogni linguaggio hai i suoi pro ed i suoi contro.

Invece con ad es. Tasm quando si scrive un programma ci sono anche le istruzioni che non hanno parte dell' assembly puro ma appartengono all' assemblatore. In questo caso il linguaggio è sempre non strutturato?

Quelle non sono istruzioni ma direttive per l'assemblatore. Servono perchè la piattaforma su cui il programma girerà ha determinate caratteristiche. Ad esempio un bootloader x86 ha l'entry point posto all'indirizzo 7C00, per cui tutte le istruzioni vanno codificate in modo da tenerne conto. Se non specifichi questo fatto, l'assemblatore non lo saprà e alcune istruzioni salteranno in posti sbagliati o prenderanno/memorizzeranno i dati da locazioni sbagliate.

Ad es. con il Pascal e l' Ada noto che i programmi possono essere o un po' strutturati oppure più strutturati. Nel secondo caso c'è un blocco di istruzioni all' interno di un altro blocco di istruzioni. Nell' assembly con ad es. Tasm (non assembly puro) non c'è un blocco di istruzioni all' interno di un altro blocco di istruzioni.

Ogni linguaggio ad alto livello fornisce astrazioni ma non si è obbligati ad usarle tutte. Pure in C puoi evitare di innestare blocchi, poi però la vita ti si complica.

In Assembly il problema non esiste perchè non esiste proprio il concetto di blocco. Esistono istruzioni, uno dietro l'altra che il processore esegue pedissequamente.


Nei linguaggii imperativi ci sono anche i comandi giusto?

Si.

Ho visto che il modello di programmazione è diverso in Smalltalk però come si chiama questo modello? E' dichiarativo?

No. Smalltalk è principalmente un linguaggio orientato agli oggetti.

Ho visto il modello di memoria nei diversi linguaggi che ci sono nel link che hai postato. Peccato che l' argomento è complesso per me :(

Quelle informazioni servono per capire qual è la differenza qualitativa tra linguaggi di alto livello e linguaggio Assembly.
 
@pabloski complimenti.. stai riuscendo a mantenere la logica da ormai parecchi post, tempo fa mi ero imbattuto in quelle questioni pseudo-filosofiche di "chiba", ma non ne ho mai capito il senso!

Inviato dal mio Nexus 5 utilizzando Tapatalk
 
@pabloski complimenti.. stai riuscendo a mantenere la logica da ormai parecchi post, tempo fa mi ero imbattuto in quelle questioni pseudo-filosofiche di "chiba", ma non ne ho mai capito il senso!

Beh sembra che voglia imparare. Il suo problema è che sta affrontando la programmazione in maniera troppo filosofica, segno di chi si pone troppi dubbi, troppo presto e senza motivo.

Da neofita non si rende conto che tutti i suoi grattacapi sono puramente estetici, perchè tanto una mente allenata ad utilizzare un certo linguaggio, lo userà e lo troverà produttivo aldilà di mancanze oggettive.

L'errore in cui ricade questo tipo di "studente" è leggere tantissimo ma applicarsi pochissimo. Avrai notato con quale rigidità affronta il tema dei compilatori, quasi come se fosse una proprietà magica esclusiva di alcuni linguaggi. Non avendo fatto pratica, gli sembra magico e non realizza che qualsiasi linguaggio può essere compilato, questo perchè tutto l'ambaradan del computing è solo una cascata di trasformazioni suo dati.

Sono cose su cui pure io avevo dubbi quando iniziai, dubbi svaniti man mano che mettevo le mani ( tanta pratica ) nei vari argomenti.
 
Beh sembra che voglia imparare. Il suo problema è che sta affrontando la programmazione in maniera troppo filosofica, segno di chi si pone troppi dubbi, troppo presto e senza motivo.

Da neofita non si rende conto che tutti i suoi grattacapi sono puramente estetici, perchè tanto una mente allenata ad utilizzare un certo linguaggio, lo userà e lo troverà produttivo aldilà di mancanze oggettive.

L'errore in cui ricade questo tipo di "studente" è leggere tantissimo ma applicarsi pochissimo. Avrai notato con quale rigidità affronta il tema dei compilatori, quasi come se fosse una proprietà magica esclusiva di alcuni linguaggi. Non avendo fatto pratica, gli sembra magico e non realizza che qualsiasi linguaggio può essere compilato, questo perchè tutto l'ambaradan del computing è solo una cascata di trasformazioni suo dati.

Sono cose su cui pure io avevo dubbi quando iniziai, dubbi svaniti man mano che mettevo le mani ( tanta pratica ) nei vari argomenti.
Mi piace il tuo buon senso e come riesci a interpretarlo. In passato ho avuto un paio di discussioni ma poi ho sempre perso la pazienza!

Il problema secondo me è che, è vero che studia e si documenta, ma poi parte per la tangente e si inerpica su sue interpretazioni e teorie scombussolate che non hanno fondamento e senso logico.

Mi riferisco per esempio a forzare l'analogia tra linguaggio di programmazione e linguaggio umano come se dovessero coincidere. E poi tutti questi riferimenti a linguaggi del passato come se fossero dei riferimenti imprescindibili (mi riferisco a quando parla di GWBasic o dorthmount basic .. se conoscesse tutte le varianti e dialetti di ogni linguaggio diventerebbe un ragionamento allucinante).. oppure quando dice di un linguaggio su misura che sia bello.da vedere e perciò senza delimitatori e parentesi graffe!?! .. per me sono considerazioni incomprensibili, forse di chi vuole sfoggiare conoscenza e terminologie saccenti?

Inviato dal mio Nexus 5 utilizzando Tapatalk
 
Mi piace il tuo buon senso e come riesci a interpretarlo. In passato ho avuto un paio di discussioni ma poi ho sempre perso la pazienza!

Il problema secondo me è che, è vero che studia e si documenta, ma poi parte per la tangente e si inerpica su sue interpretazioni e teorie scombussolate che non hanno fondamento e senso logico.

Mi riferisco per esempio a forzare l'analogia tra linguaggio di programmazione e linguaggio umano come se dovessero coincidere. E poi tutti questi riferimenti a linguaggi del passato come se fossero dei riferimenti imprescindibili (mi riferisco a quando parla di GWBasic o dorthmount basic .. se conoscesse tutte le varianti e dialetti di ogni linguaggio diventerebbe un ragionamento allucinante).. oppure quando dice di un linguaggio su misura che sia bello.da vedere e perciò senza delimitatori e parentesi graffe!?! .. per me sono considerazioni incomprensibili, forse di chi vuole sfoggiare conoscenza e terminologie saccenti?

Inviato dal mio Nexus 5 utilizzando Tapatalk

Beh in effetti c'è un pelino di comportamento ossessivo-compulsivo. La necessità di valutare tutte le possibili varianti di tutti i possibili linguaggi è quanto meno futile. Alla fin fine i linguaggi da usare li stabilisce il mercato. Ci si può specializzare, ma non si può imporre al mercato di usare Nim, quando il mercato non ha interesse. E ovviamente se non segui il mercato, non guadagni e non mangi.

Nell'ultimo post ha scritto che il suo target è l'elettronica ( suppongo embedded ), per cui c'è poco dare. C è il re. C++ la regina. Le briciole per gli altri. Il mercato appunto...
 
Io non impongo al mercato di usare un determinato linguaggio o/e una determinata architettura. Per me il mercato o/e le aziende o/e startup etc... sono libere di scegliere in che direzione vogliono andare e quindi che cosa usare.

Per me ogni persona ha la libertà di scegliere se seguire o non seguire il mercato, se scegliere o/e evitare un determinato settore o/e indirizzo piuttosto che un altro etc...

Questo discorso si riferisce sia per chi ha uno o più hobby, sia per chi lavora o/e vuole entrare nel mondo del lavoro e sia per chi è un consumatore.
Ogni scelta ha i suoi pro ed i suoi contro.

Il settore embedded è vastissimo (per quanto riguarda i componenti da programmare). Per quelli che necessitano di un linguaggio di programmazione: si utilizza maggiormente l' assembly ed il C. Poi si utilizzano anche il Pascal. il Basic, l' Ada ed il C++ (non li ho scritti in ordine).


Vorrei a precisare che questa discussione che ho creato non c' entra nulla con il mondo del lavoro.

Quando in uno dei post sopra ho nominato l' elettronica non mi riferivo al settore embebbed oppure all' Iot ma ad es. all' elettronica analogica e alle architetture Intel: Pre X86 ed X86.

L' architettura Pre X86, quella X86, il relativo assembly sintassi Intel, l' elettronica (mi riferisco alla frase) sono un hobby, un passatempo etc.. e stessa cosa vale per la scelta di questo linguaggio di programmazione adatto a me. I discorsi su quale linguaggio o/e quale piattaforma vanno di più oppure vanno di meno oppure sono di nicchia etc.. non riguardano questa discussione.

Non ho mai detto di volere un linguaggio che sia addirittura bello da vedere. Per me un linguaggio è come il contenuto di un libro oppure la vetrina all' interno di una pasticceria + i dolci (all' interno della vetrina).

Sto cercando un linguaggio che sia più vicino al mio modo di pensare/ragionare, alle mie esigenze ed ai miei interessi/gusti personali.
Mi interessa la programmazione, imperativa, modulare ed un po' strutturata. Dico "un po'" perchè non deve avere un sub program all' interno di un altro sub program.

Esistono tantissimi linguaggi di programmazione perchè chi li ha creati aveva dei motivi ben precisi. Ancora oggi c'è chi crea un linguaggio di programmazione perchè ha dei motivi per farlo.

Ma io non studio visto che non mi piace proprio. Io semplicemente leggo e mi documento su internet tra: siti web, dispense online, forum, youtube e libri online. Questo vale per diverse cose visto che sono una persona che ha svariati interessi.
Preferisco la pratica alla teoria e non mi riferisco solo all' informatica e all' elettronica. Non sto dicendo che bisogna escludere la teoria.

Io non sono per nulla una persona pragmatica. Non ragiono a macchinetta, non sono un calcolatore, non vedo il mondo in bianco e nero, non ragiono come un matematico o un programmatore etc...

Io invece sono un sognatore, una persona curiosa, sono come minimo un po' creativo, ho una personalità, vedo il mondo o in scala di grigi oppure a colori, sono un essere umano (non una macchina) che prova delle emozioni o/e sentimenti. Se una cosa mi piace o/e mi interessa non guardo quando è stata inventata, creata o quando è uscita.

Ogni persona è diversa. Non siamo tutti uguali. Ognuno ha una carattere ed una personalità diversa.

Su molte cose sono ignorante, mi manca anche la conoscenza di vari termini tecnici. Ci sono cose dell' assembly che per me sembrano astratte quindi figuriamoci i linguaggi ad alto livello o addirittura quelli di altissimo livello. Questo perchè non conosco determinate cose e quindi vedo i diversi linguaggi, l' assemblatore, il compilatore e l' interprete come un diagramma di flusso.

Non mi piace accontentarmi che il tutto funzioni per magia. Ecco uno dei motivo perchè mi sto addentrando sempre di più nel basso livello.

Tipo 2 settimane fa ho scoperto che ad se un linguaggio interpretato (che ha l' interprete) ha anche un compilatore e lo si usa al posto dell' interprete il linguaggio sarà compilatore. Stessa cosa vale all' inverso.

Ogni volta prima di rispondere a questa discussione ho avuto difficoltà a parlare dei vari argomenti e a tentare di spiegarmi al meglio. Ho dovuto fare un sacco di ricerche su internet che poi hanno portato ad altre ricerche e ad altre ricerche ancora.

Questo, ogni volta, da una parte ha portato a conoscere delle cose, a non capire altre cose ma ha portato a confusione e parecchio stress. Anche per fare i riferimenti ai diversi linguaggio mi sono dovuto documentare visto le lacune che ho.

Tutto questo l' ho fatto principalmente per riuscire a farmi capire, per spiegare quello che ho in mente, per spiegare quello che sto cercando e le caratteristiche che deve avere il linguaggio che cerco. Però mi sono accorto che su diverse cose avete frainteso e da una parte mi rendo acconto che forse sarebbe stato meglio aprire la discussione in seguito quando il mio livello sarebbe stato più alto.

il punto 3 no, perchè pascal consente di fare qualsiasi cosa, alla pari dell'assembly
il punto 4 nemmeno, dato che il concetto di libreria non è relativo al linguaggio...esistono programmi c, pascal, rust che non richiamano nessuna libreria...voglio anche precisare che il preprocessore non c'entra niente con le librerie
il punto 12 nemmeno, perchè tutti i linguaggi che hai citato sono general purpose

Su quello che hai scritto, relativo al punto 3, non sono d' accordo. Poi il Pascal non è nemmeno alla pari del C.

Ho fatto ulteriori ricerche e Kernighan (uno dei creatori del C) aveva scritto un paper "Why Pascal Is Not My Favorite Programming Language ".

https://www.lysator.liu.se/c/bwk-on-pascal.html


Ad es. dall' Ansi C in poi ogni libro, dispensa. sito web, video etc.. dicono che bisogna mettere una o più librerie per dei motivi. Stessa cosa vale anche per il C++. La cosa non è facoltativa.

Riguardo al punto 12 mi sono informato ed ho usato il termine sbagliato. Mi riferivo all'" application domain".


Certamente. E infatti esistono vari paradigmi di programmazione. Ma le tipologie esistenti non soddisfanno appieno nessuno, questo perchè in ingegneria non esiste la perfezione ma solo i trade-off.

Anche io penso che non esista un linguaggio o/e un padigma di programmazione perfetto e che quindi riesca a soddisarei appieno qualcuno.

Se vuoi un linguaggio veramente diverso e simil-assembly in quanto ad assenza di sintassi, prova LISP.

Non mi riferivo all' assembly puro.
Ho rivisto e riletto un pochino ed il Lisp e la programmazione funzionale non fanno per me e non quello che sto cercando.

Ho dato uno sguardo ad una delle ultime tue discussioni sull' altro forum dove hai menzionato diversi linguaggi come ad es. Go.

E non ti servirà a molto, perchè in ambito elettronico/embedded/iot l'architettura x86 praticamente non esiste. E' tutto dominato da ARM e AVR.
Esistono board che supportano Python, ma in generale il linguaggio che chiedi è il C.

I pc, i server e le workstation non fanno parte del settore embedded ed ovviamente nenemmeno di quello Iot.

Non è vero che nell' ambito elettronico l' archettura x86 praticamente non esiste.
Poi non è vero che è tutto dominato da Arm e Avr.

Altre cose le ho scritte sopra.
Per il resto non mi voglio dilungare perchè l' Arm, l' embedded e l' Iot non riguardano questo topic.

Molti concetti li hanno copiati da LISP. Tutta la programmazione funzionale che tanto fa figop di questi tempi è scopiazzata da LISP. Assembly è l'unico che non ha nulla di LISP, dato che non implementa astrazioni.

Forse sarà una moda del momento. Io, in generale, cerco di ragionare con la mia testa.

C'è un linguaggio imperativo, che implementa astrazioni che non ha le funzioni?

Quick basic ha un compilatore.
Pascal non ha i limiti ed è compilato. Era usato per la didattica perchè rigoroso non perchè scarso.

Ti riferisci a Qbasic? Se no mi piacere conoscere come si chiama il compilatore.

Io ho sempre saputo che fosse un linguaggio interpretato e che quindi Qbasic fosse l' interprete.

Infatti Pascal è compilato. Si è rigoroso (infatti era uno dei motivi per cui era usato nella didattica) però mica intendevo che era scarso.

C++, D, Pascal, Rust, Ada, Nim, Swift, Red, Oberon, Modula sono tutti linguaggi che hanno out of the box le stesse capacità del C. Esistono anche sistemi operativi scritti in Java, Python, C#. Solo che i linguaggi in questione vanno adattati per poter essere utilizzati come linguaggi di programmazione di sistema.

Che intendi con out of the box? Non mi riferisco alla traduzione.

Ogni linguaggio ha i suoi pro ed i suoi contro e non sono uguali.

Non so se questa tabella sia aggiornata, che ne pensi ?

https://en.wikipedia.org/wiki/System_programming_language

Ma in C non hai nessun obbligo in questo senso. Se non vuoi usare librerie esterne, semplicemente devi scrivere da te tutto il codice che ti serve.

Questa cosa non la sapevo. Non l' ho mai letta da nessuna parte.

Ma stai comunque usando una libreria di terze parti.

Ho fatto l' es. per far capire che non c'è nessun obbligo di usare anche una sola libreria per le cose principali.

Ovviamente. Ma pure l'HL Assembly è di alto livello ( relativamente all'Assembly ), ma certamente non è alto livello rispetto a Python. Il concetto di alto livello è relativo non assoluto.

Forse l' HL assembly (so che non è a basso livello) è il linguaggio che sto cercando.

Anche io penso che il concetto di alto livello è relativo mica è assoluto.

Senza il grado di complessità possibile del software diminuisce. Esiste una ragione per cui si è fatto così.

La prima frase non l' ho capita.

Sono d' accordo con la seconda frase.

Anche per i linguaggi non-strutturati c'è una ragione per cui sono stati inventati/scritti in un determinato modo rispetto a quelli strutturati.

Non ho capito. Hai modificato i sorgenti dei compilatore??? Eliminando a casaccio parentesi graffe? Cioè distruggendo completamente l'organizzazione del programmazione?

Non ho modificato i sorgenti dei compilatori. Non so nemmeno come si fa.
Io non faccio modifiche a casaccio.

[/QUOTE]

Per ottenere un software che non fa quello che dovrebbe fare. Quelle parentesi non stanno lì per ragioni estetiche.

Hai frainteso quello che ho scritto.

Per me, la sintassi di ogni linguaggio non è solo qualcosa di estetico ma ha una sua logica che è stata decisa da chi ha creato il linguaggio o/e chi lo ha standardizzato.

La mia idea era ed è quella di modificare un pochino la sintassi o/e anche la semantica del C in maniera tale da poter scrivere un programma, con una sintassi un pochino diversa rispetto al C, che poi si possa compilare e che possa funzionare.

Nella mia ignoranza credevo che bastasse modificare (non a casaccio) solamente le librerie.h relative al C (il compilatore che ho ha anche le librerie relative al C++) per poter, poi, riuscire a scrivere un programma che una volta compilato potesse funzionare.

Facendo poi delle ricerche ho invece imperato e capisco che bisogna modificare (non intendo a casaccio) i sorgenti del compilatore oltre alle librerie perchè altrimenti il programma scritto in un linguaggio un pochino diverso rispetto al C, non verrà mai compilato dal compilatore.

Se mi puoi, gentilmente, spiegare oppure indicare sul web (un sito web, una dispensa etc..) come modificare (non a casaccio) i sorgenti del compilatore C mi farebbe piacere perchè mi interessa :)

Io ho installato TDM-GCC su Windows 7 a 64 bit.

Una funzione restituisce qualcosa. E' il concetto di funzione matematica, non lo si può modificare a casaccio. Alcuni linguaggi implementano le procedure come funzioni che non restituiscono nulla. Di questi alcuni impongono che venga specificato ciò ( tramite void ), altri gestiscono la cosa implicitamente ( python ).

Io non voglio modificare a casaccio il concetto di funzione.
Non mi ricordavo il concetto di funzione.

E quindi? Si sta solo dicendo che la funzione restituisce un tipo void ( cioè niente ) e che uno o più parametri di input sono di tipi void ( cioè accettano qualsiasi tipo ). Non vedo che problema sia avere void in più posto nella stessa riga. Non è cacofonia.

Ho capito ora che cosa fanno i due void nella stessa riga.

Ci sono come minimo diversi linguaggi che non c'è l' hanno perchè i creatori di questi linguaggi hanno avuto una o più ragioni per fare così. Stessa cosa vale ad es per i 2 creatori del C. E' questione di scelte e punti di vista.

In questo caso si opta per un altro linguaggio. Fino ad oggi non ho mai usato un linguaggio che non avesse delle brutture. Ma si può benissimo convivere con queste inconsistenze. Quello che conta è che il software scritto faccia ciò che si suppone debba fare.

Infatti ho deciso che o opto per un altro linguaggio oppure modifico (non a casaccio) un pochino uno dei seguenti linguaggi: C, il Pascal, Cobol e Quick Basic + il relativo compilatore.

Riguardo alla terza frase che hai detto dipende da persona a persona. Per me, se ad es. un linguaggio non mi attira, non mi piace per nulla (non mi riferisco Solo all' estetica), non mi convince, non mi ci trovo o/e ha una o più cose non hanno senso allora ci provo a dargli un occhiata diverse volte, mi posso anche mettere diverse volte ad iniziare a leggere una dispensa, un libro o una pagina web ma poi dopo o lo mollo oppure va a finire che mi distraggo diverse volte e poi dopo lo mollo. Ed il ciclo si ripete.

Per me conta Anche che il software scritto faccia ciò che si suppone debba fare perchè non viene al primissimo posto.

Se invece contasse solo che il software faccia ciò che si suppone debba fare allora io preferisco mollare il software ed relativo linguaggio (sono serio). Però capisco che ci sono invece delle persone che la pensano diversamente da me.

Certo. E infatti altri linguaggi usano altri marcatori. Ma sono questioni di pura sintassi, non capisco perchè fissarsi così tanto su banalità del genere. Con la pratica diventa naturale e gli IDE addirittura automatizzano la definizione/manipolazione dei blocchi di codice.

Ognuno sceglie i marcatori che vuole quando crea un proprio linguaggio di programmazione. Questo vale anche per i linguaggi degli anni passati.

Ma io non mi ci fisso tanto su queste cose che tra l' altro, per me non sono così banali. La sintassi non è Solo estetica.

Io stavo spiegando le caratteristiche che deve avere il linguaggio che sto cercando, stavo rispondendo a delle domande che mi avevi fatto e stavo spiegando il perchè evito determinati linguaggio e perchè determinati linguaggi li ho mollati in passato o addirittura più di una volta. Tutto qui :)

Io ad es. utilizzo notepad2 e mi trovo bene ^^

Cioè ADD xx, yy invece di xx+yy? Sicuro che ti convenga? Non per dire ma quello che stai dicendo è implementato dai vari intermediate languages dei compilatori e delle macchine virtuali ( vedi LLVM, o l'IL di .NET )

Si. Oppure ADD xx, yy ;
Per la seconda domanda: penso di si.

Non uso LLVM oppure quei linguaggi che usano .NET framework oppure quei linguaggi che usano la JVM.

Per il C ho scaricato TDM-GCC (contiene MinGW) mentre in passato solo MinGW altrimenti potrai anche usare un compilatore scritto in C (non in C++).

Se vado sul Pascal pensavo a Turbo Pascal. Poi non so se c'è un compilatore più fedele alla sintassi originaria.

Se vado sul Quick Basic allora Qbasic.

Per quanto riguarda Cobol non lo so. Mi devo informare.

Ma non sono variabili, sono locazioni di memoria riservate per metterci dentro qualcosa. Il qualcosa è noto solo al programma e non all'assemblatore. In una locazione riservata con dw ci puoi mettere un numero a 16 bit con segno, uno senza segno, 2 caratteri ASCII o un carattere Unicode UTF-16. Ma l'assemblatore non lo sa, il compilatore invece ti chiedo di specificare che cosa c'andrà messo in quei 16 bit di memoria.

Perchè il qualcosa è noto solo al programma? Lo chiedo perchè voglio imparare e perchè sono curioso.

Si e no. La corrispondenza tra sorgente ed eseguibile non c'è, altrimenti verrebbe meno lo scopo principale del linguaggio stesso. Ma sulla dimensione c'è, infatti Pascal supporta i tipi di dati integer ( 32 bit ), shortint ( 8 bit ), smallint ( 16 bit ), ecc... Quindi la quantità di memoria riservata dipende dal tipo della variabile specificato nel codice sorgente.

Io so che il sorgente attraverso il compilatore viene tradotto in linguaggio macchina oppure prima in assembly e poi in linguaggio macchina. Nell' eseguibile c'è il codice macchina. Non so è se giusto.

Questa cosa su Pascal non la sapevo.

1) Perchè questo qualcosa è noto solo al programma e non all' assemblatore? Ho capito che è stato deciso così ma per curiosità: perchè?

Sia sull' Assembly che sul Pascal ci sono istruzioni apposite che servono per indicare la dimensione dei dati giusto? in Asm si chiamano pseudo-op.

2) In Pascal le istruzioni relative ai tipo di dati (quelle che hai menzionato) sono astratte? Se si perchè? Sono curioso e voglio impare.

Eh magari. In realtà nei processori moderni quelle istruzioni sono nomi di procedure ( contenute nel microcodice ). Il vero linguaggio macchina è un altro ed è noto solo al produttore del processore. Ma comunque questo è un altro discorso.

E' un altro discorso, che però è interessante, per un' altra discussione da aprire ^^

Mi è capito pure un video su youtube che voglio vedere sulla segretezza del linguaggio macchina (o forse l' assembly) delle cpu Intel moderne.

Se sei interessato te lo linko volentieri.

Ovvio. Lo scopo di un linguaggio di programmazione ad alto livello è offrire un modello di programmazione ( una specie di macchina virtuale ) che sia più facile da usare per l'uomo e sia sufficientemente astratta da poter rendere i programmi scritti per essa portabili su diverse architetture di processori/calcolatori elettronici. Un ARMv7 non ha il set di registri di un x86, per cui se esponi i registri x86 e li rendi manipolabili direttamente, rendi il tuo linguaggio non utilizzabile su macchine ARM. Quindi a che serve un simile linguaggio?

Non ho capito la parte dopo la virgola e quindi anche la domanda finale.

No quelle sono un'altra cosa. Sono delle funzioni di utilità fornite dalla libreria standard del linguaggio per semplificare la vita ai programmatori. Puoi benissimo scriverti a manina tutte le funzioni per manipolare le stringhe invece di usare string.h. Poi però impiegherai 20 volte il tempo che avresti impiegato per scrivere il tuo programma.


Infatti e' più comodo includere una libreria piuttosto che scrivere tutto il codice e si risparmia anche tempo. Su questo non ci piove.

C'è da dire che a seconda del programma che bisogna scrivere non credo che servano tutte le righe ci codice contenuto nella libreria.

Es. per il Pascal le librerie sono compilate mentre quelle che si possono inserire (è falcoltativa la cosa) sono poche Anche un argomento che mi suscita interesse.

In Cobol come minimo svariate cose si possono fare senza includere le librerie e senza scrivere il codice delle librerie all' interno del programma.

C'è più libertà da questo punto di vista. Capisco che la cosa è soggettiva.

Ma quelle funzioni non hanno nulla a che vedere col processore o col modello di programmazione del linguaggio. Il software che usiamo non è che riscrive da zero tutto, ma sfrutta pile di codice già scritto da altri per implementare funzionalità comuni.

Vorrei saperne di più^^
Nella Bibbia del C trovo qualcosa?

Ho anche il pdf di Fabio Manganiello sul Linguaggio C.

Dove si trovano queste pile ci codice già scritto da altri?

CMP significa COMPARE, in C è ==

Non capisco perchè CMP sarebbe più semplice di ==


CMP in Asm non corrisponde a == in C. In C è If.

Non ho detto che CMP sarebbe più semplice di == .

Quelle non sono istruzioni ma direttive per l'assemblatore. Servono perchè la piattaforma su cui il programma girerà ha determinate caratteristiche. Ad esempio un bootloader x86 ha l'entry point posto all'indirizzo 7C00, per cui tutte le istruzioni vanno codificate in modo da tenerne conto. Se non specifichi questo fatto, l'assemblatore non lo saprà e alcune istruzioni salteranno in posti sbagliati o prenderanno/memorizzeranno i dati da locazioni sbagliate.

L' ultima frase che hai scritto se avviene su un vecchio O.S, che permette l' accesso diretto all' hardware, danneggia la cpu o c'è il rischio che si possa daneggieggiare?

Questo programma è strutturato e modulare, giusto? :

ASP.net:
Print "An example of a GOTO statement"
Sleep 1000
Goto program_continue
Print "This line of code will never be executed"
       program_continue:
Print "We just skipped some code"
Sleep
End


Questo con il linguaggio Ada:

with Ada.Text_IO; use Ada.Text_IO; procedure Hello is begin Put_Line ("Hello, world!"); end Hello;

Non c'è un sottoprogramma all' interno di un altro sottoprogramma.
Altri programma in ada hanno anche il sottoprogramma all' interno di un altro sottoprogramma e credo che programma sia sempre strutturato e modulare, se non ho capito male.

Ogni linguaggio ad alto livello fornisce astrazioni ma non si è obbligati ad usarle tutte. Pure in C puoi evitare di innestare blocchi, poi però la vita ti si complica.

Questo non lo sapevo.
Mi puoi far vedere un es. di un programma in C senza innestare blocchi?


In Assembly il problema non esiste perchè non esiste proprio il concetto di blocco. Esistono istruzioni, uno dietro l'altra che il processore esegue pedissequamente.


Mi viene da dire blocco di istruzioni perchè non ho un altro termine per descriverlo.

Codice:
SEG_UNICO segment ;    definizione    dell’unico    segmento    del    programma

assume    CS:SEG_UNICO ;    assegnazione    di    tutti    i    registri    di    segmento    all’unico    segmento
assume    DS:SEG_UNICO
assume    ES:SEG_UNICO
assume    SS:SEG_UNICO

START: ;    AREA    CODICE
          mov    ax,    4c00h ;    unica    istruzione    del    programma:    terminazione    programma    EXE
          int    21h
ends
end START

Questo qui per me è strutturato e modulare visto che non tutte le righe hanno la stessa tabulazione ed più mov ax etc.. ed Int 21H si trovano all' interno di START:; etc... di ends

Se fosse stato un programma non-strutturato ogni riga di istruzione avrebbe avuto la stessa tabulazione e non ci sarebbe nessun sottoprogramma (o come si chiama).

Quelle informazioni servono per capire qual è la differenza qualitativa tra linguaggi di alto livello e linguaggio Assembly.

Che intendi di preciso con differenza qualitativa?
 
Per me ogni persona ha la libertà di scegliere se seguire o non seguire il mercato, se scegliere o/e evitare un determinato settore o/e indirizzo piuttosto che un altro etc...

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.

Il settore embedded è vastissimo (per quanto riguarda i componenti da programmare). Per quelli che necessitano di un linguaggio di programmazione: si utilizza maggiormente l' assembly ed il C. Poi si utilizzano anche il Pascal. il Basic, l' Ada ed il C++ (non li ho scritti in ordine).

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.

Quando in uno dei post sopra ho nominato l' elettronica non mi riferivo al settore embebbed oppure all' Iot ma ad es. all' elettronica analogica e alle architetture Intel: Pre X86 ed X86.

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


Sto cercando un linguaggio che sia più vicino al mio modo di pensare/ragionare, alle mie esigenze ed ai miei interessi/gusti personali.

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

Mi interessa la programmazione, imperativa, modulare ed un po' strutturata. Dico "un po'" perchè non deve avere un sub program all' interno di un altro sub program.

Non usare le funzionalità che non ti piacciono.

Non ragiono a macchinetta, non sono un calcolatore, non vedo il mondo in bianco e nero, non ragiono come un matematico o un programmatore etc...

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.

Tipo 2 settimane fa ho scoperto che ad se un linguaggio interpretato (che ha l' interprete) ha anche un compilatore e lo si usa al posto dell' interprete il linguaggio sarà compilatore. Stessa cosa vale all' inverso.

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

Anche per fare i riferimenti ai diversi linguaggio mi sono dovuto documentare visto le lacune che ho.

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


Su quello che hai scritto, relativo al punto 3, non sono d' accordo. Poi il Pascal non è nemmeno alla pari del C.

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.

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

Ho fatto ulteriori ricerche e Kernighan (uno dei creatori del C) aveva scritto un paper "Why Pascal Is Not My Favorite Programming Language ".

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

Ad es. dall' Ansi C in poi ogni libro, dispensa. sito web, video etc.. dicono che bisogna mettere una o più librerie per dei motivi.

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.

Non è vero che nell' ambito elettronico l' archettura x86 praticamente non esiste.
Poi non è vero che è tutto dominato da Arm e Avr.

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.



Forse sarà una moda del momento. Io, in generale, cerco di ragionare con la mia testa.

No, è un trend che ha preso piede da alcuni anni, tant'è che tutti i linguaggi più diffusi stanno implementando o hanno già implementato elementi di programmazione funzionale.

C'è un linguaggio imperativo, che implementa astrazioni che non ha le funzioni?

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

Ti riferisci a Qbasic? Se no mi piacere conoscere come si chiama il compilatore.

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

Che intendi con out of the box? Non mi riferisco alla traduzione.

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

Non so se questa tabella sia aggiornata, che ne pensi ?

https://en.wikipedia.org/wiki/System_programming_language

Non dice niente.

Non ho modificato i sorgenti dei compilatori. Non so nemmeno come si fa.
Io non faccio modifiche a casaccio.

Non mi è chiaro cos'hai fatto allora.

La mia idea era ed è quella di modificare un pochino la sintassi o/e anche la semantica del C in maniera tale da poter scrivere un programma, con una sintassi un pochino diversa rispetto al C, che poi si possa compilare e che possa funzionare.

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.

Nella mia ignoranza credevo che bastasse modificare (non a casaccio) solamente le librerie.h relative al C (il compilatore che ho ha anche le librerie relative al C++) per poter, poi, riuscire a scrivere un programma che una volta compilato potesse funzionare.

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.

Facendo poi delle ricerche ho invece imperato e capisco che bisogna modificare (non intendo a casaccio) i sorgenti del compilatore oltre alle librerie perchè altrimenti il programma scritto in un linguaggio un pochino diverso rispetto al C, non verrà mai compilato dal compilatore.

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.

Se mi puoi, gentilmente, spiegare oppure indicare sul web (un sito web, una dispensa etc..) come modificare (non a casaccio) i sorgenti del compilatore C mi farebbe piacere perchè mi interessa :)

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

Riguardo alla terza frase che hai detto dipende da persona a persona.

Se invece contasse solo che il software faccia ciò che si suppone debba fare allora io preferisco mollare il software ed relativo linguaggio (sono serio). Però capisco che ci sono invece delle persone che la pensano diversamente da me.

Ognuno sceglie i marcatori che vuole quando crea un proprio linguaggio di programmazione. Questo vale anche per i linguaggi degli anni passati.

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.

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'è.

Perchè il qualcosa è noto solo al programma? Lo chiedo perchè voglio imparare e perchè sono curioso.

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.


Io so che il sorgente attraverso il compilatore viene tradotto in linguaggio macchina oppure prima in assembly e poi in linguaggio macchina. Nell' eseguibile c'è il codice macchina. Non so è se giusto.

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

Sia sull' Assembly che sul Pascal ci sono istruzioni apposite che servono per indicare la dimensione dei dati giusto? in Asm si chiamano pseudo-op.

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.

2) In Pascal le istruzioni relative ai tipo di dati (quelle che hai menzionato) sono astratte? Se si perchè? Sono curioso e voglio impare.

Astratte?

Non ho capito la parte dopo la virgola e quindi anche la domanda finale.

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.

C'è da dire che a seconda del programma che bisogna scrivere non credo che servano tutte le righe ci codice contenuto nella libreria.

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

Es. per il Pascal le librerie sono compilate mentre quelle che si possono inserire

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

In Cobol come minimo svariate cose si possono fare senza includere le librerie e senza scrivere il codice delle librerie all' interno del programma.

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!

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

Dove si trovano queste pile ci codice già scritto da altri?

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.



CMP in Asm non corrisponde a == in C. In C è If.

Eh no. CMP sta per Compare cioè confronta. Il confronto in C/C++ è dato da ==

L'if in Assembly è implementato da una delle tante istruzioni di salto condizionato esistenti.

L' ultima frase che hai scritto se avviene su un vecchio O.S, che permette l' accesso diretto all' hardware, danneggia la cpu o c'è il rischio che si possa daneggieggiare?

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

Questo programma è strutturato e modulare, giusto? :

ASP.net:
Print "An example of a GOTO statement"
Sleep 1000
Goto program_continue
Print "This line of code will never be executed"
       program_continue:
Print "We just skipped some code"
Sleep
End

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

Questo con il linguaggio Ada:

with Ada.Text_IO; use Ada.Text_IO; procedure Hello is begin Put_Line ("Hello, world!"); end Hello;

Quel procedure indica una subroutine, per cui è strutturato.

Non c'è un sottoprogramma all' interno di un altro sottoprogramma.

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



Questo non lo sapevo.
Mi puoi far vedere un es. di un programma in C senza innestare blocchi?

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

Come si vede c'è un solo blocco ed è il main.




Questo qui per me è strutturato e modulare visto che non tutte le righe hanno la stessa tabulazione ed più mov ax etc.. ed Int 21H si trovano all' interno di START:; etc... di ends

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.

Se fosse stato un programma non-strutturato ogni riga di istruzione avrebbe avuto la stessa tabulazione e non ci sarebbe nessun sottoprogramma (o come si chiama).

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.
 
Ultima modifica:
Io non impongo al mercato di usare un determinato linguaggio o/e una determinata architettura. Per me il mercato o/e le aziende o/e startup etc... sono libere di scegliere in che direzione vogliono andare e quindi che cosa usare. ...
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).
 
....
Nel caso dell'elettronica analogica c'è ben poco da programmare.
....
Il riferimento era all'ambito embedded, dove sfido chiunque a trovare un processore x86.
....
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.
...
in Assembly si possono definire solo gli elementi nelle sezioni dati statiche. Niente è specificabile per quanto riguarda i dati nel heap.
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.
 
Pubblicità
Pubblicità
Indietro
Top