Risposta Stile Testo Dimensione:  10 12 14 16 18 20 24 30 Colore:  Rosso Viola Verde Blu Giallo Grigio Arancio Rosa Allinea:  Centrato Giustificato Linea vuota A capo Altri comandi Emoticons Clicca per riportare il codice nell'area di testo oppure posizionati su un'immagine per vederne il relativo comando. Testo In risposta a AMG_Novice_Usr [quote=AMG_Novice_Usr] [quote] Resident lo dice la parola, il comado va ad aggiungersi a quelli presenti nel KickStart [/quote] 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. [quote] quindi puoi digitarlo senza scrivere il percorso [/quote] 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). [quote] they use no local variables - everything is allocated off the stack [/quote] Ok, quindi se un comando ha il suo status-bit PURE settato, vuol dire che questo programma usa solo variabili globali. [quote] the same command can be run multiple times in memory with only one copy of the command [/quote] 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 ...). [/quote] formattazione A sinistra Giustificata Nessuna

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

utente amiga quadratico medio Post inviati: 701	Commento 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