Discussione interessantissima, in gran parte OT (ma non limitiamoci a tali inpalcaturizzazioni sterili/rigide), dove noi inesperti possiamo imparare molto.
Mi sono segnato alcuni punti da commentare brevemente.
Inizio con i primi, i prossimi li commenterò in un secondo momento, adesso non riesco a snocciolarli tutti.
Quando accendi un Amiga fisico, la prima cosa che fa è quella di avviare il Kickstart
Detto più precisamente:
appena do potenza, il 68K copia il FW/bios/OS "Kickstart" dal chip di ROM fisico alla chip-RAM, ad esempio nel caso del kick 2.x, la CPU 68K esegue (fetch/decode/execute) le primissime istruzioni della ROM kick2.x, e l'esecuzione di queste prime righe di FW determinano il copiaggio dei 512KB di kick2.x (o una grande parte di questi ... come stanno le cose? viene copiato tutto il kick, oppure una parte di questo? a me risulta quasi tutto, non tutto ... fra un attimo dico il perchè*) dalla ROM alla chip-ram.
Alla fine di questa copia, il 68K esegue effettivamente il FW del kick2.x, e lo esegue in chip-ram, dove ha appena finito di posizionarlo.
La prima fase di questa esecuzione prevede il POST, quindi test/diagnostica di tutto l'HW noto, con eventuale segnaletica visiva a colori sul monitor, e se il post viene tutto superato, e se il kick non trova i due bottoni nel mouse premuti, quindi se il kick non è forzato ad allupparsi dentro il boot-manager "Amiga Early Startup Control", allora il kick2.x cerca il primo volume bootable da cui tentare un avvio.
*Nota:
con kick3.2, se faccio bootstrap su partizione UDH1/CF priva di OS, vuota diciamo, con PFS3AIO, e da conseguente prompt batto:
AVAIL (tale comando è interno, evidentemente)
la shell mi restituisce su monitor che attualmente sono occupati 480 mila e spiccioli bytes di chip-ram, su 2MB di A600 totali, quindi il kick3.2 non è stato, sembrerebbe, tutto copiato da ROM a RAM, bensì quasi tutto, oppure il chip di ROM fisico ha una capienza di 512KB, ma il FW kick3.2 è di 480mila e spiccioli bytes di dimensione, non lo so ...
Exec gestisce i processi
Esatto, il microkernel, che di fatto coincide con lo schedulatore dei processi.
Alcuni comandi sono stati resi interni (cioè "copiati" nella ROM del Kickstart)
perchè il loro utilizzo era molto frequente, tra questi c'è anche CD.
A prescindere da dove un comando è localizzato, ovvero da dove si trova fisicamente, se su un file in Sys: C, oppure se è un pezzetto di binario interno al FW/bios/OS "Kickstart", scritto nella ROM fisica sul PCB dell'Amiga, se si prevede che tale comando sarà usato spesso dal sistema, bisognerebbe renderlo residente, ossia residente in RAM (es: in chip-ram), quindi all'avvio abbiamo bisogno che il comando sia copiato dalla sua posizione di storaging (file su Sys: C, oppure interno al kick) ed incollato in ram, e tale comando (che è un programma) dovrà rimanere in ram, a disposizione, senza mai che la porzione di ram per lui allocata dall'OS venga disallocata (nè la ram per lui allocata, nè il suo stack: il suo contesto deve essere tutto preservato, fintanto che Amiga è acceso): il comando deve rimanere sempre a disposizione in ram, poichè verrà chiamato spesso.
Che poi tale comando sia stato prelevato da file su floppy WB, piuttosto che da kick-ROM, piuttosto che da file su CF/IDE-44 ecc ... poco importa: ormai si trova in ram, lì rimane, a disposizione, quindi ogni esecuzione dello stesso sarà molto veloce.
Il fatto che si possa digitare il nome di una directory senza specificare CD è una
caratteristica combinata del funzionamento della shell e del fatto che CD sia un comando interno.
Sono d'accordo.
La shell potrebbe avere una sorta di CD "builtin", come accade per cmd.exe, anche se lì la dicitura "cd" deve essere battuta (cmd.exe è la versione nuova, da WinNT in poi, credo almeno, di command.com), oppure come accade per la bash-shell (anche lì la dicitura "cd" deve essere battuta) delle ultime distribuzioni di Ubuntu/Lubuntu ecc ... , dove appunto CD non è più un comando su file presente in:
/bin
ma è appunto "builtin" dentro shell-bash, per motivi di ottimizzazione.
Oppure CD non è builtin in shell/cli di Amiga 2.x e superiori, ma semplicemente la shell, quando accediamo ad un nuovo path/drawer, anche senza battere CD, la shell riconosce la situazione ed è lei ad invocare il comando CD che era interno al kick2.x, e che ora si trova residente in chip-ram, residente come quasi tutto il FW del kick2.x