Newsgroup: it.comp.os.amiga
Titolo: due piccoli pensieri...

e' gia' da un po' che m'erano venute in mente due cose ma un po' perche' in
questo periodo sono intrippatissimo con linux, un po' perche' ho anche altre
cose a cui pensare non ho mai scritto nulla... cmq ora che mi ricordo le
butto li'...
1) qua vedo gente che disprezza elate per partito preso per via della cpu
virtuale e vedo gente che si esalta per crusoe. ora non sono stato a vedere
se c'e' gente che sta in tutti e due i gruppi, ma se fosse sarebbe proprio
da dargli del fesso tutti in coro :) come si fa a disprezzare un s.o. che
traduce del codice da processore virtuale a processore nativo e poi ad
esaltarsi per una cpu che fa praticamente la stessa cosa? :)))
2) la storia della cpu virtuale imho e' una cosa davvero ottima... si parla
tanto di linux, di free software, di liberta' (dal monopolio windows
soprattutto) ecc. ecc. e poi tutti i programmi di un certo calibro che
vengono scritti per linux sono compilati solo per cpu intel... :\
con elate invece non farebbe differenza quale cpu si possiede, quindi chi
non vuole distribuire i sorgenti potrebbe tranquillamente distribuire un
programma binario e tutti potrebbero usufruirne ugualmente indipendentemente
dall'hw scelto. quindi un passo in avanti rispetto a linux sotto questo
punto di vista...
-- 
    Shiva
"The waves can't be as high as they pretend to be"
                     (Angra, Silence and distance)

 esaltarsi per una cpu che fa praticamente la stessa cosa? :)))
fanno la stessa cosa, ma il modo in cui la fanno e' completamente 
differente.
Crusoe e' efficente, sposta la complessita' dall'hw al sw, ma supporta
via hw l'emulatore sw (e questo gli da un ENORME vantaggio rispetto agli
emulatori/traduttori/compilatori 'classici')
La cpu virtuale ha bisogno di un hw complesso e di un sw complesso, per
avere
prestazioni decenti.
La complessita' totale aumenta e non di poco.
Tra l'altro richiede una cpu superscalare e con esecuzione fuori
ordine per non doversi sobbarcare pure il compito di reschedulare il
codice
al volo, il che non e' di certo una operazione realtime.
(Crusoe non ha esecuzione fuori ordine ma il sw rischedula solo in modo
stocastico)
Tirando le somme, Crusoe ha delle buone prestazioni in tutte le
situazioni, non esaltanti ma buone.
Il sw di tao......
poi supportano troppe cpu..il lavoro si frammenta e non credo che
abbiano raggiunto
risultati soddisfacenti in un campo cosi' complesso dove servirebbero
decine di milioni
di dollari di investimenti.
IMHO dovrebbero concentrarsi su una, due ISA al massimo.
Certo tra un anno avremo tutti cpu a 1ghz e quindi potremmo pure
fregarcene, ma questa filosofia vetero pcista non mi piace :)
E' solo ma mia opinione, quindi non fustigatemi :)
ciao,
Marco
******************************************************************************
                              Marco  'nAo'  Salvi
                  Bologna University - Department of Physics
 
mar...@cadvlsi1.df.unibo.it
******************************************************************************


Sono un ex possessore di amiga (mica tanto ex visto che il 500plus ce l'ho
ancora) e vorrei inserirmi nella discussione.
Da "vero hacker" mi sono sempre preoccupato della possibile perdita di
prestazione della cpu virtuale fin da quando lessi un articolo che parlava di
Taos (il predecessore di Elate) nel numero di Byte di luglio 1994 (cercatelo su
www.byte.com
). D'altra parte mi affascinava molto il fatto che Taos girava su
un PC con 486 (!!!) piu' una scheda con 4 transputer e un'altra scheda con
quattro mips: cioe' 9 cpu gestite contemporaneamente di tre marche diverse!
D'altra parte non posso che mostrare stupore per l'idea di Crusoe: dove tutti
aggiungono istruzioni "multimediali" alle cpu loro hanno aggiunto alla CPU
istruzioni per facilitare l'emulazione di altri set di istruzioni. L' idea
potrebbe avere un seguito: pensate per esempio di avere due alpha, uno traduce
le istruzioni x86 in alpha e l'altro le esegue! Oppure due Crusoe, fa lo
stesso...
Un'altra cosa incredibile che va a favore della CPU virtuale di Taos l'ho letta
su 
www.arstechnica.com
. Li' c'e' un articolo su un progetto della HP di un
ricompilatore just in time di codice HP a ... codice HP!  In pratica
sembrerebbe uno spreco, come tradurre da italiano ad italiano; ma test fatti
dimostrano un incremento del 20% delle prestazioni!
Quindi potrebbe non esserci perdita di prestazioni nella traduzione del set di
istruzioni virtuali Elate in un  reale.
Comunque spero che venga fatto dell'hardware all'altezza del nuovo S.O. Gia' mi
vedo computer con all'interno una batteria di Celeron (o di Spitfire) oppure di
ARM...

 di dollari di investimenti.
Ma che dici? non credo"? Non c'è niente da credere, si tratta di
guardare ai fatti...
Saluti,
Fabio Alemagna

 prestazioni decenti.
Nel mio post ho dimenticato una cosa molto importante che aggiungo qui:
Taos/Elate funziona molto diversamente da JVA VM.
I programmi in Elate si trovano nell'hard disk in codice assembler di una cpu
virtuale, ma, quando vengono caricati, sono subito tradotti in codice reale.
Cioe' una sola volta. Cioe' nella RAM di un computer con (per esempio) un Athlon
troviamo solo ed esclusivamente codice Athlon, mentre nell'hard disk codice
generico.

 generico.
Non proprio... La traduzione avviene solo quando necessario: è inutile
tradurre l'intero programma al momento del caricamento. Inoltre la
traduzione avviene mentre il programma viene caricato del disco, non
subito dopo, ma durante. 
Saluti,
Fabio Alemagna

 
Mmmh, dipende sempre dal lato in cui si guarda la situazione... Comunque
Crusoe e' solo il microprocessore e da solo non fa un bel niente :). Quello
che e' paragonabile al VP di Elate e' il sw che traduce da x86 (o qualsiasi
altro assembly) a codice Crusoe. A me sembra quindi che i 2 sistemi facciano
la stessa cosa.
Ciao Mei

 generico.
Cioe' ha un compilatore normale non jit? Come si comporta con il codice
automodificante? Se funzionasse correttamente direi che si otterrebbe il 90-95
% delle prestazioni di un codice nativo (velocita' ragguardevole). Sono adesso
curioso di vederlo in esecuzione (naturalmente non hosted).
Ciao Mei

 la stessa cosa.
Come fai a dire questo? Scusa, ma non ti rendi conto che sono un
l'opposto dell'altro?
Saluti,
Fabio Alemagna

 automodificante? Se funzionasse correttamente direi che si otterrebbe il 90-95
E' un compilatore JIT: non traduce tutto il codice in una volta sola, ma
solo quando serve. E cmq il codice automodificante è assolutamente da
evitare. Tanto più che nei sistemi a memoria protetta non funzioneranno
mai programmi automodificanti.
Saluti,
Fabio Alemagna

Fabio Alemagna ha scritto:

Ripeto, sono la stessa cosa. Per il SW del crusoe il codice l'assembly x86 e'
il "suo assembly", come per il VP l'assembly "virtuale" e' il suo. Poi
entrambi traducono il codice nel linguaggio nativo della cpu su cui girano.
Non puoi pensare prima al VP in un modo e poi al SW Crusoe in maniera diversa.
Ciao Mei


Il problema è che tu ti soffermi solo sul sw del crusoe, come se potessi
slegarlo da questo, il che non è. 
Devi considerare, invece, tutto il sistema: Il crusoe, per funzionare,
ha bisogno di un compilatore "codice non nativo"->"codice nativo",
mentre il VP gira virtualmente su ogni processore, anche sul crusoe se
necessario, e non ha bisogno di sw per funzionare, perchè *è* sw, ma di
hw. Il VP è un processore a tutti gli effetti, solo che è virtuale,
quindi non puoi paragonarlo al SW del crusoe, perchè il sw del crusoe è
un semplice traduttore, non emula un processore, ma devi paragonarlo ad
un  processore vero e proprio, come il crusoe.
Crusoe:
codice estraneo -> codice nativo
VP:
codice nativo (del VP) -> codice estraneo (RP)
Saluti,
Fabio Almagna

 
Vedi quanto detto prima.
Ciao Mei

 guardare ai fatti...
quali fatti?


 Pero' io non vorrei un nome amiga su quel coso :)
Forse per questo è ancora presto discutere...
Ciao,
Gérard

 Vedi quanto detto prima.
Vedi tu sopra...
Saluti,
Fabio Alemagna

 Crusoe non darebbe i vantaggi che potrebbe dare ad un RISC)
infatti non ne ha bisogno :)
Voglio sia ben chiaro, questa NON e' una limitazione per Crusoe, perche'
ha un contorno
hw che facilita' di molto il lavoro al sw di emulazione.
Possiede un set completo di registri fantasma su quale far girare il
codice ottimizzato
permettondosi di avere clock per clock valori diversi nei registri
attuali rispetto a 
quelli della cpu emulata, senza perdere nessun tipo di coerenza con il
flusso del programma.
Il tutto condito da istruzioni di commit/rollback per 'patchare' al volo
lo stato dei registri
della cpu sia nel caso che l'esecuzione di un blocco di istruzioni
precedentemente ottimizzato
sia andato a buon fine, sia nel caso che sia andato tutto male
(interrupt,eccezioni,codice
automodificante e cosi' via).
In piu' ha istruzioni di controllo di flusso che linkano tra di loro
pezzi di codice pre-tradotti.
In questo modo si puo' permettere di decidere stocasticamente (per mezzo
di un interrupt che viene
generato ogni n millisecondi) di ottimizzare (e quindi anche
rischedulare) i blocchi di codice
che vengono eseguiti piu' spesso.
E a qualcuno pare poco :)


 d'accordo.
Non direi meno avanzata... piuttosto più efficiente (anche se non sarà
certo il processore che farà girare più velocemente codice x86).
Cmq, ipoteticamente, sarebbe possibile fare un VP compiler più
sofisticato (e probabilmente, come dici tu, troppo lento per essere
usato normalmente) che funzioni non a runtime, ma ricompilando e
ottimizzando per la cpu host una volta per tutte (mi sembra che una cosa
del genere fosse usata per far funzionare applicazioni Win32/x86 sotto
WinNT/Alpha, ma non ricordo bene).
Ciao,
Gérard

 
Il punto e' che tu pensi che x86, ppc,... esistono come cpu mentre il VP no.
Ciao Mei

 
Purtroppo e' da quando le cpu hanno l'architettura harvard (cache dati e
codice separate) che non si puo' piu' scrivere codice automodificante.


e chi l'ha detto? un professore universitario? :)
-- 


 WinNT/Alpha, ma non ricordo bene).
si, e permetteva di avere prestazioni del 50%-70% rispetto all'originale
cpu
emulata a parita' di mhz su dei alpha 21264.
Considerando che mostri di potenza sono queste cpu (e considerando le
immense cache
di secondo livello che hanno) figurati cosa puoi ottenere su un normale
processore per desktop.
ciao,
Marco
-- 


 incrementare le prestazioni di una CPU.
Io no, perche' con tutti i transistor che risparmi eliminando la ooo
sicuramente nella cpu ci puoi inserire il doppio della cache piu'
qualche altro coprocessore floating point/simd.


che non sfrutterai mai se non hai dei compilatori della madonna
e dei sistemi per creare parallelismo anche dove non ce n'e', vedi
itanium di intel.


 processore per desktop.
Ovvio che un VP tipo quello di Tao avrà prestazioni molto variabili a
seconda della cpu sulla quale dovrà girare (anche qui è da vedere : loro
dicono di no!). Un RISC "tradizionale" come Alpha avrà difficoltà ad
emulare qualsiasi altra CPU (Crusoe insegna...), mentre forse il VP di
Tao girerà magari meglio su PPC che non su x86.
Ciao,
Gérard

 Tao girerà magari meglio su PPC che non su x86.
chissa'..chissa' :)
ciao,
marco



No, io! ;-)
--
Mario Giammarco
giam...@cs.unibo.it
Universita' di Bologna -Facolta' di Informatica

 purosangue.
Solo perche' Quake e Doom erano gli unici giochi che era possibile portare
senza rubare tempo prezioso ad altro (un giorno e un pomeriggio di lavoro,
rispettivamente) desumi che "l'apparato sovrastante non ti permette di
fare di meglio"? Per giunta girando in un ambiente di sviluppo,
dichiaratamente non ottimizzato? Di questo passo anche l'UltraSparc era
uno schifo, se visto girare simulato su INCAS (beh, Sun sta perdendo colpi
sull'HW, visto che UltraSparcIII e' uscito con un anno e mezzo di ritardo;
avrebbero fatto meglio a dimezzare il bilancio per la propaganda pro-Java
e assumere qualche progettista in piu').

 persino noi ;-)
Vuol dire che ci compreremo tutti o win2k o il prossimo OS amino. :)
Ciao Mei

 
Ciao,
Gérard

Hi guys! On 14-Apr-00 13:07:14, mr. Marco Salvi wrote:
 MS> Mi dispiace, ma questo non e' amiga....che lo chiamino come vogliono,
 MS> ma non e' amiga.
 MS> Amiga era/e' un insieme sw+hw che rappresenta una filosofia, un modo di
 MS> vedere
 MS> il personal computing, il divertimento, la multimedialita', la
 MS> creativita',
 MS> la semplicita' d'uso e l'estrema potenza con risorse relativamente
 MS> scarse.
 MS> Tu vedi niente di tutto questo?
 MS> Ok, e' ancora presto per dirlo.....ma quello che ci e' stato
 MS> prospettato fin'ora non mi piace, per niente :)
 manco a me :(((
 se non altro perché modificherà per sempre il concetto di Amiga.
 MS> Ora sono pronto per essere pubblicamente fucilato :))
BANG BANG!! :))
<tsb>
<tsb>| Emiliano Esposito                        \\\                     |
<tsb>| 
emi...@tiscalinet.it
                     \\\/// Amiga, that the |
<tsb>|"Love and do whatever you want" (S.Agostino)\\V/  world may know. |
<tsb>"It's not a dream, but only Amiga makes it possible"
"E' così brutto che se lancia un boomerang, quello ci pensa due volte prima di ritornare..."

 
e' meglio fare le cose con calma in software che a run time in hardware

 No, io! ;-)
peccato che non sia vero :)
ciao,
Marco


 e assumere qualche progettista in piu').
ma le ultrasparc sono uno schifo :)
ciao,
Marco
-- 


 persino noi ;-)
rabbrividiamo.
Dev'essere un segno celeste.....


 ma le ultrasparc sono uno schifo :)
Le altre CPU non hanno ancora copiato le operazioni di block load/store? ;)

 Le altre CPU non hanno ancora copiato le operazioni di block load/store? ;)
no, non le hanno.
Ma hanno istruzioni di load/store normali e di prefetch per le unita'
SIMD,
non trasferiranno 64 byte alla volta, ma 16/32 si.
Cmq penso che Itanium abbia qualcosa del genere...del resto se vuole
essere un processore per server internet serio ce le deve avere :)
ciao,
Marco
-- 


 non trasferiranno 64 byte alla volta, ma 16/32 si.
E sporcano ancora le cache.. eheh. Il che puo' essere ancora piu' inefficiente
nelle applicazioni che fanno uso delle' unita' SIMD, visto che il piu' delle
volte i dati vengono letti una volta sola. Si chiama "flusso MPEG" anche perche'
una volta letto un dato, passi al successivo e non torni piu' indietro.

 
Ah, gia', disabiliti la cache e cosi' funziona

 > > Un RISC "tradizionale" come Alpha avrà difficoltà ad


 Ah, gia', disabiliti la cache e cosi' funziona
no, basta flusharla nel posto giusto al momento giusto.
Scrissi un texture mapper usando codice automodificante
3 o 4 anni fa e girava egregiamente su 030/040/060.
Era pure una palla da schioppo, ogni istruzione eseguita
nell'inner loop mappava effettivamente un pixel a schermo.
Se pensi che il codice 'normale' aveva un ratio di 5:1 tra
istruzioni eseguite e pixel mappati capirai che c'era
un enorme differenza in prestazioni.
Tranne che su 060, perche' era cosi' lento e flushare
la cache (ogni qual volta un poligono aveva la scanline massima
piu lunga del poligono tracciato precedentemente, la cache
andava flushata) che conveniva usare il vecchio sistema :)


 una volta letto un dato, passi al successivo e non torni piu' indietro.
qui entrano in gioco le 'nuove' istruzioni di prefetch..pero' ci
vogliono compilatori
con le contropa22e :)
ciao,
Marco 
-- 


 Il punto e' che tu pensi che x86, ppc,... esistono come cpu mentre il VP no.
Sinceramente non ho capito cosa vuoi dire...
Saluti,
Fabio Alemagna

 vogliono compilatori con le contropa22e :)
Esistono algoritmi in grado di analizzare il flusso di un programma e determinare
che certi dati vengono letti dalla memoria (sempre o quantomeno nella maggior
parte dei casi) una volta sola? La vedo davvero dura!

 
Tu concentri l'attenzione sul fatto che il VP non e' una cpu reale, mentre le
x86, ppc, ecc... lo sono. Da qui le tue affermazioni sul fatto che le due
strutture siano una l'opposto dell'altra.
Ciao Mei

 parte dei casi) una volta sola? La vedo davvero dura!
si, ci sono algortimi che tentano di capire come generare il miglior
codice
con un unica analisi.
Ma come era da aspettarsi, ultimamente si stanno affermando
ottimizzatori
runtime, che generano il miglior codice a secondo dell'uso che se ne
deve fare.
(dopo aver analizzato le prestazioni del codice con vettori di test)
Mi pare siano stati introdotti da HP....


 per farlo? Che orrore.
L'Architettura PC non è UMA... Rudi, mi stupisci! :)
Saluti,
Fabio Alemagna

 Fabio Alemagna
che cavolo c'entra?
Non serve mica una architettura UMA per fare quella roba, vedi AGP.
ciao,
Marco


 Non serve mica una architettura UMA per fare quella roba, vedi AGP.
Infatti. Non serve UMA perche' il controller SCSI possa trasferire da se'
i dati dalla memoria al bus SCSI. Non esistono schede grafiche che fanno
da master sul bus (PCI o AGP) e copiano i dati dalla memoria della CPU a
quella della scheda video? Non sarebbe nemmeno tanto difficile supportare
una conversione al volo per i formati piu' elementari: se la mia bitmap
interna e' a 24 bit, ma il display e' a 16, il master ignora i bit in
piu' e scrive solo quelli necessari in memoria video. Dubito si riesca a
fare piu' velocemente con una CPU (e' un po' come la 3DRAM di Sun e
Mitsubishi, che in realta' ha poco a che vedere col 3D). Possibile che al
giorno d'oggi, con tutto quello che fanno le schede grafiche, soprattutto
per il 3D, non ci sia nulla del genere? 

 Non serve mica una architettura UMA per fare quella roba, vedi AGP.
Se una scheda esterna può avere accesso diretto in lettura e scrittura
alla memoria di sistema allora stiamo parlando di UMA. L'AGP permette
una cosa del genere? Benissimo, allora è UMA-compliant :) 
Saluti,
Fabio Alemagna


non e' UMA-compliant (qualunque cosa voglia dire) perche' AGP puo', a
seconda
della discrezione dell'utente vedere solo una parte della memoria totale
di sistema.
Esiste nei BIOS un paramentro chiamato AGP-aperture size dedicato
proprio a questo.


 una cosa del genere? Benissimo, allora è UMA-compliant :) 
A dire il vero il termine UMA e' abusato due volte. Innanzitutto si
riferisce all'accesso alla memoria da parte della CPU (e non di una
scheda); secondo, e' usato in sistemi multiprocessore. Se una CPU accede a
ogni indirizzo di memoria sempre con lo stesso tempo di attesa, si parla
di UMA. Un sistema NUMA (Non-Uniform Memory Architecture), invece, e'
caratterizzato da tempi di attesa variabili. Ad es. si potrebbero avere
due processori, ognuno con la propria memoria: l'accesso a quella locale
costera' x cicli, mentre con quella dell'altra CPU y (con y > x).
Volendo, si puo' considerare una qualsiasi scheda in grado di pilotare
autonomamente il bus (grafica, audio o cos'altro, non fa differenza) come
una CPU. In tal caso si potrebbe tornare a fare la distinzione di prima,
ma nella maggior parte dei casi si avrebbe a che fare con architetture
NUMA (una GeForce ha, se non ricordo male, oltre 2Gb/s di banda verso la
memoria locale; AGP ha 528Mb/s; il bus di sistema ha ad es. 800Mb/s di
banda verso la memoria di sistema, banda che la scheda non puo' usare in
pieno perche' "frenata" da AGP).
Quanto ad Amiga, le uniche macchine "UMA" sono l'A1000, il 500 e il 1200,
nella loro configurazione standard. In pratica, le macchine con sola Chip
Ram (o con la memoria "Slow-fast" a $C00000, lenta quanto la Chip).

 una cosa del genere? Benissimo, allora è UMA-compliant :) 
In realta' si chiama active busmastering. Uma significa che tutte le
periferiche usano la stessa memoria e non c'e' memoria dedicata ad una
periferica piuttosto che ad un'altra: ad esempio puntare lo schermo
all'indirizzo 'x' con 'x' arbitrario in tutto lo spazio di indirizzamento.

 Ram (o con la memoria "Slow-fast" a $C00000, lenta quanto la Chip).
Questo sempre nell'ottica dei tempi di accesso... Cmq il sistema formato
da chipset e cpu è UMA (in ogni accezione) su ogni Amiga, a prescindere
dalla presenza di Fast RAM.
Saluti,
Fabio Alemagna

 all'indirizzo 'x' con 'x' arbitrario in tutto lo spazio di indirizzamento.
E' quello che intendo io. Se l'AGP può accedere alla RAM di sistema
allora il sistema formato da AGP+CPU è un sistema UMA. Restringendo lo
spazio di indirizzamento considerato a quello in comune tra CPU e AGP,
ovviamente.
Saluti,
Fabio Alemagna

per p1)
A che risoluzione? Sul mio K6233 va un po male. Direi sui 20fps.......se non
c'è il cielo, nel cui caso scende a 8-10.
A risoluzioni abbastanza basse per giunta.....
Ciao!
Cossu Enrico-CPU at work:68000/20/30/40/60-"E quando mia moglie si intromise
per impedirmi di fare il mio dovere.....punii anche lei."

 Ciao!
320x200, ricordati di attivare i modi video vesa2.0 e di settare
un frame buffer lineare.
ciao,
Marco


 dalla presenza di Fast RAM.
Non mi pare che la velocita' di accesso alla Fast RAM da parte della CPU
sia uguale a quella della Chip. Ne' per questo i chip custom possono
accedere alla Fast, volendo cambiare punto di vista.

 opera di Intel e/o del consorzio VESA.
Già, forse con lo scopo di ridurre i costi e/o risparmiare sulla memoria
video. La differenza di prestazioni attuale fra cpu e memorie non può
che scoraggiarne eventuali implementazioni.
Ciao,
Gérard