Menω principale
 Notizie
 Grafica
 Forum
 Links
 Retro Trailer
 Recensioni
 Modelli Amiga
 Storia Amiga
 Retro-Gamers
 Lista Utenti
 Contatti
 Policy sito
Ricerca Google

Login

Nick


Password


15 Gennaio 2020 Postato da: AMG_Novice_Usr
domanda sul parametro PURE del comando Resident
Sto studiando un po' di AmigaDOS, e mi sono imbattuto in queste righe:

Resident >NIL: C:Assign PURE
Resident >NIL: C:Execute PURE

Mi è chiaro a cosa serve il comando Resident, ma pur leggendo il seguente brano, tratto dal manuale di AmigaDOS 3.1,
non capisco cosa significa il parametro PURE:

Il brano, per me sibillino:

The PURE option forces RESIDENT to load commands which are not marked as
pure (i.e., they do not have their pure bit set), and can be used
experimentally to test the pureness of other commands and programs.

Inoltre, dato che ci siamo, vorrei avere delucidazioni anche sul fatto che in molti comandi dentro le startup-sequences si voglia
incanalare lo standard-output della Shell/CLI sul device NIL: … in sostanza si stampa nel nulla (si evita di stampare a video) cosa
esattamente? La risposta di AmigaDOS/OS al comando in questione? O cos'altro?

Grazie!
Commenti: 4  Aggiungi  - Leggi

Indice: forum / Richieste di Aiuto


AfAOne

Post inviati: 5752

Visulizza profilo Messaggio Personale
87.10.253.*** Mozilla/5.0 (Windows NT 6.1; rv:72.0) Gecko/20100101 Firefox/72.0
Commento 1
AfAOne 16 Gennaio 2020    01:12:49


Mi è chiaro a cosa serve il comando Resident, ma pur leggendo il seguente brano, tratto dal manuale di AmigaDOS 3.1,
non capisco cosa significa il parametro PURE:

Resident lo dice la parola, il comado va ad aggiungersi a quelli presenti nel KickStart, quindi puoi digitarlo senza scrivere il percorso e renerlo più veloce nell'esecuzione.

il Parametro PURE è uno flag di protezione bit che lo trovi spesso sui file di sistema o sulle librerie, questi file sono scritti in un certo modo, ti allego una citazione più chiara sul flag PURE:

Pure programs are written in a certain way that they use no local variables - everything is allocated off the stack. That way, the same command can be run multiple times in memory with only one copy of the command.

Anyway, all those resident programs are only used a few times during startup anyway, so the other alternative is simply to nuke all those resident commands. I doubt you'd notice any difference with your hard drive loading to be honest


Citazione

Inoltre, dato che ci siamo, vorrei avere delucidazioni anche sul fatto che in molti comandi dentro le startup-sequences si voglia
incanalare lo standard-output della Shell/CLI sul device NIL: … in sostanza si stampa nel nulla (si evita di stampare a video) cosa
esattamente?


NIL che puoi trovarlo davanti, dietro, si usa sui comandi in modo che qualsiasi errore o segnalazione del sistema venga ignorata.
Esempio se io nella Startup-sequence aggiungo un comando con nome sbagliato con il NIL la Startup- sequence non lo segnalerà a video e continuerà a proseguire l'esecuzione della Startup-sequence.

Capita pure dal Workbench quando esegui qualcosa ti esca una finestra che cita qualche parametro da usare o usato, informazione etc.. bene se tu esegui quella applicazione, gioco etc. da uno script con il NIL (sempre da Icona), nessuna finestra si aprirà e nessun messaggio sarà stampato a video.



Commento modificato il 16/01/2020 alle ore 10:20:48


Immagine AROS One x86/68k
- AfA One - AfA One PPC - Amilator AfA One - Amithlon AfA One - WinUAE OS 4.1


utente amiga quadratico medio

Post inviati: 701

Visulizza profilo Messaggio Personale
87.17.194.*** Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko
Commento 2
AMG_Novice_Usr 16 Gennaio 2020    17:38:11
Citazione

Resident lo dice la parola, il comado va ad aggiungersi a quelli presenti nel KickStart

Aspetta, provo a fare il pignolo per capire se sto capendo. Io avrei detto così: il comando reso "residente" dal comando "Resident" non va ad
aggiungersi a quelli presenti nel Kick, nel senso che non va dentro il Kick, non viene copiato da wb:c ed incollato nel kick, anche perché il Kick
è un FW che risiede in una ROM. Il comando viene incollato in ram. Facciamo un'esperimento.
Supponiamo che nella startup-sequence del mio Amiga NON rendo residente il comando Execute.
Per default, durante tutta la mia sessione di lavoro, ogni volta che sulla Shell/CLI io batto:
Execute <script1>
AmigaDOS, dopo aver interpretato "Execute", si precipita su SYS:C (sys: può essere df0: oppure dh0: … insomma … il device di massa da dove
il sistema ha bootstrappato il workbench), ed in quel drawer trova il comando/programma "Execute", quindi la CPU fa il fetching delle istruzioni
relative al comando "Execute", dunque il comando viene eseguito.
Se adesso, da Shell, batto nuovamente:
Execute <script2>
Tutto si ripete esattamente come prima.
Quindi se sappiamo di dover usare, nelle nostre sessioni di lavoro su Amiga, da Shell e/o sui nostri scripts, molto frequentemente un certo comando,
conviene che tale comando, nella startup-sequence, venga reso "residente", ovvero copiato da sys:c ed incollato in ram.
In questo modo abbiamo 2 aspetti, uno negativo ed uno molto positivo:
- negativo: riempimento della preziosa ram … quindi usiamo "Resident" solo per i comandi che sappiamo di usare spesso;
- positivo: ogni volta (e sono tante le volte) che usiamo un comando reso residente, AmigaDOS va a caricarselo non da sys:c presente su HDD o
peggio su floppy, bensì dalla ram, quindi un caricamento molto più veloce.

Citazione

quindi puoi digitarlo senza scrivere il percorso

Questa possibilità (molto comoda) non è conseguenza del fatto di aver reso il comando residente … il comando può anche non essere residente,
è sufficiente che sia dentro sys:c per poter essere invocato senza specificarne il percorso … giusto? (come avviene in Linux con i comandi presenti
nel direttorio /bin … ovunque tu sia nel filesystem, se un'app è lì, è sufficiente batterne il nome per lanciarla).

Citazione

they use no local variables - everything is allocated off the stack

Ok, quindi se un comando ha il suo status-bit PURE settato, vuol dire che questo programma usa solo variabili globali.

Citazione

the same command can be run multiple times in memory with only one copy of the command

Non riesco ad interpretare bene questa frase … io interpreto così:
"possono girare contemporaneamente più istanze di un comando di tipo PURE … ad esempio: il processo 1 può chiamare COPY (supponiamo che
COPY sia un programma/comando scritto in accordo con lo stile PURE), un altro processo 2 può anche lui chiamare COPY per i fatti suoi, stessa
cosa per altri N tasks … ciascun task usa COPY come se fosse l'unico task a girare."
Se COPY non fosse PURE, quindi usasse anche variabili locali (diciamo, solo variabili locali), mi starebbe bene, ma dato che COPY usa solo
variabili globali, e dato che non abbiamo MMU sugli Amiga storici, non c'è il pericolo che le varie istanze del programma COPY maneggino le stesse
variabili (globali), da cui il pericolo di perdita della congruenza dei dati (le varie istanze di COPY non si pestano i piedi fra di loro? Se ci fosse la
MMU il pericolo non c'è, ma dato che la MMU non l'abbiamo ...).




A500-Plus + A501 + switch meccanico per selezione Double-kickstart 1.3 v. 34.5 / 3.1 v. 40.63 /// A600, Rev. MB. 1.5, espansione in trap-door 1MB chip-ram, Kick-Cloanto 45.66, HDD interno a tracce da 2GB modello MK2104MAV by Toshiba su porta IDE: partizione DH1 con WB2.1 (default) + partizione DH2 con WB3.1 /// A500, Kick 1.3 v. 34.5, scheda espansione in trap-door da 512KB /// A600, espansione da 4MB-fast-ram innestata con zoccolo direttamente su 68K, Kick 2.05 v. 37.300, espansione di chip-ram in trap-door da 1MB, CF da 4GB su adattatore interno CF/IDE: partizione DH0 con CWB GAAE, partizione DH1 con WB2.1, partizione DH2 con WB1.3 /// A500, Rev. MB 6A, Kick 1.3 v. 34.5, A520-TV-RF-Modulator /// A500, PWR-LED ROSSO. Kick 1.2 v. 33.180 /// A500-Plus, PWR-LED ROSSO, Kick 2.04 v. 37.175, Driver DF1 esterno Savage DMF 322, A590 alimentato da alimentatore di CD32, con dentro espansione da 2MB di fast-ram + HDD SCSI Seagate ST32151N da 2GB - DH0 con WB 2.04 e DH1 con WB 1.2 /// A1200, 68EC020, Kick 3.0 v. 39.106, HDD a tracce Hitachi 40GB interno su porta IDE con installato CWB, espansione A1208 in trap-door da 8MB-fast-ram, PLipBox su porta parallela per collegamento via Ethernet a Internet /// Commodore 64 Assy NO. 250425 + floppy drive 5’’ 1/4 modello 1541

AfAOne

Post inviati: 5752

Visulizza profilo Messaggio Personale
79.13.255.*** Mozilla/5.0 (Windows NT 6.1; rv:72.0) Gecko/20100101 Firefox/72.0
Commento 3
AfAOne 16 Gennaio 2020    19:42:32
Citazione

Aspetta, provo a fare il pignolo per capire se sto capendo. Io avrei detto così: il comando reso "residente" dal comando "Resident" non va ad aggiungersi a quelli presenti nel Kick, nel senso che non va dentro il Kick, non viene copiato da wb:c ed incollato nel kick, anche perché il Kick è un FW che risiede in una ROM.

No in quel senso, intendevo dire che puoi usarlo come un comado Resident nel senso che puoi eseguirlo da qualsiasi percorso tu ti trovi senza dare il percoso dove questo comando è posizionato.

Citazione

Il comando viene incollato in ram. Facciamo un'esperimento.
Supponiamo che nella startup-sequence del mio Amiga NON rendo residente il comando Execute.
Per default, durante tutta la mia sessione di lavoro, ogni volta che sulla Shell/CLI io batto:
Execute <script1> AmigaDOS, dopo aver interpretato "Execute", si precipita su SYS:C (sys: può essere df0: oppure dh0: … insomma … Quindi se sappiamo di dover usare, nelle nostre sessioni di lavoro su Amiga, da Shell e/o sui nostri scripts, molto frequentemente un certo comando, conviene che tale comando, nella startup-sequence, venga reso "residente", ovvero copiato da sys:c ed incollato in ram.


Attenzione non il comando Resident lo si usa solo per alcuni Comandi, magari quelli che fisicamente non entravano nel KickStart.

Il discorso Execute o altri comandi che tu digiti e si avviano anche senza dare il percorso (succede solo negli OS ben configurati) è dato da un'altro comando che si chiama PATH.

Nella Startup Sequence troverai per esempio:

Path >NIL: RAM: C: SYS:Utilities SYS:Rexxc SYS:System S: SYS:ρrefs SYS:WBStartup SYS:Tools

Questo significa che tutto ciò che si trova in queste cartelle (no sottocartelle) potrai eseguirlo senza indicare il percorso e da qualsiasi posizione ti trovi.


Citazione

Non riesco ad interpretare bene questa frase … io interpreto così: "possono girare contemporaneamente più istanze di un comando di tipo PURE …
ad esempio: il processo 1 può chiamare COPY (supponiamo che COPY sia un programma/comando scritto in accordo con lo stile PURE), un altro processo 2 può anche lui chiamare COPY per i fatti suoi, stessa cosa per altri N tasks


Qui non ho capito bene anche se non mi sono mai addentrato in questo argomento, magari con un esempio pratico ci ariivo senza problemi.

Riguardo la MMU anche se sugli Amiga base non esisteva su WinUAE puoi settarla su tutte le configurazioni dove nell'Amiga Reale era possibile avere.

Commento modificato il 16/01/2020 alle ore 21:48:35


Immagine AROS One x86/68k
- AfA One - AfA One PPC - Amilator AfA One - Amithlon AfA One - WinUAE OS 4.1


AfAOne

Post inviati: 5752

Visulizza profilo Messaggio Personale
79.13.255.*** Mozilla/5.0 (Windows NT 6.1; rv:72.0) Gecko/20100101 Firefox/72.0
Commento 4
AfAOne 16 Gennaio 2020    22:23:23
Visto gli argomenti interessanti trattati sto allegando i link dei tuoi post QUI nel thread "Applicazioni, Comandi e Scorciatoie", post interessante dove potrai trovare altre informazioni interessanti per te su Amiga OS. Per altre tue richieste su Comandi e amigaOS meglio discutere in quel post in modo da tenere insieme i vari argomenti per chi ne avrà bisogno in futuro.

Commento modificato il 17/01/2020 alle ore 15:19:59


Immagine AROS One x86/68k
- AfA One - AfA One PPC - Amilator AfA One - Amithlon AfA One - WinUAE OS 4.1



Utenti Online
Utenti registrati: 1206 dal 1 Gennaio 2006
di cui online: 0 registrati - 
144 non registrati

Benvenuto all'ultimo utente registrato: zulu

Buon Compleanno a frank62 - Kosmokrator - 

© Amigapage 1998 - 2007 - Sito italiano dedicato alla piattaforma Amiga ed evoluzioni varie.
Struttura del sito interamente ideata e realizzata da Marco Lovera e Alessandra Lovera - Tutto il materiale inserito all'interno del sito θ dei rispettivi autori/creatori.
E' assolutamente vietata la riproduzione o la manipolazione di tutti i contenuti o parte di essi senza l'esplicito consenso degli amministratori e degli autori/creatori.

Eseguito in 0.1820969581604 secondi