On 20 Oct 2002 at 19:00, Sythos wrote:
> Il Fri, 18 Oct 2002 22:18:08 +0200
> "Ivan Sergio Borgonovo" <mail@xxxxxxxxxxxxxxx> disse:
>
> > aaah giusto anche i registri che sono stati sempre una miseria.
> > Se poi ci fosse stato un vantaggio ad avere registri codice e dati
> > separati sarei anche stato contento... ma ne il 286 ne il 386 avevano
> > pipeline multiple, cache, branch prediction e amenità varie... quindi
> > inventarsi delle ottimizzazioni basate sulla separazione registri
> > dati/puntatori codice/stack mi suona difficile.
> Le pipeline sono apparse dal 486DX in poi, i registri separati sono solo
Si... però i registri separati sono apparsi prima... questi hanno una
ragione d'essere se li usi per tirarne fuori qualche cosa non se sono
solo una limitazione per il programmatore... cosa che infatti...
> vantaggiosi, prova a fare un buffer overflow in un registro che contiene
> solo dati e dimmi se riesci a intaccare il codice.... Branch prediction
appunto di buffer overflow di questo tipo, stack _E_ heap è piena la
storia degli x86, quindi evidentemente la cosa non è stata affatto un
ostacolo.
Le macchine Sun invece per ragioni architetturali sono meno (non
completamente solo meno) vulnerabili a queste cose.
> apparsi nel 92 con i primi pentium, scelta discutibile, ma se sbattevi 5
> NOP prima di processi pesanti ne traevi vantaggio. Forse ci hai lavorato
> troppo poco per apprezzarli....
Si ma all'epoca dei Pentium di acqua sotto i ponti ne era passata...
L'Intel si trovava già in una posizione di quasi monopolio del mercato
dei PC, potendosi permettere tutti i vantaggi di un economia di scala.
Ovvio che a quel punto per comperare processori con architetture più
intelligenti ma numeri di vendita notevolmente ridotti ti toccava
cacciare molta più lira e quindi uscivi dalla zona picci.
Se poi ritieni un bene il fatto che per trarre vantaggio dalla branch
prediction tu debba far eseguire dei nop al processore... mha... altre
macchine hanno seguito strade ben più furbe.
> > Non c'è paragone con quello che era già disponibile per il 68000 e gli
> > sviluppi degli x86 che in seguito per ovvie ragioni hanno dovuto
> > continuare a essere backward compatibili.
> Se questo sia un bene o un male possiamo anche parlarne. Capisco che
> tirarsi dietro architetture obsolete per compatibilità possa sembrare
> uno spreco, ma io aspetto la diffusione di ia64 e hammer(amd) per
> divertirmi, ia64 non supporterà + i cdici a 8 e parzialmente a 16bit,
> hammer non ha supporto completo per le istruzioni a 64bit..... vediamo
> chi la spunta...
Bho.., sai c'è gente che sviluppa un noto sistema operativo e un bel
gruppone di programmi su una miriade di architetture completamente
differenti.
> > Se l'architettura degli x86 fosse veramente furba i processori attuali
> > non sarebbero degli "interpreti" di codice x86. Il codice x86 è "così
> > efficente" che si va più veloce addirittura a emularlo software su un
> > processore... Crusoe della http://www.transmeta.com del nostro
> > beneamato... Pure gli AMD "emulano" ma HW il codice x86... il set di
> > istruzioni interno credo che sia del tipo VLIW... insomma il codice
> > x86 viene "interpretato".
> Per questo amd è stata sempre avanti, sfruttava le innovazioni intel e
> aggiungeva di suo. Mai avuto un Intel, sempre usato AMD.
mmm veramente AMD ha lavorato di suo... alcune cose sulla
parallelizzazione del codice, l'assembler x86 "interpretato", sistemi
_furbi_ sulla branch prediction li ha inventati lei.
Poi per la questione dell'integrazione... appunto torniamo al discorso
dell'economia di scala... passare da 0.18 a 0.13 micron si ammortizza
prima se vendi 1M di processori piuttosto che se ne vendi 300K.
> > > Per protezione che intendi? Intendi automatismi per evitare
> > > collisioni dati/codice/stack?
> >
> > Diritti di lettura/scrittura/esecuzione su aree di memoria, il famoso
> > virtual mode, un po' di facilities per il time sharing, indirizzi
> > lunghi...
> Se il programmatore non cappella il programma fila liscio, se cerchi un
> compilatore o processore error recovering hai sbagliato piattaforma e
> non devi cercarlo nell'assembly. Come disse il Tanno tempo fa (non so se
> sua o riferita) se la statua viene di merda non devi dare la colpa allo
> scalpello ma allo scultore.
Bhe la cosa si può ribaltare... perchè avere i permessi di scrittura
sul FS... se gli utenti sono onesti e intelligenti? Perchè avere i
template sul C++ se i programmatori possono scrivere tutto a manina?
Alcune cose agevolano sia in termini di gestione che di velocità il
proces switching... insomma non sono affatto inutili anzi hanno delle
ripercussioni notevoli sulle performance.
> > Per tante ragioni storiche gli x86 hanno avuto _MOLTO_ più successo di
> > quanto non si meritassero... e non sono gli unici.
> Solo perchè erano legati a un OS.... Se windows si fosse basato su un
> processore RISC forse ora il mercato sarebbe nullo per gli X86.
MAGAAAAAAAAAAARIIIIII.
Corre voce... ma sarà leggenda... non ho indagato... che Intel abbia
corrotto chi doveva decidere in IBM ;)
> > > Uh? io intendevo prestazioni a parità di clock...
> > e io caccio fuori i soldi solo per il clock?
> > Siamo talmente tanto alla frutta che la AMD che tra l'altro fa anche
> > dei processori interessanti ha dovuto "inventarsi" per ragioni di
> > marketing un clock virtuale per chiamare i suoi processori.
> A parita di clock un processore risc mipsa molto di più. Il clock
> virtuale serve solo per motivi utentistici, overo un 2000+ equivale come
> prestazioni a un P3-2k ma ha un clock reale più basso, un utente che si
> infila nel negozio vuole numeri, non capisce nè gli interessano i
> benchmark. E sinceramente non mi aspetto di trovare gente qua che guarda
> solo alle sigle e non alla sostanza.
Appunto... e anche sui benchmark c'è tanto di quello spazio per sparare
vaccate e intortare la gente...
Ma come cippa si fa a chiamare un benchmark "Internet Multimedia
Creation" (o simile...)???
Conclusione inappellabile... gli x86 sono una patacca. Si comperano
solo perchè rispetto al resto, producendone una barcata costano "poco".
BTW... attualmente chiamano ancora RISC delle cose che non hanno
esattamente un _Reduced_ instruction set ma che hanno "ereditato" dai
RISC una marea di registri e un maggior controllo sw sulle pipe.
--
Salve
Ivan Sergio Borgonovo
http://www.webthatworks.it/
uniq life || sleep 24h
|