Compilatori 2005

• ++
• --
• switch
• case
• default

• post-incremento
• post-decremento
• switch

• se si stanno aggiungendo token al linguaggio, occorre dichiararli nella tabella terminal
• se si aggiungono non terminali alla grammatica, tali non terminali vanno dichiarati nella tabella per i non terminal
• si usi {: RESULT = null; :} come azione semantica delle nuove produzioni che si aggiungono alla grammatica, tranne se le si aggiungono ai comandi, per cui si usi {: RESULT = new Skip(0); :}

Lezione 7 (9 febbraio 2005)

• il caso dell'if/then/else
• il caso delle espressioni aritmetiche

• post-incremento
• post-decremento
• switch

Date a queste classi un metodo fittizio:

public Bytecode translate() { return null; }

dove Bytecode sta per Bytecode.Bytecode.

Scrivete delle azioni semantiche sotto le produzioni di sintassi concreta inserite nel laboratorio precedente dentro al file Syntactical/Kitten.cup, e dichiarate il tipo di ritorno di eventuali nuovi non terminali che sono stati introdotti. Infine compilate con make syntactical.

Compilando i file di esempio del laboratorio precedente, si dovrebbero generare dei file .dot che, una volta trasformati in postscript, visualizzano anche le nuove classi di sintassi astratta.

Lezione 9 (16 febbraio 2005)

• il predicato blocked sui comandi
• il predicato breaks sui comandi

• post-incremento
• post-decremento
• switch

• Aggiungete un metodo

  public void loadClasses(TypeChecker checker) throws Exception

  a tutte le classi di sintassi astratta che avete aggiunto a Kitten. Tale metodo è usato dalla fase 1 del type-checking per fare il buildType di tutte le classi citate in un pezzo di codice. In pratica, dovrete semplicemente richiamarlo ricorsivamente sui componenti della vostra sintassi astratta. Guardate è fatto, per esempio, dentro Absyn/IfThenElse.java.

• Scrivete delle regole di controllo dei tipi per le nuove classi di sintassi astratta che avete aggiunto a Kitten. Si permetta a post-incremento e post-decremento di lavorare soltanto su interi. Si noti che invece non è obbligatorio che il selettore di uno switch sia un intero, ma che deve esistere una qualche relazione fra il selettore e le condizioni inserite per ciascun case. Per esempio, se il selettore è un intero allora nessuna condizione di un case può essere uno Studente. Questo è un esempio, trovate una regola generale!

• Aggiungete un metodo

  public Types.Type typeCheck(TypeChecker checker)

  alle classi di sintassi astratta che avete aggiunto per nuove espressioni e nuovi comandi. Tale metodo è usato nella fase 2 del type-checking per implementare le regole di controllo dei tipi identificate sopra per tali classi astratte. Si ricorda che questo metodo per i comandi deve sempre terminare con

  return super.typeCheck(checker);

  mentre per le espressioni deve sempre terminare con

  return storeStaticType(...);

• A questo punto dovreste già essere capaci di compilare Kitten (make semantical) e compilare gli esempi Switch1.kit, Switch2.kit, Switch3.kit e Cifra2.kit senza alcun errore se non quelli relativi alla posizione del break. Risolveremo questo problema nel prossimo laboratorio.

• operazioni sullo stack
• operazioni sugli oggetti
• operazioni sugli array

Modifica del type-checking in modo da permettere ai break di comparire nel corpo dei case.

• Aggiungete una nuova modalità a Semantical/TypeChecker.java, cioè un suo ulteriore campo:

  public boolean _case;

• Estendete i costruttori di Semantical/TypeChecker.java in modo da considerare anche questo campo.
• I metodi di clonaggio cloneForParser, cloneIntoReader, cloneIntoWriter e cloneIntoLoop, che vengono usati per cambiare parser o modalità, devono copiare questo campo.
• Aggiungete un metodo cloneIntoCase che crea e restituisce un type-checker identico a this ma in modalità _case.
• Modificate il metodo typeCheck che avete scritto per lo switch in modo da fare il type-checking dei case in modalità _case.
• Modificate il metodo typeCheck di Absyn/Break.java in modo da rendere leciti i break che occorrono dentro il case di uno switch.
• Eseguite make semantical. La compilazione di Switch1.kit, Switch2.kit, Switch3.kit e Cifra2.kit deve avvenire senza la segnalazione di alcun errore.

Lezione 13 (4 marzo 2005)

• post-incremento di variabile
• post-decremento di variabile

Suggerimento:

• Definite dentro Absyn/Lvalue.java due metodi:

  public abstract Bytecode translateForPostIncrementAsInteger()

  public abstract Bytecode translateForPostDecrementAsInteger()

  e instanziateli dentro le due sottoclassi Absyn/FieldAccess.java e Absyn/ArrayAccess.java in modo da ritornare un bytecode che calcola, per esempio, sempre la costante 0.

• Instanziate tali metodi anche dentro Absyn/Variable.java, ma questa volta dovete fargli ritornare un bytecode che fa il post-incremento o il post-decremento della variabile, oltre a lasciare sullo stack il valore originale della variabile, cioè quello che essa aveva prima della modifica. Dovreste riuscire a scrivere tutto usando i soli bytecode che abbiamo descritto a lezione. Non usate variabili locali per memorizzare risultati temporanei perché non sapete quali di esse sono libere e quali utilizzate nel metodo in cui l'espressione occorre
• Aggiungete alle classi di sintassi astratta che avete definito per post-incremento e post-decremento il metodo translate, che chiamerà uno dei due metodi visti sopra per generare il codice che incrementa o decrementa il leftvalue, rispettivamente
• Compilate Kitten con make translate
• Dovreste a questo punto essere capaci di compilare Post.kit e ottenere il diagramma del bytecode generato dentro Post.main() [void].dot. Traducetelo in postscript e visualizzatelo
• Se quello che vedete vi sembra sensato, ricompilate Kitten con make jbgeneration
• Ricompilate Post.kit, ottenendo un file Post.class che, una volta eseguito, dovrebbe stampare i numeri da uno a cento

Continuate il lavoro dei laboratori:

• Realizzate la generazione del codice intermedio per post-incremento e post-decremento di tutti e tre i casi dei leftvalue, visti sia come espressioni che come comandi. Se vi servissero bytecode non visti a lezione, definiteli come sottoclassi di Bytecode/Bytecode.java, instanziando in tali nuove sottoclassi il metodo JBGenerate che li traduce in Java bytecode
• Attenzione perché una Absyn/Variable.java rappresenta sia una variabile che un leftvalue del tipo this.id dove this è sottointeso. Dovete distinguere i due casi nella generazione del codice intermedio
• Realizzate la generazione del codice intermedio per lo switch. I bytecode visti a lezione dovrebbero essere sufficienti ai vostri scopi. Il default deve venire eseguito solo se nessuno dei case è stato eseguito.
• Ricordatevi che un break dentro ai case deve fare uscire dallo switch, altrimenti si esegue il case successivo
• I leftvalue di post-incremento e post-decremento, nonché le espressioni dello switch devono essere valutate esattamente una volta, mai piú volte!

Un bonus di ben tre punti verrà accordato al gruppo che consegnerà entro la mezzanotte del 3 aprile un progetto che compila correttamente il file Gara.kit generando un file Gara.class più piccolo di quello dei concorrenti. A parità di dimensione, vince chi ha consegnato prima.