Changes between Version 2 and Version 3 of doc/Memorandum

Timestamp:

May 23, 2006, 9:33:55 AM (19 years ago)

Author:

soujak

Comment:

--

doc/Memorandum

@@ -1 @@
-Di seguito un passo di un post di Morsiani chiarificatore sull'interval 
+= Memorandum =
+== [interrupt.c] ==
+L'identificazione della linea interessata all'interrupt viene fatta direttamente sul registro Cause.IP, mentre la selezione dello specifico device verra' realizzata ciclando la macro INTRDEVICE(x,y) sullo specifico tipo di dispositivo x, e scorrendo sulle di cui istanze (y). Gli interrupt verranno gestiti uno alla volta secondo la priorita' specifica della linea, al termine di una chiamata quindi, quando essi verranno ri-abilitati, la ROM si accorgera' di altre linee di interrupt asserite e ci ripassera' la palla. La priorita' e' in sostanza gia' stata assegnata del numero di linea: dalla minore alla maggiore (i terminali possiedono due semafori e quindi per loro prima scrittura su e poi lettura da).
+
+Quanto al clock, l'interval timer genera interrupt nella transizione 0x0000.0000 -> 0xFFFF.FFFF, quindi utilizzando questo fatto, il giusto settaggio dell'interval timer alla schedulazione di un processo permettera' l'esecuzione durante un solo quanto di tempo: settando, ad esempio 0x0000.0400 il processo avra' a disposizione 0x400 cicli di clock. Tenendo presente il time scale, il quanto di tempo avra` dimensioni temporali calcolabili anche in cicli. [[BR]]
+Anche per questo dipositivo manterremo un semaforo, che indichera' uno pseudo-clock, e sul quale si addormenteranno i processi che richiedano una SYS7 (WAIT4DEV), sul quale verra' fatta una V periodicamente dopo un certo prefissato numero di veri cicli. Di seguito un passo di un post di Morsiani chiarificatore sull'interval 
 timer di cui tenere conto anche durante la fase di inizializzazione in
 initial.c:
+   Il timer e' un contatore all'indietro che non si ferma mai: conta da p.es. 0x1000 (valore caricato) a 0, poi
+   0xFFFFFFFF (-1, ma anche 2^32-1^) generando un interrupt nella transizione. A ogni context switch lo scheduler,
+   fra le altre cose, deve settare il timer per dare un "tot" di tempo di CPU al processo che carica.
 
-{{{
-Il timer e' un contatore all'indietro che non si ferma mai: conta da p.es. 
-0x1000 (valore caricato) a 0, poi 0xFFFFFFFF (-1, ma anche 2^32-1^) 
-generando un interrupt nella transizione. 
-A ogni context switch lo scheduler, fra le altre cose, deve settare il 
-timer per dare un "tot" di tempo di CPU al processo che carica.
-}}}
+La vera e propria gestione degli interrupt dei dispositivi e' nostro appannaggio, e cio' che dovremo fare e':
+ * segnalare l'<ack> al dispositivo, ricordando che l'invio di un comando svolge la medesima funzione e che vale lo stesso per il caricamento di un nuovo valore nel caso del IntervalTimer
+ * fare la SYS3 (VERHOGEN) sul semaforo associato al dispositivo svegliando uno dei processi che aveva effetuato una SYS8 (WAIT4IO)
+