Newsgroup: it.comp.os.amiga
Titolo: [AmigaOS4]ancora gestion della memoria....

interessante questa discussione:
http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=4914&forum=14
cosa ne pensate??
ShInKurO
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 cosa ne pensate??
Che la gestione della memoria in AOS4 si dimostra sempre di più essere 
un accrocchio...
Fabio Alemagna

 un accrocchio...
Per essere una gestione della memoria differente è parecchio
differente..... bisognerebbe conoscere se poi risulterà efficente...:-) 


 differente..... bisognerebbe conoscere se poi risulterà efficente...:-) 
 Non hanno seguito il paradigma KISS... Io resto dell'idea che in genere
semplice=efficiente. Questo mi sembra il piu' grosso casino mai visto, o
quasi (e nessuno ne aveva idea fino a oggi...).
                                     Saluti,
                                           Andrea


 un accrocchio...
La tua questione è interessante, vediamo un pò come ti rispondono.. ;-)

 quasi (e nessuno ne aveva idea fino a oggi...).
Allora: avendo riconosciuto che la gestione della memoria a partizioni
fisse sia più semplice della paginazione per mezzo dell'uso della MMU con
la virtualizzazione delle pagine, secondo il tuo ragionamento
quindi...:-)))))
ShInKurO


 quindi...:-)))))
Non solo è più semplice, ma è anche più efficiente: se non ti servono i 
benefici della memoria virtuale, non hai bisogno della memoria virtuale, 
indi il principio KISS vale ancora.
Ovviamente la memoria virtuale in ambito desktop serve, ma questo non 
vuol dire che il modo di implementarla di Hyperion, ed il modo di 
implementare l'emulazione 68k, siano i migliori: KISS principle, che in 
questo caso non viene rispettato per niente.
Fabio Alemagna

 quasi (e nessuno ne aveva idea fino a oggi...).
Puoi motivare brevemete?

 differente..... bisognerebbe conoscere se poi risulterà efficente...:-) 
Sembra abbastanza un accrocchio anche a me, in particolare non mi e' 
chiaro che succede se faccio una malloc di 128MB (probabilmente basta 
molto meno visto che gli hyperion nel thread stesso si riferiscono a 
128mb come "upper cap" per la memoria fisica...
Per certe tipologie di software potrebbe NON essere un'assurdita` 
allocare cosi` tanta memoria (ad esempio per editare una scansione A4 a 
600dpi).
Bye,
  Gabry

 Puoi motivare brevemete?
 Perche' ricorrere ad una gestione "separata" della memoria (ad una sua
partizione in fisica e virtualizzata) nel 2004, somiglia troppo a cose
come memoria base+estesa... Ormai eventuali partizioni sono gestite in
maniera del tutto trasparente sia per il programmatore che per l'utente.
Perche' ci sono delle possibilita' (ad esempio l'approccio sandbox) che
permettono di implementare gradualmente (comunque al momento non sono
complete nemmeno in AOS4) VM e MP, senza effettuare un simile
partizionamento, ed incasinando un po' anche la gestione degli Hook e
dell'emulazione - che potrebbe comportare anche overhead superiori. Vabbe'
che dalle ultime cose che ho letto sembra che il codice 68k sia
praticamente gia' considerato deprecato e la compatibilita' possa essere
abbandonata prima del previsto...
 Tra l'altro, in tutto questo, non capisco dove possa entrare il supporto
WarpUp (probabilmente verra' trattato come applicazione legacy, dunque
come gli exe 68k).
 Ad ogni modo, come al solito, chi vivra', vedra'... e io non ho
chiaramente mai scritto un OS, dunque le mie sono riflessioni di un
profano.


 quasi (e nessuno ne aveva idea fino a oggi...).
Fin ora non ho potuto leggere il tutto con attenzione e anche ora non ho
finito del tutto ma l'idea che mi son fatto sulla gestione della memoria in
OS4 è positiva.
Per quello che ho inteso in OS4 l'intera memoria è virtualizzata, fino a un
limite massimo dei primi 128Mb però c'è una corrispondenza tra indirizzi
fisici e indirizzi logici, per i restanti MB non è detto, i programmi in 68k
verranno caricati entro e non oltre i primi 128Mb ed eseguiti come sul
vecchio exec, i programmi nativi non seguiranno questa regola ma avranno
tutta la libertà del caso.
Il limite massimo dei 128Mb per i programmi in codice 68k sarà modificabile
ed impostabile a piacimento (tra 16 e 128 forse???) anche su A1 (sulle
cyberstormppc lo è già ora) e in seguito sarà possibile allocare quantità di
memoria superiori ai 128Mb tramite l'aggiunta di uno swapper.
In pratica tutto il codice presente nei primi 128Mb potrà essere considerato
ed eseguito come 68k, il rimanente come PPC.
La cosa sembra essere abbastanza semplice e ingegnosa, non vedo il motivo di
andarsi a impegolare con la MMU o altro.. inoltre non vedo l'overhead di una
simile gestione della memoria per il codice 68k.. in fondo nella 4.1
l'emulatore 68k non esisteerà più :-)
Scusate se ho scritto caxxate ma tra le fonti in inglese, la stanchezza e
l'ora tarda..

 l'emulatore 68k non esisteerà più :-)
E' statocomunicato UFFICIALMENTE che dalla versione 4.1 non sarnno più 
eseguibili su AmigaOS i vecchi programmi 68k,e sarà possibile eseguire 
solo codice nativo PowerPC?
-- 
Marco Iannaccone
FAKEci...@katamail.com
(togliere 'FAKE' dall'indirizzo - remove 'FAKE' from the address)

 solo codice nativo PowerPC?
No, ma si è definito legacy il codice 68k, inoltre si sa (ufficiosamente)
che dal 4.1 non si considereranno più i programmi 68k a discapito dei prog
ppc....
ShInKurO


 quasi (e nessuno ne aveva idea fino a oggi...).
Anche io non ne riconosco l'eleganza ma:
"We use different address ranges to differentiate between native PPC code
and 68k code. So there's always some RAM directly mapped (the 128 MB
here), and the rest is virtualized."
[...]
"On the CSPPC/BPPC yes, but not on the A1."[...]"Currently, it selects
according to the size of main memory, with 128 being the largest."
[...]
"Some memory is physically mapped, just like on old Exec. OTOH, some of
the physical memory is set aside to serve as pages for the virtual memory
system (This page pool is not mapped, so it's invisible to the CPU).
Currently, this means that these pages are just mapped somewhere in the
address space to provide memory for virtual addresses. As there's
currently no pager, they remain there until unmapped.
Once we have a pager, this will move pages in and out of memory to disk,
remapping exisitng pages. That's why right now, you're limited to the
physical memory you have (the virtual memory is just a "reordering" of the
current memory layout)."
Praticamente fin quando non c'è il paginatore, (che dovrebbe apparire
sempre in questa release con uno degli aggiornamenti rilasciati sul sito
apposito), verrà cmq utilizzata l'assegnazione fisica. Per quanto abbia
capito, tale assegnazione fisica viene effettuata attraverso pagine
fisiche, questo rende cmq tale accrocchio-gestione migliore rispetto a
quello del 3.x, in quanto con le pagine non c'è frammentazione esterna
della memoria. 
(Ma quanto sarà grande a questo punto la tabella delle pagine???)
"The point about 68k is as follows: The PPC can mark memory as executable.
Only memory with this attribute can hold code. So what we do is, we set
aside some area of addresses which have this attribute. PPC code is always
allocated from this virtual region (and backed up with memory from the
page pool just like any virtual memory). So just by looking at the address
(actually, it's a bit more complicated, but boils down to this) we can
determine if an address holds PPC code or not."
In sintesi solo i programmi nativi ppc possono utilizzare ad ora la
gestione della memoria virtualizzata...
"CallHookPkt determines if the code is PPC or not, and either directly
calls the function, or emulates it. The same works for interrupt handlers;"
Questo perchè il sistema a questo punto riconoscerà nella memoria non
virtualizzata i programmi 68k e nella virtualizzata quelli ppc.....anche
se non capisco una cosa: una volta che i prog ppc saranno stati mappati
fisicamente sulla memoria, il sistema praticamente non distinguerà più un
tubo....?
"What happens if a program does AllocMem(400MB)?
AllocMem will return 0.
The idea is to have a pager later on..."
Qui si parla di programmi 68k. Se un programma 68k esegue questo:
"AllocMem(400MB)"
gli sarà ritornato zero, ma questo sarà risolto dal paginatore. In
alternativa, utilizzabile anche senza paginatore si può usare:
"400*AllocMem(1MB)"
Dunque una volta che il paginatore sarà pronto, anche i programmi 68k
potrenno spaziare oltre i 128mb (io utilizzo WinUAE con 64mb di ram,
fin'ora non ho mai sentito il bisogno di avere più ram. Inoltre su WinUAE
non ci sono solo i programmi 68k, ma anche le librerie, il sistema, ecc...
sono 68k, dunque considerando che OS4 è ppc, saranno solamente i programmi
68k a soffrire di questa limitazione....che verrà comunque superata con
l'introduzione del paginatore).
"The separation has its reasons. 68k is pretty much legacy. Therefore
there is no mechanism in the system that depends on it." 
E questa credo che sia la cosa più importante.....
Aggiungo io un'altra cosa, ammettendo che anche ai miei occhi questa cosa
sembra un accrocchio, ma:
1) viene eseguito tutto per mezzo di un unico scheduler;
2) non c'è una doppia riassegnazione della memoria (quark assegna una
parte di memoria all'abox, l'abox la rigestisce come meglio crede
eiassegnandola a sua volta con l'intervento del prorpio scheduler....)
3) la memoria è comunque gestita a pagine, quindi non c'è frammentazione
esterna (Abox, pur utilizzando dall'1.4 i pools di memoria, assegna questa
partizionandola, e comportando comunque il problema della frammentazione
esterna);
4) Da questa gestione accrocchiata non dipende nessuna parte del sistema,
dunque ad un certo punto sarà possibile rimuoverla senza recare danno al
sistema stesso. Questo al massimo comporterà che tutti i programmi 68k non
funzioneranno più ( se in MOS verrebbe levato ABox [ovviamente non
succederà mai perchè anche quest'implementazione, una volta sviluppato il
QBox, non interferità con il resto del sistema] ad oggi non funzionerebbe
più nulla, visto che, ad oggi, è tutto su A-Box).
Questa gestione dunque, per sua stessa natura,dovrebbe risultare più
veloce per i punti 1) e 2), e risulterebbe anche più efficente per il
punto 3).
Tutto questo però senza tenere conto dell'implementazione della tabella
delle pagine, e di quanto lo scheduler impieghi a trovare la pagina
desiderata in tale tabellone.
Inoltre è stata fatta una GRAANDE premessa non condivisibile per molti
punti scontati:
1) tutti scriveranno programmi ppc;
2) bisognerà abbandonare al più presto il codice 68k;
Queste cose sono tutte un gran punto interrogativo: per come la vedo io, i
prossimi programmi potrebbero essere benissimo per 68k, in modo da
mantenere la compatibilità con AmigaOS3, MorphOS e AmigaOS4. E' anche vero
che bastano poche modifiche per permettere ad un programma 68k di essere
compilato nativamente per os4, ma se non forniscono i crosscompiler non si
possono aspettare che un programmatore AmigaOS3 o MOS possa comprare una
macchina (AmigaClassicPPC/A1) per compilare i suoi programmi. Io ancora
non ho ben capito in cosa consistano i cross compiler forniti nella
prerelease...
ShInKurO 


ppc....
Bisognerà vedere quanti ce ne saranno di questi programmi PPC..
immagina le migliaia di programmi che ci sono in giro adesso e che se
va bene sono stati compilati con SAS nel peggiore dei casi con dei i
compilatori  più disparati. Per non pensare a linguaggi non C.
Vedremo.. il tempo è tutto dalla nostra parte. :D
Andrea Palmatè

Ecco una spiegazione più chiara da m3x...
http://www.iksnet.it/forum/viewtopic.php?t=2274


 
http://www.iksnet.it/forum/viewtopic.php?t=2274
Ok chiaro ;-)
Alla fine la divisione tra memoria FAST e VIRTUAL ricalca gli approcci già
visti in passato con programmini tipo VMM e credo sia il modo più semplice
da implementare e compatibile per far girare i vecchi programmi in 68K, in
pratica nessuno stravolgimento.

 compilato nativamente per os4
 Il problema e' che quelle poche modifiche dovrebbero farle tutti gli
sviluppatori (cosi' si obbligano tutti ad imparare anche le nuove
procedure di AOS4), quando fino a ieri tutti erano convinti che
realizzando programmi 3.x si sarebbe coperta tutta la comunita' (con solo
due compilazioni: una 68k per classic, UAE, Amithlon, MOS e AOS4, ed una
per AROS, senza aver bisogno di toccare i sorgenti, idealmente). Ma temo
che si voglia evitare questo: e si cerca di produrre una frattura per
togliere l'"acqua" alla concorrenza. O con AOS4 o contro! Peccato, perche'
alcuni sviluppatori avevano abbracciato per il momento l'idea del 68k per
tutti...
                       Saluti,
                             Andrea


 tutti...
Beh, del resto stanno cominciando ad uscire applicazioni che girano solo
su MorphOS, prima o poi deve pur accadere la frattura di API....
ShInKurO


 Qualcuno deve per prendere una simile decisione....
E' strano come fino ad oggi l'opinione generale, e se non sbaglio anche 
la tua, fosse differente. Parlo di AROS, per chi non l'avesse capito, ed 
il fatto che lo si riterrebbe utile se e solo se ci fosse un emulatore 
68k integrato cosě da poter utilizzare tutta la massa di programmi per i 
quali, ormai, i sorgenti sono introvabili.
E' quasi divertente osservare un tale cambiamento di rotta :-)
Fabio Alemagna

 E' quasi divertente osservare un tale cambiamento di rotta :-)
Io non ho cambiato rotta, non sono un traghetto :-P


 sviluppo....
Noooo, per cortesia, basta con questa storia! :)
C'č una versione per AROS di UAE, per questo. Lasciamo che AROS svolga i 
compiti per cui č stato pensato.
p.bes

tutti...
Be intanto per lo meno Amithlon ha i suoi sviluppatori che
continueranno a supportarlo.
Non ce ne saranno molti, ma chi c'č fa del buon software.

 600dpi).
Sì, ma chi svilupperebbe un software simile su OS4 per 68k ?? E' chiaro che
lo faresti per PPC e useresti la IExec->AllocMem(128000000,MEM_V) -> non
conosco il flag esatto.
Inoltre, alla fine ritengo che la maggior parte degli utenti non terrà la
memoria fisica a 128MB, si faranno un po' di prove con i programmi 68k che
si usano solitamente e diciamo che intorno ai 16MB si può stare tranquilli.
Probabilmente per l'architettura dell' OS4 era la soluzione migliore.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/