[zxspectrum] Re: Linux per ZX
- From: Alfonso Martone <a.martone@xxxxxxxxxxx>
- To: zxspectrum@xxxxxxxxxxxxx
- Date: Mon, 27 Sep 2004 13:05:05 +0200
> che ne dici di implementare l'UZIX sul 128k? :-)
L'impresa sarebbe leggermente TITANICA :-)
Ti spiego (sperando di non essere troppo complicato) perche' io credo
piu' alla riscrittura ex novo dell'intero sistema (riciclando magari
qualche pezzetto di UZIX) piuttosto che ad un improbabile "porting"...
A occhio e croce, sullo Spectrum 128 classico si potrebbe avere uno UZX
(senza la "i") nel quale:
- il bank 5 e il bank 2 sono riservati al kernel e al video (quindi il
kernel sarebbe da comprimere in non piu' di 24k-25k, cioe' codice,
dati e kernel-stack), che occuperanno l'area RAM da $4000 a $bfff;
- l'ultimo bank (da $c000 in poi) e' riservato ai task che potranno
girare contemporaneamente - fino a sei task da circa 16k l'uno (dove
devono essere compresi codice, dati e task stack), ossia i task
staranno comodi comodi nei bank 0,1,3,4,6,7 (se vogliamo usare il
bank7 come secondo schermo, il kernel guadagnerebbe qualche kbyte in
piu', ma il numero massimo di task contemporanei sara' ridotto a 5...)
- il meccanismo della fork() funzionerebbe benissimo :-) ...purche' al
momento della chiamata ci sia ancora una pagina 16k libera (certamente
qualcuno si allenera' ad implementare un meccanismo di paging su disco
e quindi il numero di task totali potrebbe salire vertiginosamente);
dato che tutti i programmi sarebbero compilati per cominciare da
$c000, non ci saranno problemi di "rilocazione" e affini (il paging
supplisce egregiamente, con la sola limitazione dell'area di grandezza
fissa per ogni task);
- ogni task non ha esattamente "16k" perche' per avere un interrupt in
IM2 in "zona kernel" bisognerebbe usare 257-512 bytes in fondo alla
RAM, che i task in questione non dovrebbero azzardarsi a toccare :-(
se qualcuno ha una soluzione alternativa si faccia avanti: ogni sistema
multitasking deve periodicamente reagire a un interrupt per assegnare
a chi gli pare la prossima time-slice...
- non c'e' modo di avere task da 32k a causa della presenza della ROM
(che ti toglie 16k utili dei 64k di indirizzamento) e comunque ci
sarebbe spazio solo per 3 task (gia' siamo troppo stretti con sei!!),
quindi l'ipotesi non vale la pena di prenderla in considerazione.
Fra parentesi, non penso che sfruttare i modi extra del +2/+3 possa
aggiungere qualcosa di utile alle funzionalita' sopra citate... con
una sola eccezione: se si ha "tutta RAM" si puo' piazzare il kernel
nella prima pagina e usare le istruzioni RST dello Z80 per le chiamate
piu' comuni, risparmiando un non piccolissimo numero di bytes nei task
e nel kernel (ed eliminando la necessita' di avere la tabella per
l'IM2 in fondo alla RAM).
Ora cominciano i guai: avere uno stack tcp/ip non serve a molto se la
seriale dev'essere pilotata "a polling" e non hai altra interfaccia di
rete su cui mandare pacchetti... :-(
Di piu': a causa della paginazione e della ROM siamo costretti in 16k
ad avere tutto (programma, dati, e buffers), quindi i programmi che
allocano parecchia memoria non gireranno (se il piu' banale dei
programmini pretende di allocare 15k di buffers e' probabile che
inceppera' l'intero sistema o fallira' miseramente il suo compito...
e' ovvio che con 32k - come nel caso UZIX - c'e' piu' speranza di far
girare qualcosa; Unix vive piu' o meno col presupposto che c'e' un
mucchio di memoria che ti aspetta li' tutta allocabile e paginabile).
Inutile precisare che non ci gireranno gcc o roba simile :-)
Piccolo vantaggio: nel caso di referencing su null-pointer, i task si
troveranno a tentar di scrivere sulla ROM, e quindi il sistema non si
piantera' :-)
Quante piu' funzioni "di libreria" si riescono a mettere nel kernel,
meglio sara' (cosi' non ci sara' bisogno di avere in ogni task una
copia delle funzioni "malloc", "free", "printf", etc).
Nel caso del Chrome la faccenda diventa piu' simpatica perche' si puo'
"sbancare" la ROM e riciclare quel po' di RAM in piu', per cui il
kernel avrebbe 48k totali di RAM sua (compreso il bonus delle RST, ed
eventualmente compreso lo schermo), potendo usare l'interrupt senza
dover chiedere l'IM2, e contenendo una corposa serie di funzioni di
libreria... o forse si potrebbe pensare addirittura ai task da 32k...
chissa'... :-)
Ultima considerazione: il tutto girerebbe sullo Spectrum 48k senza
modifiche... con l'unica limitazione di avere un solo task (bella
questa: multitasking, ma con un solo task). Con lo Spectrum espanso a
80k ci girerebbero due task da 32k (ma con kernel ridotto a 8-9k)
oppure due task da 16k (ma con "kernellone" paginato di 48k compresa
l'area video).
--
alf
Other related posts:
