Newsgroup: it.comp.os.amiga
Titolo: Memoria protetta

Leggendo (non troppo approfonditamente per la verità) i vari docs su 
AmigaOS e MorphOS, ho notato una cosa: AmigaOS non ha la memoria 
protetta mentre MorphOS si?
Inoltre, verrà, prossimamente, implementata la memoria protetta anche in 
AmigaOS?
La sua mancanza al mmento cosa comporta?
Grazie
-- 
Marco Iannaccone
FAKEci...@katamail.com
(togliere 'FAKE' dall'indirizzo - remove 'FAKE' from the address)

La sua mancanza al mmento cosa comporta?
"La memoria protetta serve al sistema operativo per bloccare una
applicazione che è "impazzita" prima che possa danneggiare tutte le
altre aperte"
da:
http://www.accomazzi.net/TfaqI1104.html
aggiungo ancora questo parte di testo interessante e poi dico la mia
opinione:
"AmigaOS e' piuttosto peculiare nel suo design. Si discosta
notevolmente
dagli OS tipici per il suo sistema di comunicazione tra processi
(IPC),
il suo sistema di librerie condivise, i device, il sottosistema BOOPSI
e cosi' via. I vantaggi e gli svantaggi di queste scelte sono tuttora
argomento di discussione tra i programmatori Amiga. AmigaOS si puo'
considerare un sistema operativo real-time, anche se probabilmente il
termine
e' stato coniato a qualche anno di distanza dall'introduzione di
Amiga.
Exec, il microkernel di Amiga, fu progettato per consentire un
efficiente
scambio di messaggi tra i processi, che e' poi stato usato con
saggezza un
po' ovunque nel resto sistema operativo. Questo e' il segreto alla
base
della ben nota efficienza di AmigaOS. Purtroppo un'architettura di
questo
tipo rende quasi impossibile l'introduzione della memoria protetta ed
ostacola non poco la creazione di un sistema di memoria virtuale.
Sono caratteristiche molto comuni in tutti i sistemi operativi moderni
ed
e' per questo che gli utenti Amiga ne sentono cosi' tanto il bisogno.
La questione si potrebbe anche vedere da un punto di vista opposto: a
causa
della memoria protetta e paginata, gli altri sistemi non possono
raggiungere
facilmente le prestazioni real-time di AmigaOS."
da:
http://www.codewiz.org/articles/ear_qnx.txt
per leggere qualcosa di interessante e mostruoso...e 
con con razza di gente abbiamo/avete a che fare:
http://www.diff.org/diff/sette/amigaos4.shtml
e sopratutto nell'intervista leggete la domanda e riposta riguardante
un macchina che di Amiga ha solo il nome.

 un macchina che di Amiga ha solo il nome.
A parte che l'intervista è uscita nel 2001 o primi mesi del 2002. Cmq non
ci vedo nulla di speciale o di scandaloso, soprattutto le parole di Olaf
sono sempre esaurienti.....
ShInKurO
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 La sua mancanza al mmento cosa comporta?
Un programma che utilizza in OS4 e in MOS le vecchie API, se scritto male,
potrà accidentalmente accedere in scrittura a porzioni della memoria
assegnate ad altri programmi, arrivando a causare anche blocchi del
sistema.


sono sempre esaurienti.....
hai ragione, rettifico..cosa pensavano di amiga...:)

merito ;-D)
Quindi c'è una seria possibilità che AmigaOS4 con la memoria protetta
possa perdere una delle qualità che hanno reso unico AmigaOS3.x:
"a
causa
della memoria protetta e paginata, gli altri sistemi non possono
raggiungere
facilmente le prestazioni real-time di AmigaOS."
Quindi se in futuro ci saranno problemi con le applicazioni a chi si
darà la colpa di tutto?
In passatto era consuedine dei programmatori dare la colpa
all'hardware quando un programma crashava, era lento, non funzionava
bene.
MAI era colpa loro, loro così  bravi da usare codice pulito (codice
automodificanti, codici specifici per processore che non stavano nella
cache di quel processore e quindi crash e rallentamenti paurosi).
Ripeto le parole di molti illustri programmatori e tecnici del
settore:
"La colpa + dell'hardware, vecchio, datato, lento, dell'AGA, dello
Zorro2, dello Zorro3, del content-switch".
Aspetto con ansia quando ci saranno probleme e se ci saranno con la
memoria protetta semmai sarà implementata.
Non è una mia opinione questa, sono le opinioni di chi programmava su
Amiga qualche anno fa, anche Note software House.
Anche questo fa parte della storia di Amiga, ma che tanti fanno finta
di non ricordare. :-|

 di non ricordare. :-|
Il punto č che non tutti hanno la stessa opinione, io tendo a riportare i
fatti in modo piů imparziale possibile, ma ci son delle cose che vanno
dette e cose che per quanto discordanti siano (come i pareri che tu hai
citato) non ricordo, mica č facile ricordarsi tutti i pareri discordanti:-)


 altre aperte"
So cosa comporta e a cosa serve la memoria protetta.
Mi chiedevo cosa comportava nello specifico nell'Amiga (tipo appunto 
impossibilità di fare quello che hai detto dopo, e magari non 
compatibilità col passato, etc...)


 sistema.
Da quanto ho capito al momento nono sono protette, per quanto riguarda 
la memoria degli altri programmi, le porzioni di dati, non quelle del 
codice, e inoltre anche la porzione di memoria del kernel è già 
protetta, o no?


 protetta. 
 Pero' si parte dalla supposizione che ad un certo punto si possa perdere
*completamente* la compatibilita' con AOS3.x: ed e' un'assunzione forte.
Perche' 3/4 (purtroppo sono anche di piu', mi tengo stretto) dei programmi
che io uso non sono piu' attivamente sviluppati. Perche' comunque i
programmi 68k 3.x non scompariranno, visto che sono l'unico modo per
garantire il supporto a Amiga classic, UAE/Amiga Forever, Amithlon, MOS e
AOS4, e, mediante semplice ricompilazione senza modificare il sorgente,
AROS. Basta vedere le uscite di questi giorni. Per avere una piena memoria
protetta bisognerebbe anche riscrivere parte del codice e ricompilare ogni
singolo programma appositamente per AOS4. Tenendo presente che almeno
meta' della comunita' (e anche qui sono stretto) sviluppa su uno qualsiasi
degli altri sistemi - sia classic che UAE che Amithlon o MOS. In parole
povere la ritengo un'"utopia".
 Per quanto riguarda MOS ti sei dimenticato di spiegare il discorso delle
sandbox, che e' stato l'approccio adottato anche da Apple. L'ABox e' una
scatola all'interno della quale non c'e' vera MP - ce n'e' una forma
simile a quella attualmente implementata in AOS4. E all'interno della
quale girano i programmi 68k, WUP, PUP e, attualmente, MOS. La transizione
da una scatola all'altra puo' essere lenta e graduale, e non dovrebbe mai
comportare un taglio netto, una cesura, la sostanziale perdita di
retrocompatibilita'. L'ABox potra' continuare ad esistere per sempre,
garantendo il funzionamento di applicazioni, vecchie e nuove, di tipo
"legacy".
 Nessun timore che la QBox sia una bestia strana: gli sviluppatori di MOS
sono amighisti dagli anni '80, MOS continuera' a sembrare in tutto e per
tutto *un* AmigaOS - non e' che la fratellanza debba limitarsi all'ABox
per qualche strano motivo. Per quanto riguarda lo sviluppo, ho sentito
dire che gia' con la 1.5 diversi driver e librerie siano stati spostati
nella QBox, ma sono solo voci non verificate, e sulle quali non farei
nemmeno particolarmente affidamento. Anche perche' c'e' un sacco di altro
lavoro da fare...
                          Saluti,
                                Andrea


 protetta, o no?
Sia AmigaOS4 che MorphOS1.4+ forniscono questa caratteristica.


 quantomeno seguiti....
Quindi, insomma.. hanno promesso che introdurranno questa cosa.


 libreria ISO C?
Ehmm questo non lo so, FabioooAlemagnaaaa!?:-)
Dovrebbe succedere quello che succede su tutti gli altri sistemi, il C e
C++ sono standard ANSI...


 libreria ISO C?
Be', non ho idea di cosa succeda nella specifica implementazione della 
libc per AmigaOS4, però se consideri che gli standard ISOC e POSIX 
partono dall'assunto che la memoria sia non condivisa tra i processi, ha 
senso, nel caso fosse possibile, fare in modo che malloc e compagnia 
ritornino puntatori a memoria privata e non condivisa. Però, questo 
sarebbe fattibile solo nel caso in cui il programma in questione *non* 
facesse uso anche di API di AmigaOS, in quanto in quel caso è 
plausibile, e spesso succede, che la memoria ritornata da malloc e 
compagnia venga usata per cose che hanno a che vedere con AmigaOS 
stesso, e non con l'API POSIX.
Fabio Alemagna

 C++ sono standard ANSI...
Per essere precisi, ormai la denominazione corretta è ISO (International 
  Standards Organization), non ANSI (American nonsocosa Standard 
Immagino_institution).
Il C è stato inizialmente approvato dall'ANSI, ma poi è diventato uno 
standard non solo americano ma internazionale, venendo approvato 
dall'ISO, ed è l'ISO che continua a tenerene aggiornate (pubblicandole 
purtroppo a pagamento) le specifiche.
gcc segue questi sviluppi.


 gcc segue questi sviluppi.
Grazie per l'informazione, capita giusto a puntino con la materia che sto
studiando per ora :ingegneria del software ;-)


 stesso, e non con l'API POSIX.
Insomma non è chiaro se chi ha scritto l'implementazione delle funzioni 
malloc() e calloc() per AmigaOS lo ha fatto facendo si che, quando viene 
chiamata la system call di AmigaOS per allocare memoria, gli viene 
passato il flag per ottenere memoria condivisa o quello per ottenere 
memoria esclusiva, giusto?
In pratica... che flag si dovrebbe usare per far si che la memoria 
allocata non venga condivisa tra trask, insomma in modo che il 
comportamento sia quello di un normale sistema con memoria protetta?
Diciamo che voglio allocare memoria facendo si che non venga resa 
accessibile a nessun altro task, che flag devo passare?
Inoltre, quando chiedo di allocare memoria, viene sempre allocata NUOVA 
memoria, ovvero non utilizzata, indipendentemente da come altri task 
possono averla allocata. L'unico modo per accedere alla memoria allocata 
per altri task è mediante accesso diretto all'indirizzo, no?
Se richiedo allocazione di memoria, so che quella che mi viene 
restituita non è stata allocata anche per altri processi, no?


 restituita non è stata allocata anche per altri processi, no?
Be', certo...
Fabio Alemagna

 studiando per ora :ingegneria del software ;-)
Trattate questi argomenti di ingegneria del software?
Quando l'ho dato io si studiava progettazione orientata agli oggetti, 
UML, progettazione viewpoint oriented, modelli si sviluppo e testing del 
software, cose insomma.. più che altro teporiche o comunque non legate a 
un linguaggio di programmazione in particolare.


 Be', certo...
Lo so che può apparire come una domanda molto scema e con risposta 
ovvia, ma... essendomi trovato a lavorare solo con sistemi a memoria 
protetta a tutti gli efetti, o con sistemi dove non c'è il mutitasking 
ne tantomeno il multithreading, ne quindi memoria protetta e memoria 
virtuale (mi riferisco alle console come il GameBoy, dove si accede 
direttamente alla memoria fisica), voglio capire cosa comporta 
esattamente questa "via di mezzo" (via di mezzo che comunque, se è come 
penso, è più vicina, già con AmigaOS 4, a un sistema a memoria protetta 
che non).
Grazie


 un linguaggio di programmazione in particolare.
Si, è quello che sto studiando....e mi piace moltissimo! Io non ho mai
concepito l'idea di mettermi davanti ad un computer e scrivere un
programma senza delle idee precise ed una progettazione in mente, penso
che dopo essermi dato questa materia le altre che ho tralasciato mi
verranno molto più facili.
Ovviamente c'è chi ragiona in modo totalmente contrario al mio, ma il
mondo è bello perchè è vario :-)


 virtuale per processo?
No, non puo` esserlo per come funziona il sistema di messaggi.
Il processo A manda un messaggio a B:
A:
struct Message msg; // lo riempo, c'e' scritto all'interno anche la 
MessagePort destinazione
PutMsg(&msg);
B:
struct Message *m;
WaitPort(myport);
m = GetMsg(); // m e' un *puntatore* al messaggio creato sullo stack di A.
TUTTO il sistema operativo funziona con questo principio, per questo 
ogni processo deve essere in grado di vedere la memoria di tutti gli 
altri processi.
Bye,
  Gabry

 mondo è bello perchè è vario :-)
In ambiti "seri" non si può non partire da una pianificazione seria del 
software, prima di scrivere effettivamente codice.


 NON crasha (ma il sistema a quel punto e' compromesso).
Per "crasha" intendi... "viene fatto crashare", ovvero il kernel termina 
il processo che ha tentato l'operazione, impedendogli di farla, per 
evitare che possa fare danni, giusto?
Esattamente come quando c'è un segmentation fault sdotto UNIX, no?
Ok, grazie mille! :-)


 processo A, e in nessun caso sarà diverso.
Mh... ancora una volta non mi è molto chiaro quello che dici, 
specialmente nell'ultima parte... cmq, se ho capito bene, mi stai 
chiedendo se più task richiedenti memoria con MEMF_PUBLIC ricevono 
potenzialmente la stessa zona di memoria? In caso fosse questa la 
domanda, la risposta è no: AllocMem() restituisce sempre puntatori a 
zone di memoria che non si sovrappongono.
Ciao,
Fabio Alemagna

 zone di memoria che non si sovrappongono.
Si, intendevo questo :-P
Grazie! :-)


 4) si tenta di scrivere su un'area di memoria non utilizzata
http://www.iksnet.it/forum/viewtopic.php?t=2265&start=15
scorrendo troverai dei post di m3x, lui è un betatester nonchè uno
sviluppatore di OS4....


Grazie!
