PDA

Visualizza la versione completa : [Commento]Il linguaggio migliore........


Luc@s
31-10-2002, 20:46
Ho visto che spesso, soprattutto in questi giorni, si parla di decidere qual'è il linguaggio migliore rispetto ad altri(vb vs c, java vs C++, ecc...)
Io penso che tutti i linguaggi abbiano pro e contro, se usati correttamente nei loro campi di utilizzo, e che nn esiste il linguaggio migliore.
Il linguaggio migliore e soggettivo ed è quello che meglio si adatta a te!In fondo il linguaggio di programmazione e l'espressione ea livello umanamente comprensibile di codice binario!
Io ho detto la mia:adhone:
Voi che ne pensate??????





:ciauz:

sebamix
31-10-2002, 20:53
Stessa cosa (a parole diverse) che ho sempre detto e ridetto io.
Ormai rinuncio alle discussioni in cui si tenta di stabilire quale sia il linguaggio migliore :quipy:

Luc@s
31-10-2002, 21:00
Originariamente inviato da McAuriel V
il linguaggio migliore?
C/C++
sempre
:mad:


Perfavore..........è un 3d serio:dhò:

Luc@s
31-10-2002, 21:01
Originariamente inviato da sebamix
Stessa cosa (a parole diverse) che ho sempre detto e ridetto io.
Ormai rinuncio alle discussioni in cui si tenta di stabilire quale sia il linguaggio migliore :quipy:


ma nel mio commento..........ho sbagliato qualcosa o ti sembra corretto?è sensato?

sebamix
31-10-2002, 21:12
Quello che volevo dire è che il tuo commento è assolutamente sensato, sono molti altri thread che non sono sensati... :quipy:

Luc@s
31-10-2002, 21:14
Originariamente inviato da sebamix
Quello che volevo dire è che il tuo commento è assolutamente sensato, sono molti altri thread che non sono sensati... :quipy:

:D

tnk

steno12
31-10-2002, 22:01
Assembler

dimostrazione pura del linguaggio migliore
rapporto istruzioni codice macchina 1 a 1 (solo in assembler ovviamente...... in quanto non cìè nè per nessuno ne c ne vb)

dovreste avere un programmino in c:\windows\ che si chiama debug.exe

cominciamo utilizzando DEBUG.EXE , che dovremo prima lanciare da una sessione MS-DOS digitando:


al prompt di DEBUG (-) (il trattino del segno meno), digitiamo:

-R (significa Registers)

e vedremo una serie di lettere e numeri più o meno come segue:

AX=0000 BX=0000 CX=0000 DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000
DS=1C82 ES=1C82 SS=1C82 CS=1C82 IP=0100 NV UP EI PL NZ NA PO NC
1C82:0100 C3 RET
-
Abbiamo di fatto (tramite il comando R) chiesto a DEBUG di visualizzare lo stato dei registri, e come potete vedere, Debug ci ha restituito una serie di valori, compreso lo stato dei flags (NV UP.......PO NC); il tutto ha il seguente significato: (Tutti i numeri sono espressi in notazione Esadecimale).
· AX=BX=CX=DX=BP=SI=DI=0000 :sono i registri di uso generale che DEBUG ci ha dati già inizializati a 0000.
· SP=FFEE è invece lo Stack Pointer che indirizza la prima area di memoria disponibile per operazioni sullo Stack tipo PUSH e POP. Perchè FFEE? e non 0000? La risposta sta nel fatto che lo Stack Pointer cresce verso il BASSO cioè verso valori decrescenti.
· DS=ES=SS=CS=1C82 è un qualunque valore di Segmento a cui puntano i registri di Segmento. Non è importante se il valore è 1C82 o 37A9 o qualunque altro numero, ma è importante il fatto che Tutti i registri di Segmento puntino allo Stesso Segmento. Possiamo infatti, in questo modo, costruire un file .COM , un file cioè che ha un solo segmento per il programma, i dati e lo stack.
· IP=0100 (Istruction Pointer)=Puntatore alle istruzioni punta alla locazione di memoria 100 (esadecimale). Ciò significa che la prima istruzione del programma che sarà eseguito partirà dalla locazione 100h, e ciò a causa di un retaggio del vecchio sistema operativo CP/M che MS-DOS sostituì fin dalla prima versione. Infatti i primi 256 Bytes (da 0000 a 00FF) erano riservati, e lo rimangono tuttora, al PSP (cioè il Program Segment Prefix o Prefisso del Segmento di Programma) che analizzeremo più avanti. Per ora può bastarci sapere che il Programma DEVE iniziare alla locazione 0100h.
· NV è lo stato dell'ultima operazione eseguita dal sistema operativo e indica che non si è verificato Overflow (NV = No oVerflow)
· UP significa che il Direction Flag è settato a UP (in alto) (se dovessimo eseguire trasferimenti multipli, questi avverrebbero dal basso verso l'alto).
· EI (Enable Interrupt) tutti gli Interrupt sono abilitati.
· PL (PLus) significa che l'ultima operazione ha dato un risultato positivo.
· NZ (Not Zero) significa che l'ultima operazione ha dato un risultato diverso da Zero.
· NA (Not hAlf-carry) significa che l'ultima operazione non ha provocato riporto di bit tra i 4 bit inferiori e i 4 bit superiori.
· PO (Parity Odd) significa che l'ultima operazione ha dato un risultato con parità dispari. (Il bit 0 era settato a 1)
· NC (Not Carry) significa che non c'è stato riporto e cioè il risultato dell'ultima operazione non ha superato il limite del Byte.
· 1C82:0100 C3 ----------- RET ( o qualunque altra cosa vediate) significa che nella locazione 1C82:0100 si trova un valore Casuale (memoria sporca) che DEBUG ci ha allocato così come l'ha trovata. Nel caso C3 (RET) significa che alla locazione 1C82:0100 vi si trova il numero esadecimale C3 che e pari a 1100 0011 binario e che ha il significato Assembler di RET cioè (RETurn from subroutine). Se non vi sentite ancora a vostro agio con i numeri esadecimali, Vi consigliamo di ricominciare dalla sezione
ABSOLUTE BEGINNER.
Proseguendo invece nel nostro scopo digitiamo ora:

-F 100 2100 90

e cioè: Fill (riempi) le locazioni di memoria da 100 a 2100 con il valore 90
(Il valore 90h ha il significato Assembler di NOP cioè No OPeration) ovvero nessuna operazione. Ciò è importante perchè, qualunque cosa scriveremo dopo, è meglio averne il controllo con un codice NOSTRO (che appunto non effettua alcuna operazione) e che è facilmente individuabile.
Digitando di nuovo:
-R
vedremo che ora sarà cambiato solo l'ultima riga e cioè avremo:

1C82:0100 90 --------NOP
ciò significa che il nostro comando è stato accettato.

digitiamo ora:
-N PRV.COM
e avremo informato DEBUG che a questo programma abbiamo dato il nome di PRV.COM
N PRV.COM infatti significa: (Name PRV.COM)
digitiamo ora:
-R CX

Come risposta avremo:
CX 0000
:

I due punti significano che DEBUG aspetta un numero da tastiera che sostiruirà il vecchio valore 0000 di CX.
digitiamo quindi 2000 (e chiudiamo sempre con Return o Invio).
Digitando ora:
-R
vedremo che CX sarà cambiato in 2000.
digitiamo quindi:
-W
ovvero Write, e avremo già salvato il nostro programma di 2000h bytes su disco, nella directory corrente del drive corrente che si chiamerà PRV.COM
NON FATELO ANCORA GIRARE PER CARITA'.
E' ancora incopleto e bloccherebbe il vostro Computer.
E' però opportuno uscire momentaneamente da DEBUG con:
-Q
e dal DOS vedere il risultato con:
DIR PRV.COM
e infatti lo troveremo, aggiornato al momento in cui abbiamo digitato -W e della lunghezza di 8.192 Bytes;
infatti 2000h=8.192 decimale.
Rientramo in debug, però ora digitando direttamente:

DEBUG PRV.COM

digitiamo quindi:
-R
e accertiamoci che CX=2000 e l'istruzione alla locazione ????:0100 sia 90 ovvero NOP.
Si è proprio il nostro programma.
( Avrete dunque capito che DEBUG scrive la dimensione del File nel registro CX, ( questo puo' bastare per un file .COM che non supera i 2^16 (-1) = 65535 = FFFF bytes); nel caso di files piu' lunghi in effetti e' la coppia BX - CX che ne determina la dimensione fino a 2^32 (-1) cioe' FFFFFFFF Bytes; calcolatene a quale valore decimale corrispondono!

Assembliamo quindi le nostre prime istruzioni con il comando -A a partire dalla locazione 0100 digitando:
-A 100
e scriviamo di seguito le seguenti istruzioni:
(A fianco dei numeri che visualizzerà DEBUG)

????:0100 MOV AH,0F
????:0102 INT 10

????:0104 MOV BL,39
????:0106 MOV AL,41
????:0108 MOV AH,9
????:010A MOV CX,1
????:010D INT 10

????:010F MOV AH,7
????:0111 INT 21
????:0113 CMP AL,1B
????:0115 JZ 011D
????:0117 INC AL
????:0119 INC BL
????:011B JMP 0108

????:011D MOV AH,4C
????:011F INT 21

per terminare l'immissione di istruzioni dare un Invio (o Return) a vuoto
quando si arriva a:
????:0121

Registriamo il programma con:
-W
e usciamo al DOS con:
-Q
Abbiamo deliberatamente separato i gruppi di istruzioni per renderle più leggibili, ma Debug le presenterà una di seguito all'altra.
Vediamo ora di capire ogni singola istruzione:
Le prime istruzioni: MOV AH,0F e INT 10H servono a determinare la modalità corrente del video, ma la cosa più importante è che questa funzione ritorna in BH la pagina video attiva, alla quale faranno riferimento le istruzioni successive. Notate infatti che il registro BH non viene interessato deliberatamente da nessuna istruzione, e ciò per far riferimento sempre alla stessa pagina video.
INT 10 è un interrupt del BIOS, ovvero un microprogramma che risiede nella ROM e che consente con una semplice istruzione ciò che altrimenti avrebbe richiesto un centinaio di ulteriori istruzioni elementari.
Nella sezione Avanzata, tratteremo approfonditamente gli Interrupt e impareremo a crearne di nostri.
Per ora basti sapere che dopo INT 10 (Funzione 0F in AH) avremo in BH il numero di pagina video che interessa il nostro programma.
Questo ci consente di far girare il nostro programma anche sotto Windows 95 ovvero in un ambiente Multitasking.
Il successivo gruppo di istruzioni (MOV BL,39.....INT 10) richiama un'altra funzione del BIOS che visualizza una o più volte il carattere contenuto in AL con i seguenti significati:
-MOV BL,39 definisce i colori del carattere nei primi 4 bit (3) e dello sfondo nei successivi 4 bit (9).
-MOV AL,41 definisce il carattere da visualizzare (41h = 65 = 'A') cioè la lettera A in codice ASCII.(Possiamo mettere qualunque carattere ASCII).
-MOV AH,9 informa il BIOS che si richiede la funzione n. 9 (Visualizza carattere).
-MOV CX,1 informerà il BIOS che il carattere andrà ripetuto 1 sola volta.
-Ricordandoci che in BH abbiamo GIA' la pagina DOVE visualizzare il carattere, INT 10 esegue la funzione e ci visualizzerà il carattere contenuto in AL

-Il gruppo delle istruzioni successive invece prelevano un carattere dalla tastiera, tramite la funzione 7 dell'interrupt DOS INT 21 (disponibile anche sotto Windows 95), e infatti MOV AH,7 - INT 21 attende che venga premuto un tasto dalla tastiera e ritorna in AL il codice ASCII del carattere corrispondente.
-Con l'istruzione CMP AL,1B verifichiamo se il carattere premuto è stato 'Esc'. e in tal caso facciamo terminare il programma. Infatti CMP AL,1B esegue una differenza tra il contenuto di AL e il numero 1B scartando il risultato, però settando i flag relativi. Di conseguenza se AL contiene 1B, verrà settato il flag Zero e quindi sarà eseguito il salto condizionale a 011D che sarà effettuato dall'istruzione JZ 011D (Jump if Zero to 011D).
Prima di ripetere il ciclo, e tanto per avere la soddisfazione di 'scherzare' con i caratteri incrementiamo il valore del carattere premuto (tramite INC AL), e cambiamo colore tramite INC BL, quindi eseguimo un salto incondizionato a 0108 che visualizzerà il carattere contenuto in AL (ma stavolta, quello che abbiamo digitato dalla tastiera, incrementato di 1, e con un colore che via via sarà diverso a causa dell'istruzione INC BL.
-Se alla fine premiamo il taso 'Esc', il programma salterà a 011D, dove troviamo le ultime due istruzioni: MOV AH,4C - INT 21 che sono le istruzioni di USCITA dal programma e che sono FORTEMENTE raccomandate dalla Microsoft. Infatti avremmo potuto terminare il nostro programma con una semplice istruzione RET (RETurn) che avrebbe riceduto il controllo al DOS, ma ciò potrebbe creare problemi in futuro e quindi accettiamo i suggerimenti Microsoft e terminiamo i nostri programmi con MOV AH,4C - INT 21.
Utilizzeremo RET solo nei rientri dalle nostre subroutines, e avendo l'accortezza di usare la RET appropriata: RETN o RETF cioè RET Near o RET Far, a secondo se ci troviamo all'interno o all'esterno di uno stesso segmento.

Facendo ora girare il programma PRV.COM ne vedremo il risultato nello schermo. E' ovviamente ben poca cosa, ma pensate: Quante istruzioni sono state necessarie? E se avessimo scritto noi gli interi processi di accesso alle periferiche video e tastiera?
Non esageriamo se affermiamo che sarebbero state necessarie diverse centinaia di istruzioni.
Ma qui sta il bello, abbiamo EFFETTIVAMENTE controllato noi LA MACCHINA. E con un controllo (quasi) TOTALE. Ci stiamo infatti ancora 'fidando' delle istruzioni che saranno eseguite dalle INT del BIOS e del DOS, ma ci sarà sempre consentito di scrivere delle nostre istruzioni, dirette e in linea, oppure di scrivere delle nostre INT che possiamo 'agganciare' quando e come vogliamo.
Riapriamo di nuovo PRV.COM con:
DEBUG PRV.COM
stavolta digitiamo:
-U (Unassemble)

e vedremo il listato del nostro programma a destra, mentre a sinistra,
dopo i soliti indirizzi ????:0100 vedremo una serie di numeri, il primo
dei quali è B40F.
Ebbene si, B40F è la traduzione in linguaggio macchina della nostra
prima istruzione:
MOV AH = B4
,0F = 0F
Questa è la riprova che i nostri codici ASM vengono tradotti con un
rapporto 1:1 in linguaggio macchina.
Notate la sottile differenza tra MOV AH,... MOV AL,.... e MOV BL,....
Solo 3 bit sono interessati a determinare se il valore successivo della
memoria deve essere caricato nel registro AH, nel Registro AL o nel
Registro BL, e infatti:

MOV AH = B4 = 1011 0100
MOV AL = B0 = 1011 0000
MOV BL = B3 = 1011 0011


La sequenza completa dell'istruzione MOV 'immediata' relativa ai registri
a 8 bit è la seguente:

Hex Binary ASM

- B0 = 1011 0000 MOV AL,(il valore immediato successivo a MOV AL)
- B1 = 1011 0001 " CL
- B2 = 1011 0010 " DL
- B3 = 1011 0011 " BL
- B4 = 1011 0100 " AH
- B5 = 1011 0101 " CH
- B6 = 1011 0110 " DH
- B7 = 1011 0111 " BH

B? dunque mette il valore immediatamente successivo (1 byte in
questo caso) alla istruzione B? nel registro determinato da ? ;
ad esempio:

B407 = MOV AH,07
B513 = MOV CH,13
B307 = MOV BL,07

Per lavorare uso vb,vc6..... per studio e passione tasm 5.0 e masm32 .........perchè la traduzione ASM/Codice Macchina è quasi sempre
in rapporto 1/1.

Luc@s
31-10-2002, 22:02
:dhò: :dhò:

o ma siete duri

:dhò: :dhò:

degno
31-10-2002, 22:12
Sono d' accordo con voi che è stupido parlare di linguaggio migliore, ma questo non significa che parlare dei pro e dei contro dei vari linguaggi non aiuta a farsi un' idea migliore dell' utilità di ciascun linguaggio. Se per gli esperti possono essere discussioni oziose (come parlare dell' arbitro Moreno a distanza di mesi), per i principianti possono essere molto istruttive.

Luc@s
31-10-2002, 22:28
Originariamente inviato da degno
Sono d' accordo con voi che è stupido parlare di linguaggio migliore, ma questo non significa che parlare dei pro e dei contro dei vari linguaggi non aiuta a farsi un' idea migliore dell' utilità di ciascun linguaggio. Se per gli esperti possono essere discussioni oziose (come parlare dell' arbitro Moreno a distanza di mesi), per i principianti possono essere molto istruttive.

su questo son daccordo!!!

Ma post come dici tu nn ne ho visti molti:master:

Loading