Newsgroup: it.comp.programmare
Titolo: Capire cosa succede dietro le quinte

Considerate un semplice file c come questo:
#include <stdio.h>
void main()
{
	printf("Hello World!\n");
}
Il compilatore lo traduce in questa maniera:
; C:\IDE68K\EXAMPLES\COMPILAZIONE_C_MISTA_68K\HW\HELLO.C - Compiled by 
CC68K  Version 5.00 (c) 1991-2005  Peter J.Fondse
; #include <stdio.h>
; void main()
; {
        section   code
        xdef      _main
_main:
; printf("Hello World!\n");
        pea       @hello_1
        bsr       _printf
        addq.w    #4,A7
        rts
; }
        section   data
@hello_1:
        dc.b      72,101,108,108,111,32,87,111,114,108,100,33
        dc.b      10,0
        xref      _printf
Con xref  indichiamo una label definita da qualche altra parte:
ma dove precisamente?
Ad esempio: la bsr salta da qualche parte, ma per me è verso l'infinito 
e oltre...dove va a pescare? :-)
Piccolo commento personale: il file "assembly finale espanso" eseguito 
da simulatore (che da quanto ho capito è quello di sopra, con tutti i 
riferimenti esterni dalle librerie c tradotte in assembly e linkate nel 
file finale) è pazzescamente lungo, sono rimasto stupefatto!!!
Ci metterei due giorni se lo volessi leggere istruzione per 
istruzione...e considerando la semplicità del programma c originale c'è 
da rimanere sbalorditi per come possa essere la traduzione assembly di 
programmi più grossi.
E' menomale che  il c è un linguaggio a metà strada tra quelli più di 
alto livello e quello assembly :-)
-- 
Bonus di 25 euro su 
betfair.it
, codice da inserire: AAAACGWFG
Vai sul mio sito(in fondo alla pagina) per altri dettagli:
http://digilander.libero.it/maxxam99/

 alto livello e quello assembly :-)
E non lo vedi che codice assembly ha generato?
Ha creato un'area di dati con la tua stringa costante, ha messo
l'indirizzo nello stack prima di chiamare la funzione di libreria
(convenzione del C)
Poi aggiunge 4 all'indirizzo del registro A7, che al momento mi sfugge
il motivo di questa istruzione e torna.
Ha semplicemente compilato la chiamata ad una funzione con un
parametro.

 Ma mica devi andare a vedere come compila le librerie!
No, però alla fine quello fa il mio programma, se lo eseguo sul 
simulatore istruzione per istruzione col l'apposito pulsantino autostep 
  son portato(lo so è da folli) a leggere tutte le righe :-)
Grazie anche per l'altro post.


 il motivo di questa istruzione e torna.
Non lo fa per fare in modo che lo SP punti non più a @hello_1  ma più in 
basso(sullo stack)?
In fondo una volta uscito da quella funzione non serve più che lo sp 
contenga quell'indirizzo...


 basso(sullo stack)?
Non credo: A7 non e' lo SP.


Mi stai demolendo una delle poche cose che credevo di sapere, sul testo 
che ho:
http://digilander.libero.it/maxxam99/Pics/2010-07-05_205825.jpg
Se non sono in modalità supervisore è il settimo registro indirizzi ad 
essere usato come stack pinter...no?



Tranquillo che hai ragione tu.
Quello schemino che hai linkato e' inequivocabile.
Mi sono fatto trarre in inganno da un tuo precedente messaggio con
alcune righe di codice dove lo stack pointer veniva indicato con SP.
Poi la mia memoria, e la confusione tra Motorola, Zilog e Intel, oltre
al lungo tempo passato a non usare piu' l'assembly, hanno fatto il
resto.
Effettivamente il Motorola non ha un registro dedicato allo SP ma usa
A7, e adesso quella istruzione che aggiunge 4 ad A7 comincia a
diventare comprensibile anche a me.

 Tranquillo che hai ragione tu.
Avevo comunque il dubbio perché da quanto ho capito il 68000 ha ben tre 
stack pointer(uno in modalità utente e due in modalità supervisore):
http://digilander.libero.it/maxxam99/Pics/2010-07-06_002650.jpg


 
http://digilander.libero.it/maxxam99/Pics/2010-07-06_002650.jpg
Come non detto, forse i 2 sp in modalità supervisore l'ha il 68020 e non 
il 68000 che ne dovrebbe avere solo uno per modalità.
