Valerio Battaglia

Di sicuro prof lei ha fatto delle considerazioni che certamente sono vere ma che noi non potevamo sapere.
Lo studente, come lei sa, con i tempi universitari e con altri corsi, basa la propria preparazione sulla falsa riga dell'esame svolto nella sessione precedente.
Per cui la lamentela nasce dal fatto che, in considerazione dell'esonero dell'anno precedente, nessuno di noi credo che abbia focalizzato la propria preparazione sull'assembler, ma penso che molti avranno fatto come me:
avere una buona dimestichezza con l'assembler ma sapere anche 8 blocchi di slides, in cui molte definizioni vanno capite e imparate.
Quindi la mia preparazione era anche su molti argomenti che il compito non mi ha permesso di dimostrarne la comprensione.
Fatto sta che le nostre sono solo lamentele, e non una critica diretta nei suoi confronto (almeno per quanto mi riguarda).
Diciamo che lamentarsi succede all'uscita dell'80% degli esami, anche perchè finchè ci sarà anche solo uno studente del mio corso che riesce a passare l'esame, significa che studiando l'esame si poteva passare....

Penso che si voleva solo constatare il fatto di essersi ritrovati spiazzati davanti ad un compito che non avevamo preso troppo in considerazione (come studenti intendo...).

Lei non deve aspettarsi che noi siamo persone con vasta esperienza in assembler...dato che è il primo esame in cui lo vediamo..lei deve solo testare se abbiamo appreso o no le nozioni di questo corso.Sicoome il corso è su architettura dei calcolatori e non sull assembler penso che le domande su altre parti che abbiamo fatto in queste settimane dovevano essere obbligatorie.secondo uno studente deve poter ottenere la sufficienza dimostrando che almeno le nozioni base del corso le ha apprese, ma in un compito del genere questo non può essere dimostrato.E' normale che per lei il codice sia facile, avendo una grandissima esperienza nel campo, e magari cose che ormai per lei sono banali possono indurla a pensare che le persone le possano apprendere facilmente, ma non è così perchè non tutti riescono ad apprnederle così velocemente e ad usarle con tale dimestichezza in 3 settimane di corso.

Salve,

concordo che i tempi sono compressi (non per mia scelta) e questo è il maggior problema dell'attuale ordinamento. il semestre darebbe più tempo per far "attecchire" le nozioni apprese a lezione. purtroppo alla fine dei 5 anni sapete molto meno di quello che si faceva ai miei tempi, non perché noi fossimo migliori, ma perché l'organizzazione permetteva quella fasi di approfondimento necessarie a far consolidare le nozioni (io ho imparato qualcosa di assembler nel 1990 e non ho più visto/letto/scritto un rigo in assembler fino all'anno scorso che mi hanno detto che a TV avrei insegnato Architettura ed il corso prevede l'assembler MIPS).

ma finché non si cambia ordinamento (tutti i corsi semestrali come ai miei tempi) come conciliare l'esigenza di prepararvi in modo adeguato e far uscire persone preparate (la cosa peggiore che possiamo farvi e far laureare con buoni voti persone che sanno fare molto poco. si sparge la notizia e nessuno vuole più ingegneri informatici di Tor Vergata) e l'ordinamento attuale che comprime un corso in 8 settimane?

mi dispiace per chi di voi ritiene quella di oggi una ingiustizia. io cerco di fare del mio meglio per voi (per quanto ci possiate credere)

Saluti

Francesco Lo Presti

Salve,

concordo che i tempi sono compressi (non per mia scelta) e questo è il maggior problema dell'attuale ordinamento. il semestre darebbe più tempo per far "attecchire" le nozioni apprese a lezione. purtroppo alla fine dei 5 anni sapete molto meno di quello che si faceva ai miei tempi, non perché noi fossimo migliori, ma perché l'organizzazione permetteva quella fasi di approfondimento necessarie a far consolidare le nozioni (io ho imparato qualcosa di assembler nel 1990 e non ho più visto/letto/scritto un rigo in assembler fino all'anno scorso che mi hanno detto che a TV avrei insegnato Architettura ed il corso prevede l'assembler MIPS).

ma finché non si cambia ordinamento (tutti i corsi semestrali come ai miei tempi) come conciliare l'esigenza di prepararvi in modo adeguato e far uscire persone preparate (la cosa peggiore che possiamo farvi e far laureare con buoni voti persone che sanno fare molto poco. si sparge la notizia e nessuno vuole più ingegneri informatici di Tor Vergata) e l'ordinamento attuale che comprime un corso in 8 settimane?

mi dispiace per chi di voi ritiene quella di oggi una ingiustizia. io cerco di fare del mio meglio per voi (per quanto ci possiate credere)

Saluti

Francesco Lo Presti

Io penso...
se tutti i prof. parlano male di qst nuovo ordinamento, gli studenti lo maledicono, troppe cose si dimenticano perchè imparate in troppo poco tempo, ecc... ecc... a che serve tutto questo??...se mi sento Scudieri che a lezione dice in aula "...io a volte lo dico in consiglio...ma vedete che li stiamo prendendo per il cu... a sti ragazzi!",e poi mi trovo all'ultimo ciclo del secondo anno (quello d'estate!!!)...con 4 esami + fisica, perchè lo sanno anche loro, lo sanno tutti che un buon 70% deve dare ANCORA fisica...con che coraggio possono fare una cosa del genere???...poi è ovvio che non capisci una ma*** e ti senti preso in giro!...
Capisco il prof Lopresti quando dice che vorrebbe che noi avessimo una buona preparazione, lo capisco...anche noi la vorremmo ....ma purtroppo non ci è consentito con questo sistema....ci stanno già troppi problemi e di sicuro l'ultima cosa che si poteva fare in un esonero (che in teoria dovrebbe essere più semplice di un appello e consentire un più facile superamento dell'esame durante il corso) era mettere la roba più complessa che abbiamo fatto....non c'era qualcosa di più difficile (parlo degli argomenti trattati).....oltre la doppia ricorsione e la gestione degli array nei cicli....non c'è altro...e credo che molti mentre si faceva fibonacci abbiano pensato (un pò anchio) "si vabbè....doppia ricorsione....si...ma sull'esonero mica può mettere sta roba".....

Questo esonero è stato proprio uno spiazzamento (altro che PC+4)!

A parte qst ce ne stanno di cose che andrebbero cambiate....ma di brutto... sto sistema non può andare avanti così....un ingegnere oggi esce con in testa un mucchio di cose (se se le ricorda)...ma senza saperle mettere in fila nè tantomeno realizzare qualcosa di concreto...è questo il tipo d'ingegnere che serve oggi?

Credo di aver toppato varie volte nel compito...

1a questione: ho salvato nello stack nella procedura chiamante un solo registro ($s0) per il parametro i che veniva passato alla funzione. Nella funzione chiamata ho, all'inizio della stessa, salvato e poi ripristinato il registro $a0 in quanto ritenevo fosse doveroso salvarlo onde evitare che cambiasse a causa della procedura doppiamente ricorsiva. E' un errore?
2a questione: giuro che, non potendo venire a lezione, avevo incontrato la slides che parlava di come lo stack veniva variato in funzione di una chiamata a procedura, ma non ci avevo capito nulla. Dato che non vorrei evitare di scrivere altre baggianate oltre a quelle che ho scritto, qualcuno mi può dare la sua soluzione all'esercizio?
Ne aggiungerò altre in seguito.
Intanto vi sarei grato per delle risposte che mi spieghino dettagliatamente come risolvere l'esercizio 2 o la slide che riporta l'esempio.

Io da parte mia ho usato lo stack in entrambe le funzioni.

Nel ciclo for salvo nello stack il contatore I e il valore I*4: il primo perchè dovendo interrogare un array che ha le celle in offset a distanza di 4, devo ogni volta aggiorare I*4. Inoltre questo valore lo salvo perchè mi serve in 3 circostanze: con B[i], A[i], chiamata ricorsiva e ancora B[i]. Per paura che lo perdessi e non volendo rifare tutto il procedimento per 4 ogni volta l'ho salvato.

Nell aircorsiva salvo 3 valori: il valore $ra, il valore n in ingresso (che mi serve per due ricorsive, quindi per passarlo come valore alla prima lo perdo dovendolo aggiornare) ed il valore di funzione_T(n/2) perchè questa funzione salva in $v0 che però è sovrascritto da funzione_T(n/4).

Ovviamente alla fine delle due funzioni dealloco :?

una domanda: nel caso non si superasse il primo esonero, si puo' fare il secondo e recuperare solo il primo agli appelli?

non so, l'hanno scorso non si poteva

una domanda: nel caso non si superasse il primo esonero, si puo' fare il secondo e recuperare solo il primo agli appelli?

da quello ke ho capito io, il giorno del secondo esonero chi ha superato la prima parte fà solo la seconda, gli altri recuperano tutto.

Non ho mai seguito a lezione. Ma vorrei sapere da voi che avete frequentato il corso se è mai stato esaminato in classe un esercizio simile al terzo dell'esonero con tanto di chiamate a funzioni e "disegnini colorati".
L'unico esempio che si fa sulle slides è un unica pagina nel capitolo "procedure" che, senza la minima spiegazione, fa finta di spiegare come si comporta lo stack nel caso di chiamata ricorsiva.
Nulla di simile comunque alla risoluzione dell'esercizio 3.
Allora mi chiedo, nell'ignoranza più totale che mi accompagna:
sono io in errore perchè nelle esercitazioni è già stato presentato qualcosa di simile oppure la mancanza di conoscenza mi ha portato a scrivere baggianate sul compito???

magari i professori hanno molte colpe, però non questa ragno: in classe (parlo del corso J-Z) abbiamo fatto molti esercizi in assembler, tipo fibonacci, uguale a questo praticamente, al termine del quale analizzavamo lo stack proprio come nell'esercizio del compito. Se l'ho sbagliato è perchè sono scemo io :roll:

Quindi in sostanza tocca rompersi la testa sulle doppie ricorsioni.
Vabbè, basta saperlo... :|

Quindi in sostanza tocca rompersi la testa sulle doppie ricorsioni.
Vabbè, basta saperlo... :|

Non ho ben capito cosa cambierebbe dalla singola ricorsione, voglio dire alla fine ogni volta che chiamate la funzione ricorsiva $ra viene salvata nello stack (se gli avete detto di farlo) di conseguenza nn mi sembra così complessa la gestione, dal momento che il salvataggio di $ra avviene ogni volta che chiamate la procedura (si può dire "in automatico".

Salve,

tengo a precisare che i lucidi non sono altro che un supporto alla didattica, che io rendo disponibile agli studenti. Io a lezione usp molto la lavagna per ulteriori precisazioni ed esempi (questo, le ricordo, non è un corso online). I lucidi non sostituiscono il testo (od i testi), l'elaborazione personale, gli approndimenti che a volte suggeriscono. Prendere a riferimento di quello che voi dovreste sapere (per voi, non per me di certo), è a dir poco limitativo. Per favore, non studiate sui lucidi.

L'unico esempio che si fa sulle slides è un unica pagina nel capitolo "procedure" che, senza la minima spiegazione, fa finta di spiegare come si comporta lo stack nel caso di chiamata ricorsiva.

Mi scuso se il mio tono è stato offensivo o iroso.
La mia reazione è stata smodata perchè ho letto che esempi riguardanti il famigerato esercizio 3 sono stati illustrati accuratamente in classe.
Io non posso seguire le lezioni, problema che, senza essere assolutamente sarcastico, è mio e non Suo.
Dunque non dovevo permettermi di infangare il Suo lavoro, essendo lei uno dei docenti più disponibili e competenti.
Ma a questo punto mi chiedo sempilcemente cosa io possa fare oltre che studiare sul libro di testo le sezioni scritte sul sito e sulle slides i riassunti delle lezioni.

Bè, intanto se hai dubbi postali pure, una mano non si nega a nessuno! Magari non saremo all'altezza del prof ma comunque possiamo almeno dirti quello fatto in classe

Più che altro ho notato, con mio stupore, che sul compito c'era qualcosa che non sapevo assolutamente fare... Non che fossi preparato da 30, ma almeno essere capace di svolgere sufficientemente un esercizio...
Dunque mi sono lasciato sfuggire qualcosa di sbagliato.

Quindi in sostanza tocca rompersi la testa sulle doppie ricorsioni.
Vabbè, basta saperlo... :|

Non ho ben capito cosa cambierebbe dalla singola ricorsione, voglio dire alla fine ogni volta che chiamate la funzione ricorsiva $ra viene salvata nello stack (se gli avete detto di farlo) di conseguenza nn mi sembra così complessa la gestione, dal momento che il salvataggio di $ra avviene ogni volta che chiamate la procedura (si può dire "in automatico".

La cosa è ben diversa invece.. Se la singola ricorsione è più facile che bere un bicchier d'acqua (il "flusso" è lineare e facilissimo da capire), la doppia ricorsione ha qualche elemento che non mi è chiaro. E il problema non è certo il salvataggio dei registri nello stack o queste procedure formali, ma proprio il suo "flusso" non so come spiegarmi, insomma per passare dal C++ al MIPS ho avuto dei problemi in questo caso.

Rinuncerò a capire e applicherò la struttura in blocco, così come viene presentata per tutte le doppie ricorsioni (con i dovuti aggiustamenti), che devo fa... :?

guarda motaro, per quel che ho notato io la doppia ricorsione è quasi uguale alla semplice. Cerco di spiegarmi con le differenze tra le due:

Singola
richiami la funzione, salvi $ra e le variabili nello stack, chiami la ricorsione e il risultato $v0 della chiamata ricorsiva lo gestisci per il risultato. Che ne so, fosse stato il fattoriale salvavi $ra ed N nello stack, chiamavi jal fact dopo aver fatto N=N-1 e poi richiamavi N dallo stack facendo qualcosa tipo $v0 = $v0*N dove il valore $v0 moltiplicato per N era il risultato della ricorsione.

L doppia è praticamente uguale: salvi $ra ed N nello stack ma allochi una parola in più, poi svolgi la prima ricorsione come fosse singola ed il risultato lo trovi quindi in $v0. Ora dovresti fare la seconda ricorsione, ma il risultato sovrascriverebbe quello che già hai in $v0, quindi prima della seconda ricorsione devi salvarti $v0 nello stack.
Una volta ricaricato N, modificato per la chiamata e chiamato la seconda ricorsione farai le operazioni necessarie: nel compito era 2*ricorsione1+3*ricorsione2 se non sbaglio. Richiami quindi dallo stack ricorsione1 e fai $v0=2*(valore richiamato) + 3*$v0 dove l'ultimo $v0 era della seconda ricorsione.

In pratica con la doppia ricorsione ti perdi il risultato in $v0 della prima e quindi te lo devi salvare nello stack, niente di più se già sai fare la singola vedrai che con un pò di allenamento è fattibilissimo