Newsgroup: it.comp.lang.visual-basic
Titolo: Fare un compilatore

>mine!***

 molto velocemente.
Tutto vero, se non per il fatto che mi risulta che VB 5.0 puo' anche
compilare veramente.
Per dirla tutta pero' io considero compilatore anche un qualcosa di molto
piu' semplice.
Per esempio una volta, ai tempi quando mi divertivo a scrivere codice per
giochini  (mai ultimati),
ho fatto una routine che, dato il disegno di uno sprite (un fotogramma),
generava il codice macchina
necessatio per disegnarlo a video senza l'ausilio di pesanti routin
generiche. Il che si traduceva
in una chiamata di procedura con coordinate X;Y, e questa mi disegnava nel
modo PIU' VELOCE
AL MODO, lo sprite desiderato.
Hi, Ciao
Ettore    By -MES-

molto velocemente.
  Il VB5 pero' utilizza il compilatore del VC++
  Ciao :-)
  Massimo
  Nell'indirizzo, sostituire DIESPAMMERS con MC1258
  In the address, replace DIESPAMMERS with MC1258

Giusto per un pò di chiarezza sarebbe utile capire coa si intende per
compilatore :
di solito è un programma che crea la struttura definita nel msg precedente
ed il linker collega il tutto in un eseguibile a livello di sistema
operativo.
In quest'ottica VB non è un compilatore.
Il codice generato è 'pseudo-code' che necessita della vm di vb per essere
eseguito.
Per Massimo Luciani :è vero che VB utilizza il compilatore di VC++ ma solo
il preprocessore poi stop.


 
Il preprocesore? vogliamo comparare il prepocessore di un basic con quello
di
un C++ ? Sono completamente diversi!!! ?!?!?!
Che io sappia il preprocessore e' qulla parte del compilatore che risolve
le
costanti, le macro, elimina i commenti ed elabora le formule! Cose
fortemente
condizionate dal tipo di linguaggio.
Hi,Ciao
Ettore         By -MES-


Questi si chiamano pre-compiled bitmaps (o qualcosa di simile).
Tecnicamente un COMPILATORE e' un qualsiasi programma che traduce una serie
di istruzioni da linguaggio di alto/medio livello (C, Pascal, Basic...) a
linguaggio di livello inferiore.
Solitamente (ed anche in questo thread, credo) ci si riferisce al linguaggio
macchina come linguaggio di arrivo.
Paradossalmente, anche VB (qualsiasi versione) crea un codice "compilato",
peccato che sia un P-CODE, ossia non linguaggio macchina, quindi
direttamente eseguibile dal processore, ma un linguaggio intermedio che deve
essere interpretato ulteriormente prima di poter essere dato in pasto al
processore.
Tornando a Franco (padre di questo thread)...
Sarei curioso di sapere cosa hai intenzione di fare :-T    <-
dubbioso/pensoso
Lo sviluppo di un compilatore e' un progetto piuttosto complesso, che
presuppone la conoscenza di molti argomenti differenti (dall'informatica
teorica, le grammatiche formali, la costruzione di un parser di linguaggio,
le macchine a stati finiti, ottima conoscenza del linguaggio macchina
target, opcodes, cicli macchina, etc...), senza contare naturalmente le
eventuali strategie di ottimizzazione del codice prodotto.
Roal Zanazzi
z...@iol.it

compilare veramente.
Si, bisogna poi vedere che cosa significa compilare veramente...
Secondo me Delphi si che compila, non VB ! Un mega fisso e passa di
DLL base per un EXE di 3 Kb lo chiami compilare veramente ?
Ciao.
""""""""""""""""""""""""""""""""""""""""""""""
 -----------Federico Emanuele Galli----------
 ----------Visual Basic's Programmer---------
 
 Sideralis Programs (Visual-Basic and Delphi)
 
http://www.geocities.com/colosseum/loge/2151
""""""""""""""""""""""""""""""""""""""""""""""
                 Trust no ONE.

>In quest'ottica VB non è un compilatore.
Si, questo e' giusto !


In quest'ottica VB non è un compilatore.
Guarda che se compili codice macchina VB crea dei files .obj che poi
evidentemente dà in pasto ad un linker: basta dare un'occhiata con
gestione risorse mentre VB compila un grosso progetto: spuntano gli
obj che alla fine vengono cancellati.
In quest'ottica quindi VB è un compilatore: il fatto che faccia
riferimento a funzioni contenute nelle dll di runtime non ha influenza
sulla velocità del codice. Si tratta semplicemente di una scelta di
Microsoft, che avrebbe potuto benissimo decidere di fornire il runtime
come .lib e linkarlo staticamente: in questo caso non avresti avuto
bisogno del runtime in esecuzione, ma il codice eseguito sarebbe lo
stesso.
Ciao
--------------------------------------------------------------------
Fulvio Senore
Eliminate "zz" dall'indirizzo e-mail per scrivermi (spammers...)
Remove "zz" from e-mail address to write me (spammers...)
--------------------------------------------------------------------


Piano, piano, si sara' sbagliato...
credo che si riferisse al back-end compiler (cosa che e' effettivamente
vera, vedere le mie considerazioni nel mio altro messaggio su questo
thread).
Roal Zanazzi
z...@iol.it


Allora... ultime notizie:
ho fatto un progettino veloce veloce in VB5.
L'ho compilato in entrambi i modi (P-CODE e nativo).
Dato che non riesco piu' a trovare il Turbo Debugger, ho usato un
mini-disassemblatore (meglio di niente).
Ho analizzato un po' il codice risultante (asm). I risultati:
1) Il compilato nativo e' effettivamente compilato in codice Intel x86
2) Entrambi chiamano una marea di funzioni della MSVBVM50.DLL
3) Il compilato nativo non e' sicuramente solo Runtime + P-CODE
impacchettato in un EXE (altrimenti avrei trovato i due dump praticamente
uguali)
Il punto 2 da' sicuramente ragione a Federico. (e comunque, Delphi non
copila SECONDO te... Delphi COMPILA E BASTA!)
Inoltre:
Nella directory di VB5 c'e' C2.EXE che mi ha fatto ricordare il Visual C (in
particolare mi sembra di ricordare che C2.EXE fosse il suo back-end
compiler) il che darebbe ragione a quelli che dicono che VB5 usa il back-end
compiler del Visual C.
La versione di C2.EXE e' 11.00 (che coinciderebbe circa con l'evoluzione di
VC, giusto?).
Solo che... le informazioni di versione di C2.EXE dicono:
    "Microsoft (R) 32-Bit Visual Basic Compiler 80x86"
e allora? cos'e'? una versione modificata (e quindi non E' IL BACK-END di
VC!) o semplicemente uno scherzo di M$?
Sempre nella dir di VB5 c'e' anche LINK.EXE che e' effettivamente il linker
di M$:
    "Microsoft (R) 32-Bit Incremental Linker"
Finale della storia:
VB5 puo' compilare, ma e' ancora anni luce da tutti gli altri
compilatori/ambienti di sviluppo (leggi Borland C++Builder, Delphi, etc...).
Non ho ne' tempo ne' voglia di controllare come sia ottimizzato dal
compilatore il codice di VB5, ma se (pare vero) viene usato in back-end
compiler di Visual C, allora potete stare sicuri che e' una schifezza (per
chi non lo sapesse, il compilatore del Visual C, oltre ad essere stra-pieno
di bachi, e' anche considerato a livello mondiale uno tra i peggiori
ottimizzatori esistenti, ed e' sempre stato cosi'!)
Roal Zanazzi
z...@iol.it

> Bisogna conoscere bene l'architettura del SO, di seguito ad essa adattare il programma che si desidera "comporre". Esso a seconda delle diverse situazioni ha compunque un'header, un'area dati(codice+dati(se ci sono)) e a volte una zona stack. Il primo, il più importante, è il descrittore che permette al SO di allocare il programma e di stabilirne l'inzio dell'area codice verso il quale bisognerà praticare uno JMP. Il metodo più semplice è quello di comporre dei codici sostitutivi della sintassi del linguaggio che si desidera creare e poi comporlo(link) badando alle informazioni dell'header, il tutto con diversi passaggi, object compresi. In teoria il VB può farlo, ma è dispendiso e poco utile, in questo vi riesce meglio il C. Il Cobol per Win è scritto in. Spero solo di aver risposto alla persona esatta. In qualsiai caso mi troverai su ioProgrammo della DiemmeEditori. Ciao e buon lavoro !!!

 stesso.
OK, Cosi' va Molto Meglio.... Sono completamente daccordo con te!  :-)))



Se ti interessa, tempo fa avevo visto qualcosa relativo alle bitmap
compilate (era sicuramente in C)...
Non ricordo bene, ma prova a dare un'occhiata su
ftp://x2ftp.oulu.fi/pub/msdos/programming/
oppure
ftp://teeri.oulu.fi/pub/msdos/programming/
(e' lo stesso sito, ma a volte fa cosini con il DNS...)
scaricati e cerca un po' sul file di indice (INDEX.TXT o simili)
Vedi anche se c'e' altra roba che ti puo' interessare. Non dovrebbe esserci
nulla su VB, perche' contiene materiale prodotto e/o utilizzato
prevalentemente dai programmatori di demo (quindi in DOS, grafica, suono,
effetti speciali...), ma c'e' anche documentazione tecnica e ottimi spunti,
algoritmi, etc...
--
Roal Zanazzi
z...@iol.it

Ringrazio Roal Zanazzi per il supporto, effettivamente ho utilizzato il
termine preprocessore in modo improprio ma per dirla tutta quanti sanno
esattemente cos'č un "back-end compiler" ???
Che comunque confermo essere quello di VC
Alla fine VB non compila (o si ???)


 Che comunque confermo essere quello di VC
Ok per questa volta ti perdono a pieni voti, anche perche', lo ammetto,
non so cosa si intende per "back-end compiler", non che non so
quli sono tutti i passi per arrivate al .exe ma non so in quale punto va a
cadere
quello che voi, sicuramente propriamente, definite "back-end compiler".
Dato che odio l'ignoranza, anche solo di termini, Sapete spiegarmenlo ?
Salutoni
Hi,Ciao
Ettore                 By -MES-
http://www.aspide.it/freeweb/ilmes


Premetto: la memoria non e' piu' quella di una volta... qundi perdonatemi
eventuali "errori" ;-)
La compilazione avviene (piu' o meno) con queste fasi:
1) File sorgente
            |
2) Pre-Processore (espande macro, include file header, etc...)
            |
3) Analizzatore lessicale ("scanner": individua i tokens, elementi lessicali
del linguaggio)
            |
4) Analizzatore sintattico ("parser": verifica la correttezza semantica dei
tokens)
            |
            | produzione del codice "intermedio"
            |
5) Ottimizzatore
            |
6) Back-end compiler (generatore codice intermedio -> codice binario)
            |
7) File oggetto (.OBJ)
Questa catena viene eseguita per ogni file sorgente (nel caso del VB per
ogni .BAS e .FRM/FRX)
Quando tutti i file sorgenti sono compilati in .OBJ, viene eseguito il
linking, ossia vengono "fusi" tutti i file .OBJ, vengono risolti gli
indirizzamenti (variabili, puntatori, etc...) e viene prodotto il file
eseguibile.
In Windows c'e' anche la fase di compilazione e linking delle risorse (file
.RES), ma la cosa non ci interessa al momento ed e' comunque simile a quella
esposta sopra.
Spero che queste informazioni siano utili a tutti i partecipanti a questo
NG.
Sono assolutamente convinto che un programmatore (persino in VB) non possa
NON sapere come funziona (almeno teoricamente) un compilatore...
(sarebbe come dire che un pilota di Formula1 non sa cos'e' una biella!!!!!!)
P.S. Si', VB5 compila (tecnicamente), ma delega la maggior parte delle
funzioni interne alla DLL di runtime.
--
Roal Zanazzi
z...@iol.it