Newsgroup: it.comp.os.amiga
Titolo: Finalmente un commento di Dave Haynie sul VP

http://amiga.org/editorials/2000/0808-haynie.shtml
Saluti,
MpZ

 
http://amiga.org/editorials/2000/0808-haynie.shtml
Non vorrei sbilanciarmi troppo ma... mi parrebbe un commento /alquanto/
positivo...
Saluti,
Fabio Alemagna

 positivo...
A me sembra un commento estremamente positivo, sopratutto "Questo e'
dove il mondo dell'informatica sta andando" checche' ne dicano i
miscredenti...
Luca
------
To reply remove "nojunk" from 
gdi...@hpu.nojunk.edu
http://www.geocities.com/SouthBeach/Canal/3184
 (Under Construction)
Sent via Deja.com 
http://www.deja.com/
Before you buy.

 miscredenti...
Haynie dimostra di parlare a sproposito (come ha preso l'abitudine di fare da
quando la CMB e' fallita): ad esempio quando dice "For one, the local native
back-end/JIT/VM can be finely tuned to the specific processor you have" invece
TAO dice l'esatto opposto: il backend e' minimale e non e' pensato per
sfruttare la cpu ospite al 100% (per quello si possono creare dei tool
nativi), ma bensi' per essere convertito a nuove cpu con il minor possibile
sforzo. Poi aggiunge "And if you integrate profiling in this, the run time
system can gradually improve the quality of the translated code over time, as
it analyzes how that code is running" ma anche questo non ha nulla a che
vedere con il software di TAO (il quale fa la traduzione a load time e basta
-- ed e' considerato un punto focale del progetto). Il paragone che segue,
poi, non ha assolutamente senso: l'idea dietro a FX!32 e' che la gran parte di
quanto viene eseguito (sistema operativo, librerie, drivers, etc...) sono
software nativo ed ottimizzato per l'alpha, e che quindi la parte "tradotta"
e' minimale -- tao invece punta ad un sistema operativo scritto in gran parte
per il VP.

 Haynie dimostra di parlare a sproposito ...
Forse non hai capito il senso degli esempi.
DH intravede possibilita' di sviluppo interessanti per il VP:
- ottimizzazione spinta tramite generazione di opcode specifici per il
singolo processore (the local native back-end/JIT/VM can be finely tuned to
the specific processor you have); Da notare "CAN BE".
- ottimizzazione a run-time tramite profiling e rigenerazione di codice (And
if you integrate profiling in this, the run time system can gradually
improve the quality of the translated code over time). Da notare "IF YOU".
Entrambe le cose esistono e sono gia' implementate (in sw) nella HotSpot JVM
v1.3 (Java2) di Sun.
Java2 tiene in codice di "traduzione" degli opcode in una libreria separata
e installabile dall'utente. Esistono gia' 3 versioni della libreria: una per
esecuzione in JIT, una per l'esecuzione con HotSpot dedicata ad applicazioni
server e una per l'esecuzione con HotSpot dedicata ad pplicazioni client.
Per Sun, creare una jvm dedicata a processori specifici, potrebbe essere
solo questione di flag di compilazione...
Hayne non ha inventato niente, comunque.
Lo sviluppo di un VP con le caratteristiche evidenziate da DH non faceva
parte dei piani di TAO.
Questo non significa che TAO voglia precludersi la strada per eventuali
miglioramenti e perfezionamenti. Alla luce di quello che hanno realizzato,
non credo che siano tanto stupidi da non aver pensato a backend specifici e
ottimizzazione runtime.
Mik.
p.s.
Buone Vacanze a tutti !
--

> miscredenti...
 CR> Haynie dimostra di parlare a sproposito (come ha preso l'abitudine di far
 CR> quando la CMB e' fallita): ad esempio quando dice "For one, the local nat
 
 E tu dimostri - come dopotutto fanno di solito i lagnosi su Usenet -
 di non CAPIRE cosa ha scritto, E di NON sapere di cosa parli.
 
 CR> back-end/JIT/VM can be finely tuned to the specific processor you have" i
 CR> TAO dice l'esatto opposto: il backend e' minimale e non e' pensato per
 CR> sfruttare la cpu ospite al 100% (per quello si possono creare dei tool
 CR> nativi), ma bensi' per essere convertito a nuove cpu con il minor possibi
 
Ma, dal momento che il costo della traduzione si paga una sola volta,
e non ad ogni esecuzione, come accade con le JVM tradizionali (quelle
di ricerca sono già oltre...), la complessità può aumentare
arbitrariamente senza impattare negativamente i tempi di startup e di
esecuzione dell'applicazione:
There are big advantages to this. For one, if you're keeping the
translated code for a long period of time, you can spend considerably
more time in the translation. One primary reason Java JITs don't
match native code is that they're not keeping around translations for
very long, so there's an inherent limit on how much time the compiler
can spend in optimizations. 
 
 CR> sforzo. Poi aggiunge "And if you integrate profiling in this, the run tim
 CR> system can gradually improve the quality of the translated code over time
 CR> it analyzes how that code is running" ma anche questo non ha nulla a che
 CR> vedere con il software di TAO (il quale fa la traduzione a load time e ba
 CR> -- ed e' considerato un punto focale del progetto). Il paragone che segue
 
Ovviamente, il codice tradotto a load time, può essere "farcito" di
spie, frequenzimetri ecc. che registrino la frequenza di esecuzione
dei "basic-blocks": questa operazione si chiama "profiling". I dati
così raccolti sono preziosissimi per un'ottimizzazione mirata, che
avviene, invece che a run-time, come nella HotSpot, a LoadTime. Ma il
principio è lo stesso.
If you have this, you can do lots of interesting things. For one, the
local native back-end/JIT/VM can be finely tuned to the specific
processor you have: not just PPC, but PPC7400 with vectorizing; not
just x86, but Athlon-specific x86, etc. And if you integrate
profiling in this, the run time system can gradually improve the
quality of the translated code over time, as it analyzes how that
code is running. DEC did much of this stuff way back, on the FX!32
project. Apparently, IBM, HP, Sun, and a few others have also done at
least some research on this.
 
 CR> poi, non ha assolutamente senso: l'idea dietro a FX!32 e' che la gran par
 CR> quanto viene eseguito (sistema operativo, librerie, drivers, etc...) sono
 CR> software nativo ed ottimizzato per l'alpha, e che quindi la parte "tradot
 CR> e' minimale 
 
Quando la parte "tradotta" sono programmini tipo WORD, EXCEL, ecc. la
CPU può passare il 60-70% nel codice dell'applicativo, a formattare
paragrafi, calcolare e ordinare celle ecc.
Se tu avessi letto gli articoli di ricerca pubblicati dagli ingegneri
DEC avresti notato come i compilatori per ALPHA, compreso il
compilatore dinamico FX!32, facciano ampio uso dei performance
counter interni del processore per allineare in modo ottimale la
posizione dei dati in memoria fisica, delle pagine nella VMEM ecc.
 
 CR> -- tao invece punta ad un sistema operativo scritto in gran parte per il VP.
 ...e qui cascano gli asini, compresi TAO e Haynie...
	Sergio Ruocco - 
ruo...@comm2000.it

  ...e qui cascano gli asini, compresi TAO e Haynie...
Pero' e' questo lo scopo di Tao. Non l'ho deciso io e neanche me lo sono
inventato...

 
http://amiga.org/editorials/2000/0808-haynie.shtml
Pare essere abbastanza soddisfatto, anche se quel "così (o qui) va il mondo
informatico"  mi lascia pensare...
Ah, del Pios/One nulla? Cosa fa il progettista del 1200 ora?
--
--
Giuseppe Gigante

>  ...e qui cascano gli asini, compresi TAO e Haynie...
 CR> Pero' e' questo lo scopo di Tao. Non l'ho deciso io e neanche me lo sono
 CR> inventato...
 
E comunque la strada sbagliata, per migliorare l'accoppiamento tra
applicazioni e hardware inserire in mezzo un sistema operativo è un
passo nella direzione sbagliata. Ovviamente non ti sto a spiegare
quale è quella giusta, ne perché...
	Sergio Ruocco - 
ruo...@comm2000.it

 Ovviamente non ti sto a spiegare quale è quella giusta, ne perché...
Ovviamente ci vogliono almeno 3 lauree per capire che un ulteriore strato
intermedio e' un problema...

> Ovviamente non ti sto a spiegare quale è quella giusta, ne perché...
 CR> Ovviamente ci vogliono almeno 3 lauree per capire che un ulteriore strato
 CR> intermedio e' un problema...
 
Ci vuole ben di più di una laurea: ci vuole CULTURA INFORMATICA,
PROSPETTIVA ed ESPERIENZA. Poi, di strati intermedi tra
l'applicazione e l'hardware possono ben essercene anche più di uno: è
come sono strutturati internamente, e come interagiscono tra loro,
quali astrazioni implementano, quali controlli esportano, ecc. ecc.
che è importante, anzi cruciale.
 
Il vetusto modello "a sistema operativo", o a layers (o a cipolla),
nato negli anni 60, è drammaticamente inadeguato. Quello a
microkernel è la risposta degli anni 90 (sbagliata) a un problema
giusto. Nel 2000 i requisiti del software serio sono tanti e talmente
"challenging", che non esiste sistema operativo o linguaggio di
programmazione, o loro combinazione, adatti a soddisfarli
adeguatamente.
Anzi, pensare ad un sistema operativo, o a un linguaggio di
programmazione, per affrontarli, è una contraddizione in termini. Per
questo le scelte tecnologiche di TAO, che separano l'applicazione
dall'ambiente di esecuzione mediante un VP, porteranno su un binario
morto; se poi ci mettono un sistema operativo in mezzo...
Il sistema operativo del futuro è il NON-sistema operativo.
 
	Sergio Ruocco - 
ruo...@comm2000.it

 ospite e' necessario scrivere tool NATIVI da associare ai tool generici?
E questo non lo dovresti fare *comunque*? Quindi dove sta il problema?
Saluti,
Fabio Alemagna

 E questo non lo dovresti fare *comunque*? Quindi dove sta il problema?
Infatti non era esposto come un problema, ma come la descrizione di un FATTO.

 morto; se poi ci mettono un sistema operativo in mezzo...
Cosa ci posso fare? Vado alla tao (o da amiga inc, o da microsoft) e gli
brucio gli uffici? Che le loro idee non abbiano nulla di sconvolgente, che
quello che ne uscira' sara' ben lungi dal cambiare il mondo informatico e' una
cosa su cui non ho l'ombra di un dubbio... Ma tutto questo cosa ha a che fare
con haynie che parla del vp senza neanche aver letto la brochure di 2 pagine
che c'e' sul sito di tao?

 Infatti non era esposto come un problema, ma come la descrizione di un FATTO.
Il fatto è che se dobbiamo paragonare un ambiente operativo classico,
con quello Elate/Ami, ci si rende conto che Elate può fare le stesse
cose degli altri (codice nativo) ma gli altri no  possono fare le stesse
cose di elate...
Saluti,
Fabio Alemagna

> Anche Windows era "così o pomì", e ci sono voluti dieci anni di
 CR> Windows ERA? Perche' la microsoft e' fallita questa notte?
Con buona pace di Zironi che delirava "Useremo tutti NT", qualcuno ha
scoperto che Linux funziona meglio di Windows; dopo IBM, l'ultima
fulminata sulla via di Damasco è HP. Notare come Linux non faccia
molto di più, o di meglio, di quanto non facciano gli altri Unix
proprietari. A riscaldare gli animi sono le sue POTENZIALITA', quello
che PUO DIVENTARE, non quello che E'. Riesci a vedere le analogie ? O
sei ancora con le fette di salame sugli occhi ?
 CR> miracolo. Sto semplicemente dicendo che la discussione intorno al come si
 CR> dovrebbe fare non ha alcun senso, in quanto tao ha gia deciso (ed a senti
 CR> loro, sono 10 anni che seguono questa strada). 
 
La versione I è quella. Come sarà fatta la versione II ?
Haynie lo sa, io pure. Tu non riesci nemmeno a concepirla.
 
 CR> lo e' fin dall'inizio: conosci qualcuno che tratta, nel mondo reale, i da
 CR> sotto forma di gerarchie strutturate ad albero con una singola radice? e
 CR> gerarchie ad albero multiradice? direi di no...
Nei database i modelli di rappresentazione dei dati sono a E-R, O-R,
oggetti puro e qualcosa d'altro. Mai sentito di gerarchie strutturate
ad albero, se non l'approccio originale dei sistemi OO, che però non
gestiscono i dati come fanno i DB.
 
 CR> Cosa ci posso fare? Vado alla tao (o da amiga inc, o da microsoft) e gli
 CR> brucio gli uffici? Che le loro idee non abbiano nulla di sconvolgente, ch
 CR> quello che ne uscira' sara' ben lungi dal cambiare il mondo informatico e
 CR> cosa su cui non ho l'ombra di un dubbio... Ma tutto questo cosa ha a che 
 CR> con haynie che parla del vp senza neanche aver letto la brochure di 2 pag
 CR> che c'e' sul sito di tao?
 
L'ha letta, il problema è che lui ci ha visto dentro molte più cose di
quante tu non riesca a immaginare. Per dirla con Shakespeare:
	"Ci sono più cosa tra cielo e terra, Orazio, di quante non se ne
sognino nella tua filosofia." Amleto. Atto I (scena 1 o 2 ).
 
	Sergio Ruocco - 
ruo...@comm2000.it

 Orazio, di quante non se ne > sognino nella tua filosofia." Amleto. Atto I (scena 1 o 2 ).
Ebbasta, hanno capito tutti che hai studiato piu' di me... non e' il caso che
tu ti sforzi a dimostrarlo ad ogni messaggio. Il punto e' piu' che chiaro...
Le argomentazioni restano deboli... La tua posizione resta quella di imporre
una autorita' di "quello che sa di piu' e che non sta neanche a spiegare il
motivo, perche' tanto non lo capiresti..."

> creduto di intendere...
 CR> I "can be" and "if you" dell'informatica, nel 1960 portavano a computer
 CR> parlanti ed in grado di comprendere il linguaggio parlato... I "can be" e
 CR> "if you" del lisp dicevano che avrebbe soppiantato tutti gli altri interp
 CR> e compilatori... I "can be" e gli "if you" di java dicevano che la maggio
 CR> delle applicazioni mainstream sarebbero state riscritte tutte in java...
 
AHI AHI, e qui ricasca l'asino, perché non stiamo discutendo se
questi sviluppi siano possibili, come sostiene Haynie (ed io), oppure
improbabili (come vuoi dire tu), ma di
1 - COSA VOLEVA DIRE HAYNIE NEL SUO MESSAGGIO "Il VP è interessante
perché si potrebbe ...e inoltre..."
2 - COSA TU - SBAGLIANDO - HAI CREDUTO CHE DICESSE "Il VP è
interessante perché è implementato così...inoltre supporta..."
che sono DUE COSE TOTALMENTE DIVERSE. Il ridicolo è che non solo le
hai confuse, ma hai pure quotato il messaggio originale, sbagliandone
l'interpretazione.
Comunque, anche entrando nel merito (sbagliato) della tua risposta,
qui la distanza tra i "è" e "sarà" è di gran lunga inferiore. Le JVM
hanno compiuto la stessa evoluzione, dal semplice interprete al
compilatore dinamico, in soli quattro anni, e quello che si deve
aggiungere al TAO/VP esiste già da anni in progetti di ricerca
neanche troppo avanzati.
 CR> C'e' una grossa differenza tra vendere sistemi basati su linux e abbandon
 CR> windows in favore di linux. IBM e' stata piagata per anni dai problemi di
 
 Windows rimane per il consumer di super-massa e i sistemi legacy di
 amministrazione, come banche, uffici di segreteria e contabilità ecc.
 il 90% dell'internet computing, information appliances, embedded
 ecc. si svilupperà su Linux, o Linux+Java.
 
 CR> stato fatto anche da SGI). Linux e' una moda: dopo il fiasco di java (orm
 CR> relegato ad applicazioni server side nel 90% dei casi) e' il turno di lin
 
 Le applicazioni server sono il 90% del software sviluppato oggi, e
 oltre al VB (per i disgraziati con Windows) si usa Java, Perl ecc...
 
 CR> ovunque: dal pda al datacenter. Come tutte le mode, in 3-4 anni si
 CR> ridimensionera'... Non dico che windows sia il futuro, certamente (almeno
 CR> auguro) il futuro non sara' linux.
 
 Questa ce la segnamo assieme a "Il DOS sfruta a fondo l'hardware" di
 Callegari e "In futuro useremo tutti NT" di Zironi.
 CR> Tu sai gia' come sara' la versione 2, e magari anche la versione 34. Io m
 CR> non riesco a concepirla, ma magari piu' semplicemente mi limito ad aspett
 CR> di vedere se la versione 1 sopravvivera' alle aspettative che hanno cerca
 CR> generare.
 
La versione 1 risolve un problema che esisteva 5-10 anni fa, quello
della portabilità del codice binario, che ora è molto ma molto meno
sentito, grazie a tools e linguaggi multi-piattaforma.
 CR> Mai sentito di gerarchie strutturate a singola radice? E' curioso, perche
 CR> il filesystem uno ci ha a che fare praticamente in continuazione: la meta
 CR> ad alto livello dell'interfaccia utente non la altera in alcun modo -- qu
 CR> benche' sia poco naturale e sia noto a tutti.
No, il filesystem è un organizzazione ad albero di meta-dati, i nomi
dei file. I dati nei file non sono strutturati ad albero: in generale
non sono strutturati affatto.
 
 CR> Ebbasta, hanno capito tutti che hai studiato piu' di me... non e' il caso
 CR> tu ti sforzi a dimostrarlo ad ogni messaggio. Il punto e' piu' che chiaro
 Io tengo a dimostrare che qualcuno ha torto, soprattutto quando
 questo cerca di farmi passare per fesso, quando il fesso è lui.
 CR> Le argomentazioni restano deboli... La tua posizione resta quella di impo
 CR> una autorita' di "quello che sa di piu' e che non sta neanche a spiegare 
 CR> motivo, perche' tanto non lo capiresti..."
 La mia argomentazione è in cima al messaggio: non sai leggere.
	Sergio Ruocco - 
ruo...@comm2000.it

 dei suoi sistemi basati su HP-UX/PA
Purtroppo l'HP/UX si è instradato in un binario morto per le licenze, ed il
concetto di "pages" spinto al limite.
AIX ormai soffriva anche sulle gloriose AS/400, ed è diventato
incontrollabile in ambito media azienda.
[snip su Hawnie]
Sul resto, non mi pronuncio....voglio aspettare...
--
--
Giuseppe Gigante

 l'interpretazione.
No no no... vedi che rientra in atto la tua retorica da imbonitore
televisivo... il primo messaggio diceva che haynie parla di un futuro del vp
che non e' possibile in quanto completamente opposto al principio su cui tao
sta tentando di basarlo: il fatto che si POSSA avere un backend ottimizzato
specificamente per una particolare estensione di una particolare famiglia di
CPU: il design del VP e' eccessivamente generico per permettere una cosa
simile. L'altro commento a riguardo del prodifiling e' altrettanto vuoto:
perche' implica altrettanti massicci cambiamenti nella filosofia del VP, il
quale a detta di tao e' gia' disponibile per 9 (o 11 o 13) piattaforme, quindi
un cambiamento radicale sarebbe costoso in maniera esagerata. 
Solo che poi lo hai rigirato sul futuro dell'informatica, su quanto ormai
windows sia in fase calante ecc.. Per poi dire che il futuro dell'informatica
non c'entrava un tubo nonappena non era piu' comodo per mantenere il tuo
discorso...

> l'interpretazione.
 CR> No no no... vedi che rientra in atto la tua retorica da imbonitore
 CR> televisivo... il primo messaggio diceva che haynie parla di un futuro del
 CR> che non e' possibile in quanto completamente opposto al principio su cui 
 Falso. E' ampiamente possibile. Mi ricordi quelli che ragliavano su Java, che
 "essendo interpretato, sarà sempre più lento di un linguaggio compilato"... 
 
 CR> sta tentando di basarlo: il fatto che si POSSA avere un backend ottimizza
 CR> specificamente per una particolare estensione di una particolare famiglia
 CR> CPU: il design del VP e' eccessivamente generico per permettere una cosa
 CR> simile.
 
 Falso: basta estendere il set di istruzioni del VP aggiungendo un set di
 istruzioni vettoriali, che poi sarà specializzato per ALTIVEC, MMX
 ecc. dal compilatore a load time, oppure esteso in macroistruzioni
 assembly, se queste unità non fossero presenti.
 
 CR> L'altro commento a riguardo del prodifiling e' altrettanto vuoto:
 CR> perche' implica altrettanti massicci cambiamenti nella filosofia del VP, 
 CR> quale a detta di tao e' gia' disponibile per 9 (o 11 o 13) piattaforme, q
 CR> un cambiamento radicale sarebbe costoso in maniera esagerata. 
 
 Falsissimo: per il profiling la struttura del VP non cambia affatto,
 semplicemente si fa un overloading del traduttore di codice di un
 basic-block di istruzioni, che aggiunga in testa/coda un paio di
 incrementi di contatori di performance, e/o start/stop di timer
 hardware (ormai ce li hanno tutti i processori), una robetta da
 esamino di compilatori.
 CR> Solo che poi lo hai rigirato sul futuro dell'informatica, su quanto ormai
 CR> windows sia in fase calante ecc.. Per poi dire che il futuro dell'informa
 CR> non c'entrava un tubo nonappena non era piu' comodo per mantenere il tuo
 CR> discorso...
 
 Falsissimo: PRIMA ti ho spiegato perché la compilazione dinamica era
 utile in FX!32 per Alpha, e dopo qualche messaggio in cui insistevi
 a dire che TAO è così quindi è inutile speculare, io ti rispondevo
 che anche Win era stato consegnato su tavole della legge dalla MS,
 ma NON PER QUELLO NON ERA AMPIAMENTE CRITICABILE E MIGLIORABILE, ANZI !
 
 Se vuoi criticare quello che dice Haynie, cerca di informarti meglio.
 
 Mesi fa, quando venne fuori per la prima volta la notizia di TAO/VP,
 Haynie liquidò l'idea con un "il solito progettino da università";
 ora dopo alcuni mesi è li che sbava immaginando le evoluzioni.
 
 Idem per Linux: ai tempi degli annunci di AMIGA Inc. era una
 schifezza immonda, soprattutto per il RT, ma anche per la GUI, ora
 va quasi benissimo.
 
 Nel caso di TAO/VP aveva ragione prima - niente di straordinario - e
 ha ragione adesso - risolve il problema della mobilità del codice E
 delle prestazioni, due esigenze in fortissimo contrasto nei sistemi
 embedded ad alte prestazioni (wireless e mobile computing, ad esempio).
 
 Linux nel frattempo è migliorato molto, sia nella facilità
 d'installazione ed uso, sia nelle prestazioni real-time, nel senso
 generico del termine (nel senso formale del termine, sistema
 operativo real-time è un ossimoro).
 Sia l'approccio TAO/VP, sia quello Java, sia quello di
 Crusoe/Transmeta, di cui curiosamente nessuno parla più ma è il più
 interessante in assoluto...
 
 A proposito, mi sai dire quanta differenza
 c'è tra l'ISA x86 e quello di un processore VLIW a 4 vie ? Più o
 meno di quella tra il set di TAO/VP e un assembler tradizionale ?
 No, sai, perché Transmeta non solo ha implementato un compilatore
 dinamico x86-VLIW, ma emula anche tutto il resto del processore,
 eccezioni, memoria protetta e BUG inclusi...
 
 Quello che nessuno ha ancora detto è che con un prodotto come
 CRUSOE, una CPU virtuale riprogrammabile, soluzioni come il TAO/VP 
 nel giro di 5 anni non avranno più ragione di esistere...
 
	Sergio Ruocco - 
ruo...@comm2000.it

  nel giro di 5 anni non avranno più ragione di esistere...
Basta con 'sta storia, Crusoe NON E' riprogrammabile, non piu'
di qualsiasi altro microp.
******************************************
Marco  'nAo'  Salvi
Bologna University - Department of Physics
mar...@cadvlsi1.df.unibo.it
******************************************


  nel giro di 5 anni non avranno più ragione di esistere...
Gia' adesso non e' che ci siano poi cosi' grandi ragioni per un ambiente
interamente basato su un processore virtuale... Un sistema di distribuzione di
applicazioni neutrale per la piattaforma potrebbe avere senso, ma ormai le
piattaforme sono cosi' poche...

>  nel giro di 5 anni non avranno più ragione di esistere...
 CR> Gia' adesso non e' che ci siano poi cosi' grandi ragioni per un ambiente
 CR> interamente basato su un processore virtuale... Un sistema di distribuzio
 CR> applicazioni neutrale per la piattaforma potrebbe avere senso, ma ormai l
 CR> piattaforme sono cosi' poche...
 
 L'approccio Transmeta libera i progettisti dell'hardware dalle
 catene della compatibilità con il passato, che oggi limitano
 fortemente le possibilità di velocizzare i chip e/o ottimizzarli
 per determinati scopi (basso consumo, prestazioni intere vs FP
 ecc.).
 
 Le piattaforme HW potranno diventare un'infinità, proprio perché
 l'interfaccia tra HW e SW è (RI)DEFINIBILE IN SW, e non più in HW.
 
 Il set di istruzioni diventa solo una questione di compatibilità,
 o di gusti, mentre l'architettura HW viene ottimizzata per il
 particolare processo produttivo ecc..
 
	Sergio Ruocco - 
ruo...@comm2000.it

>  nel giro di 5 anni non avranno più ragione di esistere...
 MS> Basta con 'sta storia, Crusoe NON E' riprogrammabile, non piu'
 MS> di qualsiasi altro microp.
 
Sciocchezze: la definizione dell'x86 si carica come se fosse un
FlashBIOS. Bug nel compilatore ? Bug nella maschera ?? Nuovo firmware
di emulazione con la toppa e via...Lo dicono chiaramente
nell'articolo su IEEE SPECTRUM. Altrimenti se *la cpu emulata da*
Crusoe non fosse riprogrammabile il tutto non avrebbe alcun senso...
	Sergio Ruocco - 
ruo...@comm2000.it

 Crusoe non fosse riprogrammabile il tutto non avrebbe alcun senso...
stavolta la sciocchezza l'hai detta tu.
L'emulatore che gira su Crusoe e' un sw come tutti gli altri, dire che
Crusoe
e' riprogrammabile e' come dire che su uno z80 posso caricare tutti i
programmi
che voglio.
E' banale e non significa che lo z80 e' riprogrammabile.
Una FPGA e' riprogrammabile o la pipeline 3D di un chipset con supporto
DirectX8
e' riprogrammabile.
Il mio x86 e' forse riprogrammabile perche' lo uso per giocarci a Mario64?
Siccome ti diverti tanto a dare i compitini, ora e' arrivato il tuo turno di
fare i compiti (non si finisce mai di imparare, dovresti saperlo):
http://www.patents.ibm.com/details?pn=US05832205__
dovresti leggere (e possibilmente capire) questa roba invece di qualche
whitepaper per giornalisti.
ciao,
Marco

>  da 15 anni e Windows 2000 ha bisogno dei pasticci ?
 MS> quindi? X rimane lentissimo pure in locale, dove non devi
 MS> aprire un socket.
 
Leggiti gli ultimi articoli dell'X Consortium, di X Free, e questo
Thread di /.
 
http://slashdot.org/articles/99/08/19/1237208.shtml
dove spiegano come e perché si può e si deve migliorare. 
Windows non fa testo come confronto perché ha un architettura
"diretta", non redirezionabile.
 MS> nada.
 MS> XFree 4 ha varie migliorie ma non in questo senso.
 
OTTIMO, ci sono i sorgenti: se non ti piace, invece di ragliare,
miglioralo, e poi vieni a raccontarci come hai fatto.
 MS> ma c'hai proprio la fissa con M$ e Intel :)
 
C'è una certa discrepanza tra la loro posizione di mercato,
l'immagine che ne hanno gli utenti comuni, e la qualità dei loro
prodotti, è bene che qualcuno si ricordi ogni tanto che i Re sono
abbondantemente nudi...
 
 MS> Da dove e' scappati fuori l'Itanium?
 MS> Se hai voglia di discuterne apriamo un thread su microprocessori,
 MS> magari in un gruppo piu' adatto.
 
Grazie, ma non ne ho bisogno
 MS> ti sei gia' spinto oltre la definizione di VLIW, per esempio Elbrus 2k
 MS> non rispetta questa tua defizione  e a occhio e croce neanche il TriMedia
 MS> di Philips.
Ma pensa...se è per quello neanche i POWER di IBM rientravano troppo
nella definizione di RISC, eppure non si sbaglia certo di più
chiamandoli RISC che chiamandoli CISC...E poi Timedia è un DSP/Media
Processor travestito da general purpouse, Elbrus è tanto che ne non
ne sento parlare, ma anche questo mi pare debba ancora uscire.
 MS> stavolta la sciocchezza l'hai detta tu.
 MS> L'emulatore che gira su Crusoe e' un sw come tutti gli altri,  dire che
 MS> Cruso e' riprogrammabile e' come dire che su uno z80 posso caricare tutti i
 MS> programm che voglio.
 
 NO ! L'emulatore è scritto nell'assembly del processore nativo, ed
 accede all'architettura interna della macchina, progettata per
 l'emulazione di intere CPU, e non l'esecuzione diretta di programmi 
 utente.
 
 Ad essere riprogrammabile è il "modello di programmazione" presentato 
 al software in assebly: il sti di sitruzioni, i registri interi e FP
 (infatti i registri HW vengono usati come alias/renamed register x86
 dal SW Transmeta, quello che nonrmalmente viene fatto dall'hardware
 della CPU superscalare) ma anche tutto il sistema di acesso e protezione
 della memoria. Crusoe non ha i segmenti dell'x86, li "emula" via SW.
 
 MS> E' banale e non significa che lo z80 e' riprogrammabile.
 
 z80 non è ripogrammabile, tanto che set di istruzioni e di registri
 sono stampati nei libri. Lo stesso non si può dire dei processori
 emulati da CRUSOE, in tutto e per tutto definiti in _SOFTWARE_
 
 MS> Il mio x86 e' forse riprogrammabile perche' lo uso per giocarci a Mario64
 
 No, non hai capito la differenza...
 
 MS> Siccome ti diverti tanto a dare i compitini, ora e' arrivato il tuo turno
 
 Non solo mi diverto a scriverli e a darli, ma li correggo pure !
 
 MS> fare i compiti (non si finisce mai di imparare, dovresti saperlo):
 
 Da quando sono su Internet, dai gruppi italiani, i.c.a compreso, non
 ho mai imparato nulla, anzi, ho avuto solo da spiegare, correggere,
 raddrizzare torti, strigliare asini...
 MS> 
http://www.patents.ibm.com/details?pn=US05832205__
 MS> dovresti leggere (e possibilmente capire) questa roba invece di qualche
 MS> whitepaper per giornalisti.
 Arrivi tardi: ho già letto e streletto questo e altro su Transmeta,
 dai brevetti in poi, più di un anno fa. Allego sotto una spiegazione
 abbastanza dettagliata circolata ancora prima che uscisse il WP.
 MS> ciao,
 MS> Marco
---------------------
From: Matt Sergeant <mser...@ndirect.co.uk_NOSPAM>
Subject: Transmeta is _definitely_ the MMC
Given the info we had about possible dynamic emulation, it looks like
Transmeta's super secret chip is the MMC. Transmeta recently were given
a patent for a chip that can do dynamic emulation in hardware. However,
you're going to be dissapointed - the native code of the Transmeta chip
is x86...
See here: 
http://www.patents.ibm.com/details?pn=US05832205__&s_clms=1
for the patent, and here is a "translation" of what the patent actually
means: (thanks to sengan on 
slashdot.org
 for the "translation")
If one assumes Transmeta's patent refers to their work in progress,
Transmeta is building an emulation chip able to run x86 apps. This
confirms speculation based on Linus' remark about Java: "There is
already a binary standard: it's called x86". However, the processor
can also be used for Pcode, Java or Postscript making it the Emulator
writer's dream. Let's hope the language spec is kept open so that
emulators for many processors can be written. Native software
(Morphing software) is used to convert from the target instruction
set to the native instruction set, but unlike traditional CPUs, it
has hardware-assist such as the exception handling hardware the
patent describes. This allows it to use optimization strategies
written in software to improve throughput: a much more flexible route
than that taken by AMD and Intel which use predetermined hardware
optimization strategies.
Transmeta's patent simplifies maintaining state when instructions
have been reordered. The state at the instruction that caused the
fault must be determined even if instructions following it have
already been executed. Transmeta achieves this by using working
integer registers (and uncomitted memory stores), which may or may
not be comitted to the x86 registers (and memory) depending on
whether or not an exception occured. Comitting occurs on integral
instruction boundaries which I take to mean boundaries the state of
the native instructions and the host instructions happen to coincide.
Comitting appears to be the equivalent of a zero-cycle instruction.
Should an exception occur, the state at the last commit is restored
and the target instructions are translated and re-executed in order
to recreate a correct state when the exception reoccurs. The patent's
prefered embodiment uses 64 working integer registers and 32 working
floating point registers.
The patent describes hardware assist for memory mapped I/O (MMIO)
regions. Instructions accessing these regions may not be reordered
since the behaviour of one I/O location may depend on the contents of
another (say a index,value pair of MMIO registers). An optmization
strategy traditional emulators cannot use is to reorder memory
accesses which is only safe if accessing main memory: recall that in
C, volatile is used to give the compiler more chances to optimize,
but volatile does not exist in machine code. Transmeta's native
instruction set includes memory accesses that will cause an exception
if an address refers to a MMIO region (achieved by adding a MMIO bit
to the TLB which states whether or not a memory region is MMIO). Thus
the Morphing software can aggressively optmize all target
instructions assuming non MMIO, but recover where the assumption
fails, and retranslate the code appropriately. A similar process
allows target variables to be kept in registers instead of memory.
The patent claims a preferred embodiment of the native instruction
set is VLIW because VLIW instruction sets are easy to parse and allow
one to specify what each of the execution units is doing at any
cycle. A cache of translated instructions is kept either on chip or
in main memory. The die includes only one CPU which translates and
executes the translated code. No performance gain would be achieved
by having a second processor to do the translation since Transmeta's
studies indicate that "the translation for a target instruction (once
completely translated) will be found in the translation buffer all
but once for each one million or so executions of the translation".
In the case of code that often generates exceptions, both the
reordered and the in-order translation may be cached. The prefered
embodiment uses a 2 Meg cache.
The patent describes hardware assist to detect self-modifying code
due to a CPU-writes or DMA writes to areas of code with cached
translations. A write-protection bit is added to the TLB to specify
that the translation code will go stale if the TLB entry's page is
written to. Writing to a write-protected page causes an exception,
just like the read-only bit of the x86's page table.
The patent finishes with an example showing a while loop of 10 x86
instructions being translated into native instructions. Every X86 EIP
update and every general protection fault check is expressed as an
explicit instruction. In general this translation increases
instruction count six fold. Further optmization however reduces this
down to two-fold, with the equivalent of only 2 core instructions
being in the loop. Recall that 6 instructions can be packed into one
VLIW instruction. The general optimization technique is: be
optimistic and fix it if it turns out the assumptions were wrong.
-- 
<Matt/>
---------------------------------------------------------
	Sergio Ruocco - 
ruo...@comm2000.it

  abbastanza dettagliata circolata ancora prima che uscisse il WP.
non basta leggerlo ,devi anche capirlo.
E non serve (come del resto sempre fai) quotare quello che dicono gli
altri per non esporti in prima persona.
Pensi sia cosi' 'cool' ricorrere sempre al principio d'autorita'?
Avrai mica paura di misinterpretare i brevetti e prendere cantonate?
Se tanto volevi quotare una recensione dei brevetti potevi quotare i miei
post di piu' di anno fa, sia su questo gruppo che su it.comp.hardware.cpu,
che scusa l'immodestia, sono decisamente piu' descrittivi e meglio
argomentati
di quelli cmq buoni di Matt che ha fatto solo un mini riassunto, tanto che
si capiva
di piu' dall'abstract del brevetto.
Ma dimenticavo, tu sei troppo occupato a correggere i compiti degli altri
che
oramai non hai piu' il tempo di  fare i tuoi.
Gia' che ci sei potresti una volta ogni tanto invece che lodare  questa o
quella
tecnologia andare un po' piu' oltre e cercare di capire dove sono i limiti e
i drawbacks..che pure quella di Transmeta,come tutte, ha.
Per esempio dire che Crusoe si ciuccia da 8 a 16 mega di ram per
l'emulazione
non sarebbe male, considerando anche che la ram nei portatili e nei pda si
paga a peso d'oro e che l'uso di ram aggiuntiva consuma energia, che
guardacaso Transmeta si e' dimenticata di conteggiare nei suoi benchmarks
fatti ad-hoc, ops!
E ancora, Transmeta e' fabless e quindi pure i loro processori saranno
parecchio
costosi, ri-ops!
Nominare e incensare n tecnologie ora per poi dire k anni dopo 'io l'avevo
detto
che sarebbe successo, avevo ragione' perche' una di queste ha sfondato e' il
tipico
gioco che fanno i tanti ciarlatani che leggono le carte sulle tv regionali,
e' veramente
un giochetto troppo facile da attuare, quindi sarebbe anche ora di
smetterla.
Quando fai previsioni, argomentale e falle con tanto di  data di scadenza
dopo
la quale l'uso diventa sconsigliato al consumatore.
ciao,
Marco

 ...si attede INTEL Itanic - il DOMINATORE DEI 64 BIT - da appena 3
Non era il Merced intel-HP? :-)
--
--
Giuseppe Gigante

 ha scritto nel messaggio
news:8nc6mt$2mf$3...@nslave1.tin.it...

ora si chiama Itanium, ma siccome qualcuno prevede che sara'
un disastro e' stato rinominato scherzosamente Itanic :)
ciao,
Marco

> No, forse no...
Mi permetto umilmente di dire la mia su questo piccolo punto in quanto ho
usato ed utilizzo sia pcAnywhere che VNC (quest'ultimo l'ho pure provato
sull'Amiga per controllare uno dei servers che abbiamo in ufficio... ho un
bel grab del mio WB con un bel WinNT in finestra... :-)
Entrambi sono semplicemente dei remote controller ed è quindi ovvio che
"riportino" tutto il desktop con mouse e tastiera ma NON permettono di
condividere la stessa sessione host su più client.
pcAnywhere, essendo commerciale, è più protetto e semplicemente non permette
un secondo collegamento; VNC, che è gratis, semplicemente sconnette il client
precedente.
No, non sono proprio delle baggianate in quanto ti permettono la gestione
remota di una macchina, cosa che garantisco essere una manna dal cielo quando
devi gestire un parco di macchine sparse in tutta Italia, siano essi
portatili con win95 o servers in sedi distaccate... più volte ho detto che
dovrebbero fare un *monumento* a quelli che per primi hanno avuto l'idea dei
seguenti programmi: pcAnywhere, Ghost, PartitionMagic :-)
    Ciao, Giangi
--
/MotorCycle travels/    
http://www.geocities.com/TheTropics/Paradise/6362/
Reverse (right to left) the domain to write me...
(PGP key available, send email with "PGP Key request" in subject)
--
Thanks to the Italian law 675/96 regarding the *privacy* it's absolutely
forbidden to use my address for unsolicited messages. Even if this address
has been extracted from /public domain/ sites/newsgroups.
--
=|:-)   Abe Lincoln

seguenti programmi: pcAnywhere, Ghost, PartitionMagic :-)
ghost in particolare ;)
bye, bye
  Ale Gerelli
 
a...@gerelli.it

>seguenti programmi: pcAnywhere, Ghost, PartitionMagic :-)
 AG> ghost in particolare ;)
Bhe... anche PM non scherza mica! :-) Sapessi quanto mi piacerebbe averlo
sull'Amiga! :-|
    Ciao, Giangi
--
/MotorCycle travels/    
http://www.geocities.com/TheTropics/Paradise/6362/
Reverse (right to left) the domain to write me...
(PGP key available, send email with "PGP Key request" in subject)
--
Thanks to the Italian law 675/96 regarding the *privacy* it's absolutely
forbidden to use my address for unsolicited messages. Even if this address
has been extracted from /public domain/ sites/newsgroups.
--
:-f sticking tongue out

  nel giro di 5 anni non avranno più ragione di esistere...
Se tra 5 anni si stara' ancora a discutere di queste futilita', invece di
pensare a problemi ben piu' seri, dubito si sara' fatto il benche' minimo
progresso (siamo gia' ora pienamente ancorati a tecnologie di 20, 30 o 50
anni fa).
Per la cronaca, Crusoe non e' ne' una CPU virtuale (e' un x86), ne'
riprogrammabile (se non dal sig. Edmundo Transmeta).
-- 
 "Without deviation from the norm, progress is not possible." (F. Zappa)
 Rudi Chiarito         SGML/XML, user interface, i18n         Amiga Inc.
 
ru...@amiga.com
 
http://amiga.com/

riprogrammabile (se non dal sig. Edmundo Transmeta).
 Si sa qualcosa sulla versione Crusoe/PPC a cui era interessata Apple ?
Saluti.
--
    _
 Fa/_)io         - Amiga Group Italia -
  /__)enedetti   
http://www.amyresource.it/AGI/
/...ma febbraio mi ha fatto rabbrividire/

 non c'è neppure il cambio di stato della CPU.
Veramente su *nessun* sistema alla semplice chiamata di una libreria c'è
un cambiamento di stato del processore. Inoltre il sistema usato da
AmigaOS per le librerie (jump table contro linking dinamico) è poco
efficiente in termini di tempo macchina, in quanto c'è bisogno di due
salti prima di arrivare al codice vero e proprio e questo ha effetto
sull'uso del'istruction cache e su varie altre ottimizazioni che i
processori possono effettuare.
Saluti,
Fabio Alemagna

  Si sa qualcosa sulla versione Crusoe/PPC a cui era interessata Apple ?
in una intervista di poche settimane fa il CEO di Transmeta, David Ditzel,
diceva che era altmente improbabile la loro entrata su mercati differenti
da quello dei cloni x86, almeno per ora.
ciao,
Marco

 processori possono effettuare.
beh, l'instruction cache non c'entra molto, piu' che altro i danni
sono provocati dal primo dei 2 salti che e' fatto con
un indirizzamento indiretto, il che proibisce alla BPU di fare
il suo lavoro causando un completo stallo della pipeline
principale del processore.
Su 040/060 te ne freghi, tanto la pipe e' cortissima, ma di certo
questo approccio non andrebbe usato sugli ultimi cloni x86
che hanno pipe fino a 20 stadi (P4)
ciao,
Marco

 riprogrammabile (se non dal sig. Edmundo Transmeta).
amen
ciao,
Marco


Nulla ti vieta di scrivere il TUO codice in nativo. Si perde
portabilità? Mah... non ci sarebbe comunque la portabilità, in quel
caso, quindi non vedo il problema.
Nei casi più generali va bene la libreria, poichè si può benissimo
scrivere una libreria per ogni tipo di processore supportato (lo si
dovrebbe fare comunque anche se fosse direttamente il VP a supportare
quelle istruzioni).
Ancora una volta io vedo solo vantaggi da questo punto di vista, non
svantaggi.
Saluti,
Fabio Alemagna

 svantaggi.
regola fondamentale dell'universo: ogni approccio ad un problema
ha i suoi pro e i suoi contro, se non vedi i contro vuol dire che non
stai guardando bene (oppure sei 'cieco') :-)
ciao,
Marco

 stai guardando bene (oppure sei 'cieco') :-)
io ho scritto "da questo punto di vista". 
Io trovo un vantaggio poter scrivere in nativo solo le piccole parti del
mio programma che lo necessitano, non uno svantaggio.
Con Elate/Ami posso fare tutto quello che posso fare con qualsiasi altra
architettura, non è vero il contrario.
Saluti,
Fabio Alemagna

 architettura, non è vero il contrario.
evvai..il sacro graal :)
ciao,
Marco

 evvai..il sacro graal :)
Quale sacro graal... Scusa Marco, anzichè fare del sarcasmo, perchè non
rispondi?
Saluti,
Fabio Alemagna

 rispondi?
non e' sarcasmo, mi fa solo ridere la tua cieca fiducia in una
tecnologia di cui hai solo sentito parlare e che ancora non
ha dimostrato un bel nulla.
Io stravedo per Transmeta e per la loro tecnologia, ma non per questo
sto tutto il tempo ad incensarli e a credere che il loro approccio sia privo
di difetti, come invece fai tu con TAO.
ciao,
Marco

 di difetti, come invece fai tu con TAO.
Che faccio io? Guarda, laciamo stare che è meglio...
Saluti,
Fabio Alemagna

 cui stiamo parlando adesso.
allora illustrami gli altri svantaggi inerenti la tecnologia di TAO perche'
fin'ora credo di non avertene mai visto citare nessuno.
ciao,
Marco

>  va quasi benissimo.
 RC> Mah... 
Questo è quello che dice Haynie, io non sono d'accordo:  quasi quasi
si potrebbero indicare le righe di codice che non faranno MAI essere
Linux un vero sistema RT.
 RC> Certo, salvo poi diventare inutilizzabile perche' il processo di X si e'
 RC> gonfiato a dismisura e "assorbe" tutta la memoria - mi e' capitato almeno
 
 Se ci fai real-time non lanci X, è ovvio...
 
 RC> Non mi pare che il rapporto prestazioni/Watt di Transmeta sia tanto
 RC> diverso da quello di uno StrongARM. Con la piccola differenza che
 RC> StrongARM e' disponibile da una vita - e per giunta puoi prendere
 RC> facilmente il nucleo, affiancargli unita' aggiuntive e piazzare il tutto
 RC> in un singolo chip. Oggi.
 
 StrongARM non è compatibile X86, e non è nella stessa classe di
 potenza del Transmeta, e forse non è altrettanto scalabile.
 
 RC> Se tra 5 anni si stara' ancora a discutere di queste futilita', invece di
 RC> pensare a problemi ben piu' seri, dubito si sara' fatto il benche' minimo
 RC> progresso (siamo gia' ora pienamente ancorati a tecnologie di 20, 30 o 50
 RC> anni fa).
 
 Certo, ma questo è il destino: lo stato dell'arte della ricerca è
 "digeribile" tecnologicamente e industrialmente non prima di 15-20
 anni, almeno nell'informatica.
 
 RC> Per la cronaca, Crusoe non e' ne' una CPU virtuale (e' un x86), ne'
 RC> riprogrammabile (se non dal sig. Edmundo Transmeta).
 
 Sono modi di dire per spiegare la differenza tra implementazioni
 hard (tradizionali) e "soft" (Transmeta) di una CPU+modello di
 programmazione. Anche la "memoria virtuale", dopotutto, sta su
 disco...
	Sergio Ruocco - 
ruo...@comm2000.it

 caso, quindi non vedo il problema.
Se proprio Marco ci tiene a compilare, come fa ora, il codice in nativo
usando le nuove ottimizzazioni vettoriali del gcc, senza scrivere nulla a
mano, puo' fare lo stesso con un crosscompilatore. Prima crea la versione
generica con vpcc, poi col crosscompilatore MMX, Altivec o cos'altro
genera i tool ottimizzati. Nulla glielo impedisce. ;)


> non c'è neppure il cambio di stato della CPU.
Nemmeno su altri sistemi operativi c'e' un cambio di stato quando chiami
una funzione di libreria. Forse confondi chiamate di libreria con chiamate
di sistema?
"Costosa" non e' un termine forte. Se avessi davvero messo a confronto gli
approcci di AmigaOS, Elate/VP ed altri sistemi operativi, non avresti
fatto altro che dire lo stesso.
Lo faro' io per te (si parla di librerie dinamiche):
a) AmigaOS
Un programma chiama una funzione di libreria, che per convenzione e' del
tipo
   jsr -xyz(a6)
La CPU salta all'indirizzo in questione, che si trova all'interno della
tabella dei salti della libreria e che pressoche' sempre e' del tipo
  jmp indirizzo_della_funzione
Costo della chiamata: due salti, di cui il primo relativo (ancora piu'
costoso). Le pipeline del processore sentitamente ringraziano per il
lavoro aggiuntivo. Se c'e' un patch (o piu' di uno), il costo diventa ben
piu' pesante - sappiamo bene la popolarita' dei patch nel mondo Amiga.
b) altri OS (SystemV/ELF, etc.)
Una chiamata ad una libreria dinamica ha la forma
  jsr indirizzo
che corrisponde a un elemento nella tabella di salti _del programma_, che
viene generata dal compilatore e risiede in una apposita sezione del
binario ELF. A questo punto ci sono due possibilita'. Se il sistema usa il
cosiddetto lazy binding, all'indirizzo di cui sopra c'e', la prima volta
che la funzione viene chiamata, del codice del tipo
  move #xyz,registro
  jmp  indirizzo2
Il codice che si trova ad indirizzo2 ricerca l'indirizzo della funzione
avente numero xyz e rimpiazza le due istruzioni di cui sopra con un salto
assoluto; dopodiche' vi salta. Quindi, per la prima chiamata c'e' un costo
piuttosto alto, ma dalla seconda in poi ci sono solo due salti assoluti
(niente salti relativi): il jsr e il jmp generato al volo (e' codice
automodificante.. brrr).
Se invece il sistema non fa uso di lazy binding, il loader ELF ricerca gli
indirizzi di tutte le funzioni (anche quelle che non verranno mai chiamate
nel corso dell'esecuzione) e genera una tabella di salti assoluti. In
questo caso, il costo e' sempre di due salti, ma c'e' un po' piu' di
lavoro effettuato quando il programma viene caricato in memoria. Se c'e'
abbastanza memoria, il programma rilocato non sara' mai liberato e si
potra' lanciarlo decine o centinaia di volte, senza riaccedere al file
binario su disco. E' un po' come i programmi residenti di AmigaDOS, con la
non trascurabile differenza che e' il sistema operativo a fare il tutto
automaticamente.
c) VP con tool di tipo embeddable
Nel sorgente e nel binario ci sono chiamate del tipo
  qcall xyz,(parametri : risultati)
Nel codice tradotto, il codice del metodo xyz viene incluso in linea,
senza alcun salto. Equivale alla parola chiave inline (o __inline) del
linguaggio C; con quest'ultimo, pero', lo si puo' fare solo quando la
funzione invocata e' presente nello stesso file sorgente (direttamente o
tramite #include). Men che meno e' possibile farlo con codice
precompilato. 
Ovviamente tali tipi di tool vanno creati con parsimonia. Ne' avrebbe
tanto senso creare un metodo del genere per l'equivalente di Read/Write,
perche' il costo di un accesso al disco (o un dispositivo di rete o
quant'altro) annulla piu' che abbondantemente il risparmio di due salti
(ma anche tre, quattro o cinque). Nessuno promette che salveranno il mondo
dall'effetto serra, ma possono tornare utili in molti casi.
Dicevi?


un cambiamento di stato del processore.
 Sì, è vero. L'abitudine ad AmigaOS mi fa pensare alle chiamate ad
una libreria, come chiamate a funzioni del SO.
 La mia domanda non era questa in effetti.
 La jump-table ha i suoi vantaggi, come quello di tenere in memoria
una sola copia della libreria per tutti gli applicativi che la richiedono
e la facilità nella sostituzione di funzioni (basta modificare la tabella).
 E` vero che ormai la memoria può non essere un problema, ma se "x" è la
quantità di memoria del mio sistema, compresa tra 0 e +oo , per me è
comunque importante sapere che neppure un byte viene sprecato.
 E tuttavia non mi sembra che parlare di linking-dinamico (DLL di
Windows), rappresenti una grossa novità.
Saluti.
--
    _
 Fa/_)io         - Amiga Group Italia -
  /__)enedetti   
http://www.amyresource.it/AGI/
/...Ea enim elatio, si iustitia vacat pugnatque, in vitio est/

 FB> Nel Duemila del Signore, Fabio Alemagna, aveva scritto:
 FB>  E` vero che ormai la memoria può non essere un problema, ma se "x" è la
 FB> quantità di memoria del mio sistema, compresa tra 0 e +oo , per me è
 FB> comunque importante sapere che neppure un byte viene sprecato.
 
 Ogni byte non utilizzato è un byte sprecato.
	Sergio Ruocco - 
ruo...@comm2000.it

 genera i tool ottimizzati. Nulla glielo impedisce. ;)
E' quello che gli ho detto io, ma lui dice "e allora se pure con Ami
devo compilare in nativo, a che mi serve?"
Saluti,
Fabio Alemagna

 fin'ora credo di non avertene mai visto citare nessuno.
Illustrameli tu, visto che a quanto pare è il tuo compito. Ovviamente
svantaggi che non siano quelli di cui tu vai parlando in questo thread.
Saluti,
Fabio Alemagna

 genera i tool ottimizzati. Nulla glielo impedisce. ;)
il punto non sono i tool ottimizzati, il punto e' il codice che fa da
collante
tra il codice generico e i tool ottimizzati, e' li che vanno inserite quelle
particolari istruzioni.
Se non lo fai e il codice che hai linkato assume che ci siano (come nel
caso di tool nativi ottimizzati) le prestazioni vanno a puttante perche'
vengono prefetchati di continuo dati che verranno usati solo in iterazioni
successive mentre all'ingresso del loop di calcolo il codice
si aspettava che gia' le cache fossero riempite col dato che serviva (che va
precaricato o meno prima chiamare le funzioni della lib, dipende da come
e' fatto il codice di contorno), risultato: il processore e' costretto
a fetchare da solo i dati di cui hai bisogno dalla ram,il bus si satura
perche' e' in corso
il prefetch per l'iterazione seguente che in quel momento e' totalmente
inutile,  la cpu
stalla e molto probabilmente se la cpu sta cachando in L1 (che di solito
sono 2-way associative
e tieni conto che  un registro vettoriale e' lungo gia' mezza cacheline)
il prefetch viene subito invalidato appena la transazione sul bus del dato
che effettivamente serve
viene ultimata.
In questo modo entri in un circolo vizioso che rende il codice simd piu'
lento di quello
sisd, il che non e' bello :)
Questo (del prefetch) non e' solo un problema di TAO ma di tutti i
compilatori
in generale perche' le informazioni utili al compilatore per effettuare
queste ottimizzazioni
non le puo' trovare  nel codice oggetto, ma deve estrarle dal sorgente.
Ergo si torna al discorso che ti avevo fatto precendentemente, ovvero
realizzi
delle funzioni nella tua lib ottimizzata che contengono gia' le istruzioni
di prefetch
e tutto il codice di 'startup' corretto ma per farlo perdi in flessibilita'
perche'
per quante funzioni tu possa implementare una soluzione gia' pronta avra'
un approccio ad un determinato problema piu' o meno fisso e poco
malleabile.
ciao,
Marco

 svantaggi che non siano quelli di cui tu vai parlando in questo thread.
cavolo..sono mesi che cito difetti (o limitazioni, che e' meglio), ora
tocca a te :)
ciao,
Marco

Dicevi?
 Dico che non mi hai risposto alla domanda riguardo alle infinite
copie della libreria che potrebbero risiedere in memoria, ma sarà
una questione di poco conto.
 Aggiungo anche che per ottenere la stessa cosa, visto che si
perdono diversi vantaggi di una libreria dinamica in stile AmigaOS,
potrei benissimo utilizzare una libreria statica da linkare al mio
oggetto (ovviamente solo le funzioni utilizzate).
Saluti.
--
    _
 Fa/_)io         - Amiga Group Italia -
  /__)enedetti   
http://www.amyresource.it/AGI/
/...smarrisce il bel volto in un colore, non pallidezza, ma candore/

 Ogni byte non utilizzato è un byte sprecato.
 E` chiaro che ogni byte non sprecato per tenere inutilmente "n" copie
della stessa libreria, può essere utilizzato per tutt'altro genere di
cose.
Saluti.
--
    _
 Fa/_)io         - Amiga Group Italia -
  /__)enedetti   
http://www.amyresource.it/AGI/
/...entrarono Pompeo e Lepido, in assetto da guerra/

 tocca a te :)
Tutte le tue aromentazioni vertono su *questi* (ipotetici) difetti, ora
illustremene altri.
Saluti,
Fabio Alemagna

 illustremene altri.
 e no..stavolta tocca a te fare la parte del cattivo!
******************************************
Marco  'nAo'  Salvi
Bologna University - Department of Physics
mar...@cadvlsi1.df.unibo.it
******************************************

 di startup VP per Elate? nulla!
ok... siccome mi rendo conto che questo thread non porta a nulla (e
quando mai :D) io la finisco qui. Sinceramente, mi sono scocciato. Non
ci provo tanto gusto nell'advocacy. Lasciamola fare a che ne ha il
diritto: Rudi, ci sei?
Saluti,
Fabio Alemagna

 diritto: Rudi, ci sei?
KO tecnico? :-) (doppia battuta carpiata con mezzo avvitamento)
ciao,
Marco


 KO tecnico? :-) (doppia battuta carpiata con mezzo avvitamento)
pensala come vuoi, io la mia risposta te l'ho data: mi sono scocciato. A
te l'ultima parola.
Saluti,
Fabio Alemagna

 malleabile.
MathEngine offre funzioni sia di alto che di basso livello ed e'
estremamente flessibile. Puoi provare a registrarti presso il loro sito,
mi pare offrano una versione alfa del nuovo toolkit, cosi' potrai renderti
conto di come funziona. Ovviamente la versione per Elate sara' diversa da
quelle attuali (Windows e PS2).


  Si sa qualcosa sulla versione Crusoe/PPC a cui era interessata Apple ?
E' la prima volta che ne sento parlare. Non credo abbia tanto senso,
perche' i PPC consumano gia' di proprio meno degli x86 - G4 esclusi.
E' una voce fondata, o si tratta dei soliti sogni di utenti Mac/Amiga?
