Newsgroup: it.comp.hardware.palmari
Titolo: Occupazione memoria

Sono ancora in ballottaggio tra un Tungsten E e un Axim economico (32 Mb Ram).
Mi domandavo quanto spazio rimane a disposizione su qusti due palmari dopo
aver installato il software standard (diciamo OS+Office suite+Acrobat o 
surrogato, anche se  probabilmente l'office suite non mi serve) per valutare
la necessita' dell'acquisto di schede di espansione.
Altra domanda: su Palm il software puo' essere installato solo ram, vero?
Alessandro.

 Altra domanda: su Palm il software puo' essere installato solo ram, vero?
No, anche su scheda di espansione. Idem per PPC.
-- 
Saluti.


Chi mi sa dire quanta memoria riamane libera su Palm?-)
Alessandro.

 Chi mi sa dire quanta memoria riamane libera su Palm?-)
Su palm hai a disposizione la memoria nominale meno un'area riservata 
del sistema operativo: Palm dichiara 28.3Mb disponibili. Da quel che ho 
potuto sperimentare un sistema operativo PalmOS può girare 
tranquillamente anche con quasi tutta la memoria utilizzata (cioè con 
quasi tutti i tuoi 28Mb occupati).
Dico quasi perchè 1) i prgrammi installati su SD vengono copiati in 
memoria centrale per l'esecuzione e 2) alcuni programmi usano la memoria 
centrale come "swap" per operazioni temporanee, ma sono piuttosto rari.
Morale diciamo 25 mega occupati e il resto lo lasci libero e vivi felice :-)
Ciao
Redhawk

 la office.
Paquito occhio che sul Tungsten C "Documnet to Go" è in ROM ;)
e se non erro lo è anche nel Tungsten E,
non ne sono certo al 100% ma quasi :)
Baciamo le Mani
--
Nicola O. & Treo600

Sbagli! Sul T|E "Document to GO" non è in ROM ;-)
Ciao
Root


 e se non erro lo è anche nel Tungsten E,
No, e' da installare. Nel T3 e' in rom.
-- 
Giuseppe Gigante


Personalmente sul T|E ho installato un po' di roba: Document to go + Web
Clipping (plucker) + chat + news + lettore mp3 + lettori multimediali vari +
giochi + zlauncher + ... ed ho più di 20Mb liber...
Ciao
Root

 tutto mostruosamente e poi impiantare il palmare...
Ma assolutamente no ! Con 15 Mb di RAM il mio iPaq 3850 fà girare senza
rallentamenti almeno 4/5 applicazioni di cui due/tre belle "toste" come
Internet Explorer, Windows Media Player e Acrobat Reader.
-- 
Saluti.


Mai dire mai. Hai mai sentito parlare di "Execute in place" (XIP)?
http://www.mvista.com/tech2.html
Alessandro.

 Sono ancora in ballottaggio tra un Tungsten E e un Axim economico (32 Mb
Ram).
Se per risparmiare stai valutando di non acquistare una scheda, devi
prendere il TE. I programmi per Palm sono molto meno pesanti.
Ciao, Gianni.

 
http://www.mvista.com/tech2.html
A parte che la tecnologia XIP è dotazione standard di PocketPC 2002, nota
questo:
=== quote ===
XIP is not a size vs. speed panacea. XIP saves RAM by not copying programs
and system code from ROM, but in doing so increases flash/ROM requirements,
primarily because XIP images must also be readable in-place, and can't be
compressed like "normal" files or kernel boot images.
=== quote ===
LA tecnologia XIP si applica alle Flash ROM (e nemmeno a tutte, solo a
determinati modelli predisposti appositamente) e consente di non ricopiare
in RAM il codice contenuto nella ROM, fornendo all'esecuzione il codice
prelevandolo just-in-time dalla ROM.
Questo è possibile solo grazie ad una strategia tecnica molto particolare
che richiede il supporto espresso sia dell'hw che del sw: ma non cambia i
termini dell'architettura teorica di un computer, perchèin pratica con XIP
la ROM emula la RAM per la parte statica dell'esecuzione (cioè del codice,
visto che questo non si modifica durante l'esecuzione medesima).
Peraltro è da notare che XIP non fà parte della dotazione standard dei
device Palm e nemmeno di alcuni modelli di PocketPC (es. iPaq 1910); non
solo: non è nemmeno applicabile alla parte di memoria RAM usata come
storage.
-- 
Saluti.

 XIP is not a size vs. speed panacea.
Certo e' solo un altro modo di fare le cose.
Alessandro.

 come storage.
Ci saranno dei validi motivi (per esempio lo storage puo' essere compresso)
ma avere due copie in RAM dello stesso programma mi sembra un po'
paradossale.
Alessandro.

argomento).
ancora con questa storia?
in quel thread non mi pare che tu abbia avuto ragione, inutile rimettersi a
parlare di storage e dynamic memory, i programmi non vengono duplicati in
ram al momento dell'esecuzione come se venissero caricati da un HD.
Ho fatto una semplice prova: mi sono rimasti liberi 2KB di memoria, ora
vado ad eseguire un programma il cui eseguibile e' grosso 721KB: il
programma viene eseguito senza problemi. Prova un po' a spiegarmelo...
Saluti.
   Paolo

 Internet Explorer, Windows Media Player e Acrobat Reader.
Appunto io ho detto che scendendo sotto 10-15 mega liberi ci sono dei 
problemi.
Inoltre il mio ex PPC dotato di processore ARM a 206Mhz (il top per 
l'epoca) con  15 Mb liberi circa moriva sotto il solo peso di agenda 
fusion, poi ripeto magari le cose sono cambiate, ma io ora uso palm :-)
Ciao
Redhawk

 programma viene eseguito senza problemi. Prova un po' a spiegarmelo...
Su che macchina ? Per caso ha PalmOS 5 ?
Se è su OS 5 ti ricordo che in macchine dotate di tale sistema operativo una
quota della RAM è *sempre* riservata all'esecuzione del s.o. e delle
applicazioni, quindi è normale: i 2 Kb che ti sono rimasti libero sono nello
storage, non in tutta la RAM del device.
Se la macchina ha OS 4 o precedenti è lo stesso, o quasi; nel senso che su
OS4 la memoria riservata all'esecuzione è molto più poca ma c'è comunque.
Se poi volete continuare a credere alle favole, fate pure.
-- 
Saluti.

OS4 la memoria riservata all'esecuzione è molto più poca ma c'è comunque.
lo ripeto per la terza volta:  la ram di storage e quella di
esecuzione sono due cose separate!
il programma utilizza per l'esecuzione la dynamic memory e non viene
ricopiato nella storage memory: non occupa il doppio dello spazio
nella storage memory  (l'unica a disposizione dell'utente) al momento
dell'esecuzione.
Saluti.
  Paolo

con le applicazioni che hai ti rimane un mare di memoria, ma una sd seppur
piccola la devi avere se lavori con documenti nativi per document to go.
--
www.clipeus.it
 tecnica e tecnologia

 document to go.
Cioe' senza SD non funziona?
Alessandro.

 dell'esecuzione.
Che vuol dire che "il programma non viene ricopiato nella storage memory e
non occupa il doppio dello spazio" ?
In nessun sistema operativo, per l'esecuzione di un programma questo viene
ricopiato dalla memoria di massa alla memoria di massa; non ha senso.
Il codice da eseguire viene caricato nella RAM e da lì mandato al processore
per l'esecuzione, il risultato elaborato dal processore torna alla memoria e
di lì eventualmente allo storage.
Nel caso specifico di PPC e PalmOS il codice viene caricato a "pezzetti"
nella RAM, secondo la corrente necessità di elaborazione (per es. nei device
PalmOS classic il "chunk" di memoria da caricare è lungo 64Kb per ogni
"pezzetto" di codice da eseguire) e non per blocchi monolitici pari
all'intera dimensione del programma.
Questo vuol dire che sia in PalmOS che in PPC è necessaria un'area di RAM
ove condurre le elaborazioni, partendo dai "pezzetti" di codice e dai dati
ivi caricati; la ovvia conseguenza è che per *entrambi* i sistemi la RAM
fisicamente disponibile nel device non è *tutta* allocabile per lo storage.
Infatti, per esempio, per il Palm TT dei 16 Mb disponibili fisicamente ne
sono utilizzabili dall'utente solo 14. Perchè ? Perchè gli altri 2 servono
al sistema operativo ed alle applicazioni per le loro operazioni.
-- 
Saluti.

 fusion, poi ripeto magari le cose sono cambiate, ma io ora uso palm :-)
Moriva perchè Agenda Fusion non era un programma particolarmente ottimizzato
(poi è migliorato): ma questo è un problema di quella specifica applicazione
realizzata in modo scadente; non è certo un problema del sistema operativo o
della piattaforma di elaborazione.
Se fai programmi scadenti puoi mettere in ginocchio anche un Cray ...
-- 
Saluti.

 Cioe' senza SD non funziona?
Non funziona con i documenti in formato nativo, cioč in formato desktop.
Vuol dire che su PalmOS se non hai una scheda di memoria non puoi caricare
nel palmare, per esempio, un file di Word con estensione .DOC ma devi prima
convertirlo in formato PDB passando dall'apposito conduit disponibile sul PC
tramite il PalmDesktop.
Non importa la dimensione del documento.
-- 
Saluti.

Tecnicamente quello che dice Paquito è esatto. Ma "fisicamente" c'è qualche
imprecisione.
Non ho grande dimestichezza con l'assembler Palm o PPC, ma trattandosi di
microprocessori abbastanza standard (ARM, Motorola, Xscale ecc ecc),
suppongo che le seguenti considerazioni generali possano essere
fatte.(quello che voglio dire che i circuiti digitali, siano essi MP, DSP o
semplici codec si prgettano sempre secondo questi schemi).
Astraendo:
In un sistema digitale la descrizione di un evento può esser fatta a vari
livelli (layer). Si va da quello più generale (Behavior Layer) a quello più
strettamente caratteristico (Physical Layer). Esistono ben 5 livelli
intermedi tra questi due tra cui i più importanti sono il System Layer, Il
Logical o Logic Layer, il Geometric Layer, i due rimanenti sono semi ibridi
ed hanno un nome differente a seconda della tecnologia.
Brevemente:
Il Behavior Layer (o livello comportamentale) descrive cosa ci si aspetta
dal dispositivo/circuito.
Il System Layer (o livello di sistema) descrive le operazioni fondamentali
che le varie parti del circuito devono compiere per svolgere quanto
richiesto.
Il Logical Layer (o livello logico) descrive come vanno interconnessi i vari
"blocchetti" di cui è composto il disp per portar a termine l'operazione
prescelta.
Il Geometric Layer e il Physical Layer invece descrivono i vari transistor
ed il loro comportamento fisico (differenza tra i due? GL descrive il
funzionamento del singolo transistor, PHL quello della zona di silicio che
costituisce il transistor).
Questo per ogni operazione che va effettuata dal singolo processo/programma.
Nella tecnologia moderna più che di singoli programmi si parla di thread.
Ogni thread viene eseguito in maniera esclusiva o concorrenziale, ma quello
che ci importa è un'altra cosa. Il meccanismo è sempre lo stesso, in più al
massimo c'è un multiplexer che commuta tra i vari thread permettendo
l'ottimizzazione della catena delle pipeline (spero di non essere troppo
criptico)
Il funzionamento è più o meno questo.
- il processore consulta le Flag di sistema (e quindi indirettamente IRQ,
Flag d'esecuzione ecc ecc).
- il thread viene caricato in memoria in un segmento (di dimensione
fissa!!!!) secondo una procedura che vedremo in seguito.
- vengono settati le flag/i bit di esecuzione secondo opportuni parametri
che dipendono da vari fattori.
- si iniziano a riempire i registri d'esecuzioni con le istruzioni prese dal
segmento e i registri dati con i dati presi dall'HEAP o dallo STACK (in
pratica sono due strutture dati ad accesso sequenziale, la cui unica
differenza è che nello stack o pila l'ultimo elemento inserito è quello
prelevato per primo, mentre nell'heap o coda, è il primo elemento inserito
ad essere prelevato).
- finito il thread si passa (eventualmente al thread successivo)
Per quanto riguarda la memoria:
- ogni singolo thread occupa almeno un segmento (che nel caso di registri a
16bit equivale a 64k)... thread molto grossi possono essere "spezzati" su
più segmenti e virtualmente gestiti come thread sequenziali. Questo segmento
è la memoria di esecuzione.
- ai thread eseguiti in modalità protetta viene normalmente assegnato un
altro segmento (o più segmenti) detto segmento dati a cui attingere per
riempire/svuotare l'heap o lo stack.
- nel caso il thread non venga eseguito in modalità protetta... viene
assegnato un singolo segmento di 64k in cui dati e codice devono convivere.
Questo schema è stato ideato per permettere  la sincronizzazione delle varie
componenti. Se infatti il processore (che ha tempi d'esecuzione ormai
dell'ordine dei millesimi o di nano secondo) dovesse attingere informazioni
da dispositivi molto più lenti (le MASS STORAGE hanno tempi di accesso
dell'ordine dei millesimi di secondo cioè circa 1.000.000-10.000.000 volte
più grandi), l'effettiva velocità di un processo sarebbe plafonata
fortemente dall'effic. delle unità a dischi. Caricando il tutto in memoria
(tempi d'esecuzione dell'ordine dei decimi di nano secondi (cioè almeno
10.000-100.000 volet più veloci di un HD) si ha una singopla attesa
all'inizio, ma poi l'esecuzione è "fluida".
Nei device come i PDA in cui MASS STORAGE e memoria RAM sono un unica cosa,
questo schema non è stato modificato a livello di sistema (System Layer)
perchè questo permette ai programmatori di utilizzare linguaggi di
programmazione standard (occorre fornire solo il compilatore adatto a
generare i binari per la piattaforma specifica) senza dover creare un
linguaggio ad hoc che limiterebbe ad una cerchia ristretta lo sviluppo del
software (come è avvenuto finora per i telefonini!).
Per cui, sebbene già presenti in memoria (nalla memoria STORAGE), i singoli
thread vanno caricati anche in quella di esecuzione, altrettanto dicasi per
i dati!
Questo, almeno a livello di sistema...
In realtà, suppongo, che ad un livello di astrazione più caratteristico (a
metà tra il System Layer ed il Logical Layer), sia stata effettuata qualche
genere di ottimizzazione che permetta di evitare la copia fisica del
thread... in pratica si realizzerebbe una sorta di link simbolico alla
posizione del thread nella STORAGE. Questo limiterebbe la richiesta di
memoria libera ad una piccola porzione che fungerebbe da cache in cui
precaricare il thread e che il processore vederebbe come un segmento
virtuale.
Quest'ultima, ovviamente, è una mia ipotesi  ma nasce da  alcune
considerazioni sui crash di sistema che necessitano del soft reset. Infatti
i processori utilizzati  ormai sfruttano la cosiddetta modalità protetta,
che permette tra le altre cose di separare lo user space dal kernel space,
cioè di impedire che un'applicazione crashando impalli il sistema. Il fatto
che le applicazioni piantandosi richiedano un soft reset (parlo di sistemi
palm, non conosco i PocketPC), a mio parere, implica che la loro esecuzione
coinvolga nello stesso thread una porzione di codice kernel (quella addetta
alla gestione del segmento virtuale), così come avviene per i sistemi
Windows di classe non NT in cui alcune routine (ad esempio quelle grafiche)
girano in kernel space e...
Beh... naturalmente la cosa è ben più complessa di come l'ho descritta io...
ma credo che in buona approssimazione si possa considerare attendibile.
Ovviamente, come spiegavo... esistono vari livelli di astrazione, e per
ciascun livello vari modi di dare la descrizione di una certa operazione (si
consideri che qualsiasio porta logica viene realizzata come combinazione di
porte NOT e NAND o, in alternativa, di porte NOT e NOR o ancora come una
combinazione lineare delle due cose!)... per cui...
Credo pertanto che nessun sistema a nessun livello usi due copie di codice
in memoria (neanche i moderni sistemi di CLUSTERING che ormai accedono ad
un'unica memoria in modo concorrenziale!) per cui mi trovo d'accordo con
Paquito nella sostanza. Tuttavia occorre sapere che chi lavora allo sviluppo
di codice del SO deve tener ben presente lo schema di cui sopra quando crea
l'interfaccia per il lancio delle applicazioni.
Ciao
Root


Non sono un ingegnere, ma il fatto che il programma venga duplicato in
memoria o eseguito sul posto rigurda il sistema operativo ma non vedo
perche' debba influenzare il linguaggio di programmazione.
Alessandro.


Sui desktop non ci giurerei (non vedo perche' dovrebbe essere cosi'). A meno
che non ti riferisca alla cache ma e' un meccanismo "trasparente" al
software.
Alessandro.

 perche' debba influenzare il linguaggio di programmazione.
La tua obiezione è più che leggittima se ti limiti ai programmi magari anche
di parecchie di linee di codice ma in cui la gestione della memoria è
lasciata al S.O. e per cui la cosa sarebbe del tutto trasparente al
programmatore. Ma quando si programma ad un certo livello (parlo soprattutto
di C e C++) ed è il programmatore che gestisce direttamente le classi di
memorizzazione, lo sfruttare un'architettura standard come quella "copia in
memoria il thread", lo svincola da conoscenze specifiche dell'architettura.
In pratica ciò ti garantisce di usare librerie che (a parte una diversa
compilazione delle stesse a seconda delle piattaforme), ti garantiscono
uniformità di comportamento. L'alternativa è usare librerie crosslink che in
un certo senso "emulano" le operazioni delle librerie standard a discapito
dell'ottimizzazione e/o delle prestazioni. Lo stile di programmazione in
pratica non è affetto da variazioni al variare della piattaforma
hardware-software.
Ciao
Root

 gestisce direttamente le classi di memorizzazione,
Io uso abitualmente il C per programmare su PC e la memoria e' gestita da
funzioni della libreria standard (malloc e compagnia) quindi il problema e'
demandato al compilatore. Il problema ce l'hai se programmi in assembler o a
livello di sistema operativo, ma a quel livello certi problemi sono normali
:-)
Alessandro.

 Allora perche' hai parlato di segmenti da 64k?
Perchč la struttura a segmenti rimane quella a 16 bit! I segmenti rimangono
tali!  Cosě si hanno un numero fisso di blocchi (segmenti) di dimensione
fissa! tu pensa che casino il gestore della memoria se dovesse mettere anche
solo pochi k in settori non contigui in una memoria


 livello certi problemi sono normali
Non sono d'accordo... perchè se vuoi ottimizzare il codice devi conoscere
come il sistema si comporta davanti ad una certa operazione. Ed in
particolare utilizzando strutture dati dinamiche (fai riferimento alla
malloc quindi hai almeno una minima idea di quello di cui parlo), un
quantitativo di dati congruo può portare a fastidiosissimi problemi di
buffer overflow/underflow in strutture tipo HEAP/STACK senza bisogno di
scomodare la programamzione del S.O.
Certo, sono d'accordo con te se dici: Devo scrivere uno stupido programmino
che mi stampia video tutte le tabelline dall'1 al 12 che vuoi che me ne
freghi se il mio procio c'ha gli indirizzi di segmento a 16 o 32bit?
Ciao Root


Ah, ok. Avevo capito che i programmi potessero essere caricati solo 64k alla
volta, non a blocchi da 64k.
Alessandro.

 operazione.
Si ma stai parlando di ottimizzazioni, che solitamente vanno nella direzione
opposta alle generalizzazioni e alla portabilita' che suggerivi parlando di
"linguaggi di programmazione standard".
Alessandro.

 suggerivi parlando di "linguaggi di programmazione standard".
No! Non mi sembra! Qui non si sta parlando dello studente che deve fare il
programmino in C per l'esame di informatica! Ma di chi ha fatto della
programmazione il proprio mestiere o più in generale di chi vuole costruirsi
un'applicazione per coprire una particolare esigenza. In questo caso la
disponibilità di Framework o IDE che utilizzino linguaggi standard e
multipiattaforma è un requisito essenziale.
Il C ed i suoi derivati sono pensati per andare oltre i limiti di
portabilità dell'assembler, ma sono stati concepiti su per piattaforme di un
certo tipo, e per questo risponde a certe esigenze. So che tutto ciò può
sembrare un controsenso, ma la progettazione di un software non può
prescindere dalla piattaforma ed in particolare come il software interagirà
sulla piattaforma stessa.
E' impensabile, ad esempio, riscrivere un'applicazione DirectX in C per
farla girare su un Palm, almeno con l'hardware attuale! Quello che ti voglio
dire è che è possibile ricreare l'interfaccia di sistema fornita dalle API
directX in C o C++  e farla girare sul Palm, ma ci saranno cmq grosse
limitazioni dovute al fatto che tali API non sono state concepite per
funzionare su quella piattaforma.
Quindi, a parte i soliti discorsi sul decadimento di prestazioni dovute alla
"simulazione" capisci che a quel punto è molto più conveniente (ma questo
non vuol dire che sia semplice!), riscriversi totalmente l'applicazione,
magari tramite l'implementazione di librerie concepite per la piattaforma su
cui vogliamo farla girare, piuttosto che prenderne una già fatta e
"adattarla"!
Ovviamente il discorso si fa sempre più ad ampio raggio.
Per questo, ritornando al discorso di partenza... il perchè su come il
sistema operativo si occupi di gestire le applicazioni influisca sulla
disponibilità di strumenti di programmazione è riconducibile al seguente
fatto (non so se hai dimestichezza con i sistemi Unix/Linux): un sistema non
è identificato esclusivamente dall'hardware che lo costituisce, ma anche e
soprattutto dal sottosistema software che lo gestisce (S.O., librerie e
perchè no? anche applicazioni!). Pensa al fenomeno Virus... perchè sono così
diffusi nella realtà Windows/Dos ed invece è un fenomeno così ritretto (per
non dire inesistente) nel mondo Unix/linux?  Semplice: per come il sistema
operativo gestisce le risorse. in effetti su Linux/unix lo stratagemma,
chiamiamolo così, dei permessi a livello processo (ma anche delle singole
risorse), rende futile qualsiasi tentativo: in pratica l'eventuale virus,
ammesso che potesse ottenere un accredito sul sistema, potrebbe danneggiare
solo se stesso e quanto da lui prodotto (i puristi non me ne vogliano, in
buona approssimazione il succo del discorso è questo!).
Ciao
Root

 essenziale.
Continua a non essere chiaro in che modo evitare la duplicazione in memoria
del programma possa dare problemi allo sviluppatore.
Alessandro.

 software.
E' così anche su desktop e dalla notte dei tempi.
Per esempio in MS-DOS di usavano i file .ovl (overlay), che erano appunto
deputati a far caricare in memoria i pezzi di codice necessari; grazie a
questo sistema anche sotto MS-DOS in modalità reale (cioè con il limite
della RAM a 640Kb) era possibile eseguire programmi che occupavano più
spazio di quanta memoria fosse disponibile.
Sotto i Windows desktop questo meccanismo è stato istituzionalizzato
mediante le DLL (Dynamic Linking Library) e con l'arrivo dei Windows
multithread questo ha consentito una facile estensione dei programmi Windows
al multithreading: basta far girare main program e DLL collegate in thread
separati.
Per esempio la funzione di stampa può essere implementata in una DLL e
quando questa funzione viene richiamata solo in quel momento e fatta girare
in un thread separato dal programma che la richiama.
Se vai a vedere l'architettura di Internet Explorer noterai che questo
concetto è portato all'estremo, tant'è che il main .exe di IE (iexplore.exe)
è veramente minuscolo: tutto il lavoro è fatto dalle DLL.
-- 
Saluti.


Si possono fare programmi multithread anche senza usare le DLL e usare DLL
senza essere multithread.
Alessandro.

 senza essere multithread.
Indubbiamento. Ma nel caso di Windows è stata facile l'estensione al
multithread in questo modo.
-- 
Saluti.

 memoria del programma possa dare problemi allo sviluppatore.
Secondo me il motivo pe cui non ci capiamo è che ci riferiamo a due cose
differenti.
Quello che cerco di dirti è che non è il copiare l'applicazione in memoria a
creare problemi (e poi chi ha parlato di problemi?). Dico solo che il
meccanismo con cui si gestisce la memoria e soprattutto la sua assegnazione
ai programmi è un elemento discriminante per i sistemi informatici. Nel caso
che citi tu (la copia fisica di un applicazione), tanto per fare un esempio,
ciò influisce molto sulla portabilità della stessa: pensa ad una grossa
suite che deve essere sviluppata per girare sia sui palmari con 8MB (come il
mio m125) che su quelli che ne hanno 32 (come il mio T|E)... un'applicazione
di anche soli 5Mb sul primo andrebbe installata su SD mentre sul secondo
potrebbe tranquillamente andare su RAM (ammesso che i 5MB debbano essere
allocati tutti in una volta per la sua esecuzione).
Ad ogni modo mi permetto di farti un piccolo excursus sull'esecuzione dei
programmi nei sistemi informatici ed in particolare in quelli multitasking
(ma sarebbe più giusto dire multithreading). Sono quattro tipi:
1) Esecuzione esclusiva - lettura/scrittura esclusiva. Ogni thread alloca
delle risorse in maniera esclusiva e per tutta la durata della sua
esecuzione quelle risorse rimangono bloccate.
2) Esecuzione esclusiva - lettura/scrittura concorrenziale. Il thread alloca
delle risorse e le tiene impegnate per tutta la durata della sua esecuzione,
ma può lanciare processi esterni (o figli) che scrivano nella stessa area
dati.
3) Esecuzione concorrenziale - lettura/scrittura esclusiva. Il thread è
strutturato in maniera da poter essere interrotto per passare il controllo
ad un'altro thread mentre questo è ancora in esecuzione (in parallelo o in
multiplexing), la sua area dati (ma anche talune risorse allocate) è
bloccata, e riservata solo al thread stesso.
4) Esecuzione concorrenziale - lettura/scrittura concorrenziale. Una volta
tipica solo dei sistemi multiprocessore. In pratica il thread è in grado di
passare il controllo ad altri thread e di condividere in pieno le risorse
con questi.
Ti dico questo perchè secondo me il problema non è tanto l'assegnazione
della memoria di esecuzione quanto delle risorse e dell'area dati. In
particolare la gestione dell'HEAP/STACK che come sai è accesso sequenziale,
deve essere tale che, nel caso in cui debba essere condiviso non ci siano
conflitti tra i vari thread. E siccome, di norma, la memoria allocata
dall'HEAP/STACK è unica...
Allo stato attuale i sistemi multithreading attuali gestiscono senza
problemi esecuzioni concorenziali tramite varie procedure. C'è chi usa un
alto parallelismo (come i processori RISC) e chi invece combina lunghe
catene di pipeline con istruzioni complesse (C-RISC E CISC in genere).
Procedure diverse significa anche diversa gestione a livello hardware... per
cui cambiando piattaforma hardware non si assicura la compatibilità tra le
piattaforme diverse. Se però tramite il sistema operativo, si riesce a dare
un'interfaccia di gestione unica ecco assicurato che la stessa applicazione
possa girare su piattaforme diverse.
Come ho spiegato all'inizio, la questione è molto complessa perchè, non si
parla del programmino in sè e per sè ma della programmazione in genere, il
che vuol dire driver, GUI, applicazioni di gestione, routine
grafiche/matematiche... ecc ecc.
Ciao
Root

 memoria a creare problemi (e poi chi ha parlato di problemi?).
Ok, ma io mi riferivo a quello che hai scritto, che fa presupporre che sia
la *non* duplicazione a creare problemi per lo sviluppo delle applicazioni:
<inizio citazione>
"Nei device come i PDA in cui MASS STORAGE e memoria RAM sono un unica cosa,
questo schema non è stato modificato a livello di sistema (System Layer)
perchè questo permette ai programmatori di utilizzare linguaggi di
programmazione standard (occorre fornire solo il compilatore adatto a
generare i binari per la piattaforma specifica) senza dover creare un
linguaggio ad hoc che limiterebbe ad una cerchia ristretta lo sviluppo del
software (come è avvenuto finora per i telefonini!)."
<fine citazione>
La mia opinione e' che, al contrario di quanto da te affermato nella frase
riportata, scelta di non duplicare in memoria ha impatto  praticamente nullo
sui linguaggi utilizzabili per la programmazione e quindi sullo sviluppo
delle applicazioni.
Alessandro.