Newsgroup: it.comp.hardware.cpu
Titolo: Athlon 64

Quale sarà il prezzo di un athlon 64 di fascia bassa?
--
antoni...@libero.it

Curiosità:  come va su Windows XP, ovvero su un sistema operativo non a 64
bit ?

 bit ?
non ci va.........ci sono versioni di winxp a 64bit,puoi utilizzare app a
32bit ma non l'os......o almeno a quanto ricordo :-P
--
"Io ne ho viste cose che voi umani non potreste immaginarvi...
navi da combattimento in fiamme al largo dei bastioni di Orione..
..ho visto i raggi B balenare nel buio vicino alle porte di Tannhauser...
e tutti quei momenti andranno perduti nel tempo, come lacrime nella pioggia"
ICQ:42964371

 32bit ma non l'os......o almeno a quanto ricordo :-P
Possiedo XP a 32 bits... posso aggiornarlo alla versione a 64 bit o ci sono
"impedimenti" ?


aggiornarlo?? meglio formattare,ma poi tu possiedi anche winxp a 64bit??


 32bit ma non l'os......o almeno a quanto ricordo :-P
Athlon64, cosi` come Opteron, e` in grado di funzionare in 5 modalita`
differenti.  2 a 32 bit e 3 a 64 bit.
32 bit legacy, 32 bit pura, 64 bit legacy, 64-32 e 64 pura.
Ovvero ci funge sopra tutto quello che vuoi senza nessun cambiamento.
-- 
try: troll.uses(Brain)
except TypeError, data: 
   troll.plonk()
Linux User #310274, Debian Sid Proud User

 sono "impedimenti" ?
Dipende da cosa intendi per "impedimenti"! ;)
Se intendi "impedimenti" tecnici, ovvero eseguire un aggiornamento ebbene 
si ci sono problemi. L'architettura di un 64bit e' completamente diversa da 
un 32.
Cmq e' assolutamente inutile avere un processore e un SO a 64bit se poi non 
si hanno applicazioni a 64bit da farci girare. Leggete bene il datasheet di 
XP64, le applicazioni a 32bit vengono eseguite in un sottosistema emulato 
come succede per le applicazioni a 16bit sulle versioni di windows a 32bit.


si,ma non l'os..........


 come succede per le applicazioni a 16bit sulle versioni di windows a 32bit.
Non e` assolutamente vero. Ma chi ve le dice ste cose?
Un processore a 64bit porta giovamenti a qualsiasi sistema a prescindere
in quanto semplifica la gestione della memoria. Leggilo tu il datasheet di
AMD64, le applicazioni a 32 bit non sono affatto emulate ma sono eseguite
in modo nativo. AMD64 e` un'estensione dei 32bit che in caso di
attivazione di un flag (che viene attivato solo se il sistema operativo e`
a 64bit) decide se girare a 32 o 64bit. A 32 bit siamo messi come lo siamo
ora, una sorta di nuovo Athlon con qualche modifica qua e la`, sempre
modifiche pesanti ma e` comunque un 32bit purissimo. Se invece viene
attivato il flag si passa alla "zona" 64 bit dove il processore ha altre
modalita` tra cui legacy (con supporto anche ai 16 bit), mista (solo 64 o
32) e pura a 64. Tutto questo avviene tramite attivazione di un registro
interno del processore che agisce da flag. Questo e` molto semplificato
ovviamente ma la cosa funziona in questo modo.
emulato? Non e` mica un Itanium... Non ha bisogno di emulare visto che e`
gia` in buona parte uguale a un x86...


 si,ma non l'os..........
Si, anche l'OS.
Altrimenti avrei giusto 2 o 3 cosette da chiedere, non perche` non le so,
ma giusto perche` mi piacerebbe vedere che spiegazione mi dai.


 si,ma non l'os..........
E visto che mi hai pure fatto andare a cercare immagini e leggere
datasheet almeno guarda questa immagina qua che spiega le modalita` di
funzionamento di Opteron.
http://images.anandtech.com/reviews/cpu/amd/x86-64/opmodes.gif
Ma chi vi ha messo in testa ste storie che andate dicendo?
Se lo sa Gabriele... >:>


 aggiornarlo?? meglio formattare,ma poi tu possiedi anche winxp a 64bit??
E che ne so io... non l' hai detto tu che esiste?

 gia` in buona parte uguale a un x86...
In parole povere, le prestazioni sono "giovate" anche sotto un semplice
Windows XP a 32 bits?
Esiste qualche benchmark?
No.. perchè se decidessi di passare all' Athlon 64 per guadagnare l' 1% di
potenza rispetto all' Athlon XP per il fatto che non ho OS e/o applicazioni
a 64 bit, allora aspetto e vaffanculo.
Aspetto commenti e suggerimenti.


guarda che io non ti ho fatto cercare proprio niente...........
bye
toky

 a 64 bit, allora aspetto e vaffanculo.
AMD ha introdotto il MN per fare in modo che i processori fossero
classificati in base ai loro risultati in una certa cerchia di test. Se il
futuro Athlon 64 a 2Ghz si dice che avra` un MN di 3400+ significa che
avra` le prestazioni di un Barton con ipotetico MN di 3400+ ovvero non
troppo superiori.
Esistono benchmark ovunque ma sono di Opteron e non di Athlon64. Il
passaggio a 64bit non porta miglioramenti prestazionali, porta anzi
peggioramenti. K8 pero` nel passaggio a 64bit introduce nuovi registri e
altre migliorie che gli fanno guadagnare ancora in prestazioni una volta
passati a 64bit.
A prescindere dal fatto che non ho idea di cosa possa servirti un Athlon64
(non hai gia` abbastanza potenza ora?) non puoi certo aspettarti un
incremento del 200%... Diciamo che ripetto al Barton 3200+ sara` in media
l'8-9% piu` veloce, _IN MEDIA_, ovvero ci saranno applicazioni in cui va
meno e altre in cui va di piu`, ma la loro media lo rendera` piu` veloce.


 ma giusto perche` mi piacerebbe vedere che spiegazione mi dai.
ma perchè a quest'ora tarda devo leggere ste cose?? mi sento come sollevato
da tergo, tipo PRESO PER IL CULO..........
bye
toky
ps:se non l'avessi capito io non ho detto niente :-|

 
Se abbiamo una discussione il minimo che posso fare e` andare a prendere
le mie fonti... Non vedo motivo di scaldarsi, era solo una battuta.


 ps:se non l'avessi capito io non ho detto niente :-|
Lo so... Scusami se ti sono sembrato rude, erano solo battute ma mi
accorgo di essere un po` acido dopo tutti gli esami che ho dato (l'ultimo
e` domani)...



siiiii,lo so,ma io se guardi i post non ho detto niente di anomalo,ho solo
detto che un procio a 64 bit gli server un os a 64bit,le app lo so che vanno
in emulazione :-)
sivvome poi mi hai pure scritto voglio chiederti altre cose tanto per vedere
cosa midici come se mi volessi scommettere..........
bye
toky

 meno e altre in cui va di piu`, ma la loro media lo rendera` piu` veloce.
Allora non ti sembra il caso che si potrebbe ancora "spremere" gli attuali
processori a 32 bit , prima di passare all' Athlon 64 ed all' Opteron?
Credo che si potrebbero creare processori molto piů potenti di ora con le
stesse tecnologie a 32 bit: tipo degli Athlon XP 3400+, 3600+, 4000+ ecc...
Pensi che rientrino nei piani dell' AMD o la cosa finisce col 3200+ ?

 cosa midici come se mi volessi scommettere..........
azz... :).
Athlon64 non e` a 64 bit completamente. E` esteso a 64bit ovvero ha sia i
32 che i 64. Non ha bisogno di emulare.
Per andare a 64bit pero` serve l'OS a 64bit, ma non e` obbligatorio averlo
per usare un Athlon64, posso usare anche windows xp attuale senza cambiare
nulla.


 Pensi che rientrino nei piani dell' AMD o la cosa finisce col 3200+ ?
Athlon e` giunto alla fine e piu` di cosi` non gli si puo`
chiedere... Esiste dalla versione a 500Mhz e ora abbiamo superato i
2200Mhz, quasi 5 volte la frequenza di partenza con un IPC altissimo. Non
credo esistano processori che sono sopravvissuti cosi` a lungo
praticamente inalterati mantenendo prestazioni cosi` elevate.
AMD ad ogni modo non credo salira` sopra i 3200+ con la fascia a 32bit.
Di 3400+ ci saranno solo gli Athlon64.


stesse tecnologie a 32 bit: tipo degli Athlon XP 3400+, 3600+, 4000+ ecc...
E quando lo facciamo sto maledetto salto se no?
Devi solo aspettare che gli sviluppatori scrivano codice a 64bit...con
tool a 64 bit...e allora li si che si nota la differenza
-- 
Lawrence "Rhymes" Oluyede
http://loluyede.blogspot.com
XmlDesk - 
http://tinyurl.com/fhrz
 - for Xml developers
UGIdotNET - User Group Italiano .NET - 
http://www.ugidotnet.org

 e ricordi piu' che bene.
ma non diciamo cazzate per favore. ATH64 è perfettamente compatibile con
tutto il codice x86 a 32 bit. Punto.


ecco quello che mi sfuggeva,e che è il mio unico post anche :-) quindi si
pui installare anche un os a 32bit e la cpu "va a 32bit"?
bye
toky

praticamente inalterati mantenendo prestazioni cosi` elevate.
Beh, l'architettura P6 è partita dal Ppro 150 / PII 233 ed è arrivata
fino a 1.3 GHz... :-)
Senza contare che è stata ripresa dal Banias, ma immagino ci siano
state parecchio modifiche
-- 
ZHELGADIS THE LIGHTBRINGER (ICQ 33134824)
BAG #008,DPPSJ #000,BAT #013,TFC #012, GAMERDA #026
"Aspettare non è mai stato un problema, per me.
Posso trascorrere piacevolmente ore e ore con l'aiuto di un buon caffè"

 fino a 1.3 GHz... :-)
ma aassolutamente no, è cambiato un sacco quel processore mentre Athlon è
fondamentalmente rimasto uguale a sè stesso per tutto il tempo.

 gia` in buona parte uguale a un x86...
si dalle descriziomi parlano proprio dell'itanium, os dedicato ed
emulazione schifosa per i 32 bit

fondamentalmente rimasto uguale a sč stesso per tutto il tempo.
Cosa?
Il cambio c'č stato dal PPro al PII (pipeline piů lunga se non sbaglio
e un miglir supporto al SW 16 bit), per il resto?
PII -> PIII Katmai: istruzioni SSE (come per l'Athlon XP)
Katmai -> Coppermine: cache L2 integrata nel die di 256k, con bus a
256bit vs 64 (l'integrazione č avvenuta nel passaggio K75->
Thunderbird; il bus purtroppo č fermo a 64 bit pure nei K8..)
Coppermine -> Tualatin: cache a 512k (come nel Barton)
Oltre ai vari cambi di processo produttivo (0.35 - 0.25 - 0.18 -
0.13Cu per il P6, 0.22 - 0.18Cu - 0.13Cu per il K7), ovviamente
Allora, quali sono le differenze sostanziali? Non a caso si parla
sempre di architettura P6...
-- 
ZHELGADIS THE LIGHTBRINGER (ICQ 33134824)
BAG #008,DPPSJ #000,BAT #013,TFC #012, GAMERDA #026
"Aspettare non č mai stato un problema, per me.
Posso trascorrere piacevolmente ore e ore con l'aiuto di un buon caffč"

 se il sistema operativo e` a 64bit) decide se girare a 32 o 64bit. A
Io non parlavo del datasheet del processore, ma del SO. Quando parlo di 
emulazione parlo solo di SO. Attualmente i Windows NT per eseguire le 
applicazioni DOS, OS/2 1.x, Win16bit, POSIX, ha tanti sottosistemi 
dedicati che le fanno girare ma in maniera non nativa. Non sto parlando 
di processore ma sto parlando di SO. WinXP64 e' stato sviluppato secondo 
questa logica, ovvero le applicazioni 64bit girano a livello SO mentre 
tutte le altre girano in un sottosistema dedicato, il sottosistema altro 
non e' che un'applicazione a 64bit che fornisce meccanismi di passup tra 
applicazioni di vecchio tipo e il SO. Questo significa che tutte le 
applicazioni a 32bit girano in XP64 in un sottosistema dedicato a 32bit, 
cio' posto la sicurezza di funzionamento si abbassa perche' tutte le 
applicazioni andranno a dividersi una stessa istanza di questo 
sottosistema, quindi se ne crasha una le altre ne saranno profondamente 
affette.

 affette.
Ma per favore... Ma tu sai come funziona un OS? K8 e` in grado di
funzionare a 64bit ma facendo girare software a 32 usando la modalita`
protetta e solo quella. Modalita` reale e virtuale non riesce a
usarle. Usandolo invece a 32bit riesce a funzionare in tutte e tre le
modalita`.
Non c'e` nessun sottosistema dedicato o meglio, se microsoft decide di
fare ste cazzate peggio per lei, linux non ce l'ha e questo basta per dire
che quelle di microsoft sono scelte e che se vuoi portami qualche dato il
sito microsoft non ha importanza per i processori. Il sistema operativo
passa il programma al processore e lui si preoccupa di eseguirlo.
Se un programma crasha gli altri sarebbe bello che restino in piedi, e
credo proprio che fara` cosi` anche stavolta. Questa funzionalita` dipende
dalla protezione della memoria.
Io che uso linux e non ho tutte ste cagate ma posso passare con
tranquillita` da x86 a x86-64 compilando pian piano le mie applicazioni
man mano che mi serve vado contro le regole?
Non ci posso credere... Mi si spiega come funziona un processore passando
dal sito microsoft, scarcati il datasheet di Opteron, leggilo e poi
pentiti di quello che hai scritto...
Se ti sente Gabriele...


 pui installare anche un os a 32bit e la cpu "va a 32bit"?
Si, non per niente sui primi prototipi presentati alle varie fiere
facevano girare Linux (in modalita a 64bit) e Windows XP (a 32bit).
In pratica gli x86-64 possono funzionare
con OS a 32bit ed applicazioni a 32bit
oppure con OS a 64bit ed applicazioni a 32bit oppure a 64bit.
Niente OS a 32bit con applicazioni a 64bit (per fortuna).
Probabilmente AMD ha *anche* voluto pararsi il culo da "genialate"
made-in-Microsoft.
Anni fa Microsoft aveva fatto il porting di Windows NT
per cpu Alpha a 64bit ... "castrandola" in una modalita a 32bit
(sarebbe come se la Ferrari si facesse fare una centralina
  dalla Fiat e questa gli propinasse quella di un Punto ... con le
  stesse limitazioni di accelerazione e velocita di una Punto).
L. Micheletto

 di informatica 2?
E tu hai mai studiato un pochetti di 'Sistemi Operativi'? E hai mai 
realizzato un sistema operativo? E magari hai mai scritto driver per il 
kernel di linux?
Quando parlo di emulazione intendo dire che se il SO implementa una 
SysCall a Xbit allora per permettere ad una applicazione a Ybit di 
accedere a quelle SysCall deve creare un sistema di passup, in Windows il 
passup e' realizzato tramite dll di appoggio condivise. Cio' posto c'e' 
una parte di codice che viene utilizzata 'contemporaneamente' da tutte le 
applicazioni a Ybit. Se un'applicazione sputtana questa parte di codice 
condivisa tutte le altre andranno ad avere problemi. Questo succede con 
app a 16bit su Win32 e con app a 32bit su Win64.
Come funziona un processore lo so, le diverse modalita' le conosco, come 
si trappano le syscall pure visto che un SO microkernel (come quello di 
WinNT) l'ho scritto (anche se a scopo didattico e su un'architettura MIPS 
RISC quindi molto semplice).
Lascio cadere la discussione qui perche' sinceramente non ho voglia di 
continuare e sono sicuro che non portera' a nulla.
Saluti
Stefano

 Emulare significa ben altro.
di questo non sono poi cosi' sicuro: parlando di wine e similari si 
parla comunemente di emulazione...

 condivisa tutte le altre andranno ad avere problemi. Questo succede con 
ho un paio di appunti: 
a) l'evento "un'applicazione sputtana quel codice condiviso" e' piu' o 
meno probabile dell'evento "un'applicazione sputtana una parte vitale a 
caso del sistema operativo" ?
sai, se si parte dal presupposto che un'applicazione riesca a corrompere 
parti del sistema operativo, il problema non e' mica del processore...
b) tra l'altro l'eventuale debolezza riguarda *quel* sistema operativo.

 parla comunemente di emulazione...
Il che e` tutto dire quando Wine singnifica Wine is not an Emulator :)


 wrote in
news:slrnbhe4pk.t...@localhost.localdomain: 

ti rispondo punto per punto:
a) questa cosa non e' affatto vera. un'applicazione che viene gestita in 
maniera nativa dal sistema operativo ha meno probabilita' di sputtanare 
il tutto di un'applicazione gestita tramite passup. Il passup (nel caso 
di Windows con Dll che creano un sottosistema compatibile) e' un layer in 
piu' che aggiunge complessita' e quindi debolezza al sistema operativo. 
Un conto e' che il SO puo' 'gestire' direttamente un'applicazione, un 
conto e' che un SO deve passare per un layer in piu' per gestire 
un'applicazione.
b) l'eventuale debolezza indubbiamente riguarda il SO, ma purtroppo 
quando tu fai un SO per una determinata architettura e devi mantenere 
compatibilita' devi fare un layer in piu' e quindi e' per definizione 
piu' debole. Un esempio palese e' il MacOSX che per mantenere 
compatibilita' ha un layer nel kernel che gestisce le applicazioni 
'vecchie' ed e' provato che sotto MacOSX le applicazioni 'vecchie' sono 
meno stabili che con i vecchi MacOS.

 Il che e` tutto dire quando Wine singnifica Wine is not an Emulator :)
Poniamo l'esempio di VMWare che permette di eseguire un intero SO in 
maniera trasparente in una macchina virtuale. Questo SO verra' eseguito 
in maniera nativa a livello di singole istruzioni perche' il processore 
e' lo stesso e le istruzioni sono quelle, ma VMWare aggiunge un layer di 
emulazione che permette al SO virtuale di girare in maniera trasparente 
come applicazione del SO host. Questa io la chiamo emulazione, e questo 
tipo di emulazione (tipico in Win32 per eseguire app DOS, 16bit, OS/2 1.x 
o tipico in Win64 per eseguire app 32bit) aggiunge complessita' e 
instabilita'.
Quindi io dico se non si hanno in mano applicazioni a 64bit e' inutile 
avere un processore a 64bit, un SO a 64bit e farci girare solo 
applicazioni a 32bit.
Nel caso di WinXP64 questa frase della stessa M$ dice tutto:
"Windows XP 64烹it Edition provides a rich platform to integrate both 
64肪it technical applications and 32肪it business applications using the 
Windows on Windows 64 (WOW64) x86 emulation layer."
E poi questa:
"A key feature of Windows XP 64-Bit Edition is its ability to run 32-bit 
Windows-based applications unmodified on the 64-bit platform. To enable 
this capability, Microsoft has added a new 32-bit subsystem to Windows XP 
64-Bit Edition. This subsystem邑indows on Windows 64用rovides the 32-bit 
Windows services needed for applications to run properly even if they are 
not 64-bit."
E aggiungo questa frase stupenda sempre dalla stessa M$:
"Most 32-bit applications should continue to perform best on 32-bit 
versions of the Windows operating system."
Nello specifico vorrei aggiungere che certamente il WOW64 utilizza la 
feature del processore di switchare nella modalita' a 32bit, come 
attualmente il sottosistema 16bit gia' fa nelle versioni a 32bit di 
Windows.
E spero che in questo modo si chiuda il tutto.

 Nel caso di WinXP64 questa frase della stessa M$ dice tutto:
Di quello che dice microsoft non me ne frega niente. Io uso Linux e non
windows.
Quello che fa windows non e` e non deve essere considerato uno standard o
la norma.


la norma.
Peccato che per il mercato desktop non sia ancora cosi ;-)


 standard o la norma.
1) il thread e' iniziato parlando proprio di WinXP64 quindi quello che ho 
scritto e' assolutamente pertinente.
2) se avesso studiato bene il codice di Linux capiresti che cio' che vale 
per M$ vale anche per Linux. Il problema va oltre al SO, programmalo tu 
un SO che riesce a far girare applicazioni a 64bit e a 32bit in maniera 
100% nativa senza usare passup e vengo a leccarti la suola delle scarpe.

 farle girare, quindi ho preso in assoluto il miglior esempio.
Benissimo quindi la questione e` chiusa. Il sistema operativo non emula un
bel niente. Hai appena confermato il fatto che l'unica cosa che non emula
il sistema operativo e` il processore e per il semplice fatto che non ce
n'e` bisogno.


 Windows.
non esiste nessuna feature del genere.  forse sui nuovi itanium, quelli 
con l'interprete HW x86, ma su 386+ e x86-64 no di sicuro. il 386 ha 3 
modi principali di funzionamento:
- reale (16 bit, compatibile 8086, meccanismi di protezione quasi 
completamente disabilitati)
- protetto (16 e 32 bit; i 32 bit sono un'*estensione* del modo 
*protetto* del 286)
- V86 (un 8086 virtuale in modo protetto)
in modo protetto la distinzione tra 16bit e 32bit riguarda 
*esclusivamente* i default per operandi e indirizzi. e la distinzione 
viene fatta in base al bit apposito del descrittore di segmento coinvolto.
tanto per capirsi la sequenza di byte
B8 90 90 90 90
in un segmento di codice a 32 bit viene interpretata come 
MOV EAX, 90909090
in un segmento a 16 bit invece:
MOV AX, 9090
NOP
NOP
per avere operazioni a 16 bit utilizzando un segmento a 32bit basta 
semplicemente utilizzare i prefissi appositi (non sono sicurissimo che il 
contrario sia permesso, ma visto che le istruzioni a 32 bit in modo reale 
e V86 sono valide, sono abbastanza confidente). 
tra l'altro per win 3.11 c'erano librerie aggiuntive per i 32bit che 
permettevano di far andare (non so quante) applicazioni scritte per win95.
per x86-64 la situazione e' simile. alcune differenze in sintesi sono:
- ha un modo di funzionamento aggiuntivo
- in modo 32bit funziona (quasi, ci sono alcune estensioni gia' nate 
  col pentium) tutto come un 386
- i 64bit sono disponibili solo nel modo aggiuntivo a 64bit (long 
  mode mi sembra) e su segmenti a 64 bit (nel 386 erano disponibili sempre).
- in modo a 64bit per i segmenti a 64bit lo spazio di indirizzamento e' 
  flat (vengono ignorati base e limit del descrittore di segmento)
- in modo a 64bit si possono usare segmenti a 32 o 16 bit, in modo 
  _identico_ ai processori precedenti. per questo, solo cambiando task, 
  si riesce a eseguire codice a 32 (o anche 16) bit senza problemi.
- non sono supportati alcuni descrittori di sistema (usati solo dal SO) 
  del 286, ormai obsoleti

 meno stabili che con i vecchi MacOS.
brutto esempio. prima di tutto perche' e' un caso di compatibilita' 
all'indietro di  SO con *architetture* diverse ma con identico processore. 
si stava invece  parlando di evoluzione di un SO (che pero' mantiene la 
sua architettura)  per supportare un processore con un modo di 
funzionamento aggiuntivo. 
macosx in pratica e' uno unix, derivato da BSD. i vecchi macos non 
c'entrano  assolutamente nulla con macosx, sono qualcosa di piu' simile a 
windows 3/3.11 (nemmeno il 95...). sinceramente mi stupirei se il layer di 
"interconnessione" non fosse complesso e poco affidabile.
poi, per la precisione, esistono due "layer": 
http://developer.apple.com/macosx/architecture/
The Classic environment is actually a full version of Mac OS 9.1 running 
in a protected memory space under Mac OS X. As a result, most Mac OS-9 
compatible applications will run side-by-side with Mac OS X applications.
The Carbon APIs are based upon earlier Mac OS APIs. Carbon is a native Mac 
OS X runtime environment that allows applications to take advantage of Mac 
OS X features such as multiprocessing support and the Aqua user interface, 
while retaining compatibility with the installed base of Macintosh 
computers running Mac OS 8.1 or later.
Classic environment e' una specie di VMWare che fa andare macos 9 (!) 
a fianco coesistono le API del vecchio macos che internamente, quando
possibile, chiameranno le funzioni native.
e quando non e' possibile ? quando non e' possibile vuol dire che o 
non sono piu' utili (e bisogna riscriverle per compatibilita') o non sono 
piu' _realizzabili_ (e bisogna emularle in qualche modo).
esempio: non ci ho mai messo le mani, ma trattandosi di OS con 
multitasking cooperativo, suppongo che le applicazioni avranno la 
possibilita' di richiedere (e rilasciare) in modo esclusivo risorse, 
senza che il SO si intrometta. suppongo inoltre che la cooperazione per
alcune applicazioni sia necessaria. in altre parole un'applicazione 
scritta per il vecchio macos dovrebbe avere la possibilita' di interferire 
pesantemente con lo scheduler dei processi (e probabilmente con tante 
altre parti del SO). macosx ha il suo scheduler che al massimo accetta 
qualche velato consiglio, ma quando vuole sospendere un processo lo 
sospende punto e basta. come si emula una situazione di cooperative 
multitasking con uno scheduler preemptive ? piu' o meno imbastendo uno 
scheduler secondario che (a mo' di thread) gestisca i processi "macos".
ma questo scheduler e' sottomesso allo scheduler principale e deve essere 
interrompibile... 

 win95. 
Le famose Win32s, un'altra boiata M$, uscite prima di Win9x. Grazie a 
loro l'ambiente a 32bit di Win9x e' stato fatto a passup verso i 16bit.

si,ma non l'os..........
Non e` vero, con Opteron e Athlon 64 gira tutto in modo trasparente
senza la necessita` di nessuna emulazione, si possono avere diverse
combinazioni, mondo tutto a 32 bit, mondo tutto a 64 bit, OS a 64 bit
ed un misto di applicazioni a 64 e 32 bit.
Io ho qui una macchina dual Opteron 2GHz e la uso con Windows 2000 32
bit ed applicazioni 32bit. Non vi dico come performa, praticamente no
c'e` niente di simile al mondo, bisogna passare ad un 4P per avere
performance simili.

nulla.
Si, oppure Win 2000 32bit come faccio io sul mio dual Opteron 2 GHz.



Hai ragione. Fare certe affermazioni e per giunta con autorita` e` una
tragedia intellettuale.

 Si, oppure Win 2000 32bit come faccio io sul mio dual Opteron 2 GHz.
Vuoi proprio farmi invidia e`? :)
Piuttosto dove sono finiti i portatili con Athlon Xp LV? Sono equivalenti
ai banias e costano una frazione ma non li vende praticamente nessuno...
Meno male che al lavoro mi hanno dato un Athlon Xp mobile 1600+. Oggi ho
fatto le prove sulla batteria e dura piu` di 4 ore e mezzo con un Acer
1300 impostato in risparmio massimo sotto linux, mi sono fatto un po` di
alias in bash cosi` posso decidere io la frequenza a cui deve andare e il
momento in cui ci deve andare, chesso` faccio set800 per andare a 800Mhz o
minfreq per passare a 500Mhz o maxfreq per 1400Mhz... Dovreste farvi
sentire di piu` tra i portatili... Avreste grosse potenzialita` con i
vostri processori e i prezzi delle macchine con i vostri processori (la
meta` di tutti gli altri notebook).
Buon lavoro :)


Piuttosto dove sono finiti i portatili con Athlon Xp LV? 
beh, bisogna chiederlo ai costruttori ed a chi li ricatta, se la
domanda e` troppo limitata...
Qui comunque sta avendo un certo successo il Fujitsu sottile e leggero
con l'XP-M e` davvero una bella macchina, non so se c'e` in EU.
Per quanto riguarda il Power M. abbassare i MHZ non basta. Noi sotto
windows moduliamo dinamicamente frequenza e tensione (che come sai
lavora con legge quadratica)
Gabri

 lavora con legge quadratica)
Anche sotto linux viene modificata la tensione :). A 500 Mhz mi pare sia
1v e al massimo 1.4v e poi ci sono tutti i passi intermedi che posso
settare a piacimento eh eh eh :).
