Confronto fra i486 e Motorola 68000

[cdimauro]

Originariamente inviato da Marco71

Ben ritrovato Dr. Di Mauro...innanzi a tutto le auguro buone vacanze ovunque lei si trovi...

ARGH. Perché mi dai sempre del lei?

Comunque auguri anche a te agli altri: sono appena rientrato dalle ferie...

L'unica cosa che rimprovero a Motorola è di avere risparmiato sul numero di transistor proprio nei "blocchi" che più mi interessavano allora ed adesso: nella unità f.p.u...
Quando su un numero di "Bit" di allora lessi che non avevano implementato le funzioni trascendenti mi misi a piangere "interiormente" dato che purtroppo la vita esige molto spesso il mascherare ed il dissimulare ciò che realmente si prova (come dicono nei forum...I.M.H.O).

Anch'io ho storto un po' il naso quando, col 68040, Motorola eliminò buona parte di quelle istruzioni dell'FPU 68882. Poi, però, vedendo che con l'apposita libreria giravano del 50% più velocemente a parità di clock (prendendo 68030 e 68882 come riferimento), mi sono in parte ricreduto.

Dico in parte, perché capisco che un processore come il 68040 (e peggio ancora il 68060) è particolarmente complicato (a livello implementativo). Ma una cosa che non ho mai digerito di Motorola è il fatto di avere cambiato l'ISA della modalità utente.
Passi per quella supervisore, che è dominio del "sistema operativo" e dove giustamente col tempo subentrano parecchie modifiche (es: la MMU si è evoluta molto col tempo, dal 68020 / 68851), ma non sono mai riuscito ad accettare la "castrazione" di alcune istruzioni nella modalità utente.

Questo è accaduto per le funzioni trascendentali col 68040, e con la MOVEP e LMUL / LDIV (se non ricordo male) col 68060. Anche se la MOVEP, ad esempio, è stata usata MOLTO raramente (a parte con gli ST ), non vedo il motivo per cui doveva essere eliminata, visto che faceva parte dell'ISA fin dal 68000...

Mi dice, non avrebbe una fotografia del silicio dell'MC68040 (o meglio di 68000, 68020,68030 ecc.) ?

C'era su qualche numero di MC MicroComputer del '90, se non erro, ma ormai da qualche mesetto sono seppelliti nel garage di mio padre...

La ringrazio e continuo a "stare alla finestra" della vostra discussione...
Grazie.

Marco71.

Non hai di che ringraziare nessuno: qui è un dare e un avere. Leggo con piacere i tuoi interventi nel campo dei dischi rigidi...

Ciao
Cesare

[cdimauro]

Originariamente inviato da Crisp

si, ok come il caso di Quake
Ma non fu voluto però, è stato chi lo ha programmato ad essere davvero bravo

Veramente io ricordo che quella notizia non fu legata a Quake o a qualche altro software, ma saltò fuori poco tempo dopo la presentazione del primo Pentium. Comunque è passato parecchio tempo, e può darsi che la mia memoria faccia cilecca...

Però l'abilità dei programmatori su pc si vedeva, guarda il caso di Screamer Rally, di DarkForces, di Duke Nukem 3D che giravano bene anche su 486dx2.
Il 68040 e il 68060 era pienamente in grado di far girare questi titoli forse meglio della cpu x86 che in confronto alle cpu Motorola era davverò senza confronto eppure..

Stai parlando di titoli 3D, quindi che utilizzavano la modalità chunky pixel delle VGA e delle "moderne" schede grafiche in generale. La modalità a bitplane utilizzata da Amiga, Atari STx, ecc. mal si prestava per il 3D, se non realizzato "alla vecchia maniera", con poligoni al più retinati (e usando il Blitter).

Apple ha messo in pensione le cpu 68k appena gli è stato possibile, non gli è manco interessato provare il 68060 e già su 040 si riuscivano a fare cose che sullo stesso 040 su amiga era impossibile.
Ah ecco un caso di pessima programmazione Amiga 68k: Emulatore Megadrive
Su 486sx33 emulazione perfetta, su amiga almeno un PowerPC
Froto su 060 e scheda grafica è lentissimo, per emulare un C64, ma quello è colpa dei programmatori, perchè lo stesso frodo su un Mac emulato da uno 040 con shapeshifter fa grirare Frodo al 100%

Quindi le cpu 68k erano ottime cpu e i programmatori sembrano aver fatto di tutto per abissarle..
Basta vedere le stesse applicazioni su amigaOS e MacOS..

Dipende dalle applicazioni. Come tu stesso hai riportato con quegli esempi, è evidente che spesso ci si è trovato davanti a problemi dovuti a cattiva programmazione, non a carenze architetturali (fatta eccezione per il 3D, per cui vale quanto scritto sopra).

[Mark0]

Originariamente inviato da Marco71

Mi dice, non avrebbe una fotografia del silicio dell'MC68040 (o meglio di 68000, 68020,68030 ecc.) ?

Io ho trovato queste: Molecular Expressions: Chip Shots - Motorola Integrated Circuits

Bye!

[Marco71]

...in precedenza avevo utilizzato proprio questo sito che raccoglie fotografie S.E.M per delle micro-foto dei processori Intel...in "falsi colori"...

Marco71.

[Crisp]

Originariamente inviato da cdimauro

Poi, però, vedendo che con l'apposita libreria giravano del 50% più velocemente a parità di clock (prendendo 68030 e 68882 come riferimento), mi sono in parte ricreduto.

Con Oxyronpatcher le istruzioni emulate dell'882 giravano molto ma molto di più del 50%.
Con un 68040 40 mhz + oxypatcher il confronto con lo 030 50 mhz, spariva definitivamente a favore dello 040
E la combo 060 + Oxypatcher era

Poi ovviamente il software scritto con in piedi non c'era niente da fare, però le applicazioni che usavano la fpu in maniera intensiva lo 040 era un siluro, e oxypatcher ti faceva vedere ogni volta che un programma accedeva alla 68040.library tutte le istruzioni 882 emulate...

Su 040 mancava l'istruzione Fint e Fintrz, istruzioni usate moltissimo da tutte le applicazioni fpu su amiga
Istruzioni reimplementate poi su 060, gurada caso

[cdimauro]

Non ho mai avuto uno 040 o uno 060 , per cui non posso giudicare.
Cercando in giro ho trovato questo: http://66.249.93.104/search?q=cache:...+patcher&hl=it e non mi sembra che queste patch diano risultati eccezionali.

Comunque, era tutto grasso che colava...

P.S. Bello il tuo nick, se ha il significato che immagino...

[Crisp]

no, il nick è il nome con attaccato la sigla della provincia

E' proprio oxypatcher
Cmq l'accelerazione c'è con i programmi che usano la fpu in maniera intensiva.

queste sono le istruzioni supportate:

The OxyPatcher supports the following integer instructions:
MULU.L
MULS.L
DIVU.L
DIVS.L
MOVEP
CMP2

and the following FPU instructions:
FMOVECR (all const.)
FDBcc (all Condition-Codes)
FScc (all Condition-Codes)
FSIN
FCOS
FATAN
FLOGN
FLOG2
FLOG10
FTAN
FETOX
FTWOTOX
FTENTOX
FETOXM1
FLOGNP1
FCOSH
FSINH
FASIN
FACOS
FTANH
FATANH
FGETEXP
FGETMAN
FINTRZ
FINT
FSINCOS
FSCALE
FMOD
FREM

The Data.X FFP-Format, e.g.:
FMOVE.X #Data,FPn
FCMP.X #Data,FPn
FSIN.X #Data,FPn
FMOD.X #Data,FPn

e queste invece non sono supportate:
CAS2
CHK2

avrai visto di alcune istruzioni intere perchè lo 060 deve emulare pure delle istruzioni intere che gli sono state tolte e senza oxypatcher perde quyalcosa anche nella applicazioni che non usano la cpu..

andiamo avanti:

The following table will show the speed of the OxyPatcher:

For the 68040 Processor:
------------------------

Program unpatched patched
===================================================

MaxonC4D_V4.0
-------------
Scene1 00:07:52 00:02:52
Scene2 00:21:37 00:09:21
Scene3 01:04:36 00:32:56

WCS_V2.04
---------
Scene1 00:13:00 00:05:28
Scene2 01:25:23 00:42:41

Lightwave_V5.0
--------------
Scene1 00:21:39 00:17:45
Scene2 01:32:38 01:20:28

SceneryAnimator_V4.0
--------------------
Scene1 00:03:31 00:02:09
Scene2 00:03:16 00:01:46

Reflections_V3.05
-----------------
Scene1 00:03:21 00:02:38
Scene2 00:18:43 00:15:06
Scene3 00:13:53 00:04:29

Real3D_V3
---------
Scene1 00:56:04 00:37:16

Fractuality_V1.10d
------------------
UrApfel/640*512
DoubleFP/It.max=128 00:06:44 00:00:53




For the 68060 Processor:
------------------------

Program unpatched patched
===================================================

MaxonC4D_V4.0
-------------
Scene1 00:10:58 00:01:13
Scene2 01:14:32 00:04:38
Scene3 05:56:03 00:16:58

WCS_V2.04
---------
Scene1 00:10:13 00:02:02
Scene2 01:13:36 00:18:08

Lightwave_V5.0
--------------
Scene1 00:17:57 00:06:03
Scene2 01:24:06 00:26:31

SceneryAnimator_V4.0
--------------------
Scene1 00:19:24 00:01:23
Scene2 00:13:26 00:01:07

Reflections_V3.05
-----------------
Scene1 00:02:10 00:01:07
Scene2 00:11:18 00:06:17
Scene3 00:04:02 00:01:40

Real3D_V3
---------
Scene1 00:34:14 00:14:51

Fractuality_V1.10d
------------------
UrApfel/640*512
DoubleFP/It.max=128 00:06:59 00:00:18


********************************************************************************

4.4 Tested Systems
----------------------

The OxyPatcher has been tested on the following configurations:

-A1200/Blizard1260/48MB-FastRAM/SCSI-Controller
-A1200/Apollo1240-40MHz/16MB-FastRAM
-A1200/Apollo1260/16MB-FastRAM
-A4000/Apollo4060/Picasso4/40MB-FastRAM
-A4000/Cyberstorm-MK2/Picasso4/32MB-FastRAM
-A4000/Cyberstorm-MK2/Cybervison/112MB-FastRAM


come avrai letto, alcune applicazioni hanno avuto un incremento enorme (sopratutto su 060) altre meno.
In generale si un incremento dal 5 al 40% di velocità tra una cpu 040/060 di base e patchata.
Dipende dal software e da come è scritto.

Poi c'è un'altra patch: FastExec per spostare in fast ram l'Exec e muovere in fast l'SSP che su 040 e 060 da ulteriori incrementi.

Somma oxypatcher e fastexec e si ottiene un buon boost

La mia era l'apollo 1240 40 mhz 32 MB e prima avevo uno 030/50 16 MB, quindi ho avuto modo di vedere le differenze.
Cmq in generale c'è stato più incremento di velocità tra un 1200 di base e uno 020 28 Mhz che tra un 68040 e un 68030

[Crisp]

Originariamente inviato da Crisp

MaxonC4D_V4.0
-------------

Scene3 01:04:36 00:32:56

Scene3 05:56:03 00:16:58

come si vede qui nel rendering della 3° scena lo 060 è addiritura più lento dello 040 senza usare la patch, mentre con la patch si recupera mezzora su 040 e 5 ore su 060...

Se tra senza patch e patch c'è un simile divario, usare queste cpu con oxypatcher migliorava ancora di più il divario con lo 030.

Se invece usavano istruzioni native era ancora più veloce e non c'era bisogno della patch..
Molti binari per 040 emulano a nastro instruzini 882

[cdimauro]

Non c'è che dire: impressionanti questi risultati, specialmente con lo 060.

[Marco71]

..per caso le prime versioni di MC68060 erano in contenitore ceramico rosso-fegato con la scritta "060" ?
In pratica lo stesso contenitore dell'MC68040...
Quando la famiglia 68000 era sul "trono" veniva molto utilizzata anche in ambito (sigh!) militare con versioni particolari schermate per le radiazioni ionizzanti e non presenti nello spazio "esterno".
Il 68050 (mai entrato in produzione) fu per me il vero "canto del cigno" della più che gloriosa famiglia 68000 (sigh!)...
Esponenti più o meno illustri 68xxx sono ancora impiegati in utilizzi "embedded" oltre che in ambito automotive...
Grazie.

Marco71.

[cdimauro]

Peccato che stiano scomparendo a favore di soluzioni basate su core ARM...

[cdimauro]

Già, e la cosa mi dispiace, perché anch'io ritengo l'architettura 680x0 molto, ma molto più semplice da programmare rispetto a un ARM.

Sì, il primo ARM era davvero molto semplice: constava di 25 mila transistor. Nonostante tutto era mostruosamente veloce, rispetto a un 68000, che ne contava ben 68000... Semplicità che si pagava, ad esempio, col fatto che architetturalmente non era in grado di indirizzare più di 64MB di memoria.
Fortunatamente questi limiti sono stati rimossi dalle successive versioni.

Trovo molto interessante l'introduzione dell'ISA Thumb: semplice, potente quel che basta e molto compatto. Una bella trovata della Acorn, non c'è che dire.
Peccato che nessuno abbia pensato di realizzare un processore ARM funzionante soltanto in modalità Thumb: dovrebbe essere più semplice da realizzare, produrre, e spingere a frequenze più elevate.

[Gica78R]

Ehm... Scusate se mi intrometto... Ho letto tutto fino a pag. 6, poi ho pensato al suicidio.
In realta' mi sono imbattuto in questo thread solo perche' cercavo informazioni sul Motorola 68000, in particolare circa lo spazio di indirizzamento... Su un vecchio libro ho letto una cosa strana, di cui riporto uno stralcio:

Il 68000 e' un processore con architettura 16/32 bit avente un bus dati di 16 bit e un bus indirizzi di 23 bit non multiplexati.

[...] il 68000 possiede registri da 16/32 bit e un registro contatore di programma di 32 bit. Di quest'ultimo, sul bus indirizzi ne vengono pero' riportati soltanto 23, ottenendo cosi' una capacita' di indirizzamento di 16 MB.

La cosa mi e' parsa subito assurda, e leggendo nel thread e in alcuni links ho avuto la conferma che il bus indirizzi e' di 24 bits (senno' come ci arriva a 16MB???)... E' cosi', vero? Il bello e' che nel libro la faccenda dei 23 bit e' ripetuta diverse volte Che faccio, lo brucio?

Grazie

[cdimauro]

Originariamente inviato da Gica78R

Ehm... Scusate se mi intrometto... Ho letto tutto fino a pag. 6, poi ho pensato al suicidio.

E' ancora presto: prima devi finore di leggerti tutto il thread...

In realta' mi sono imbattuto in questo thread solo perche' cercavo informazioni sul Motorola 68000, in particolare circa lo spazio di indirizzamento... Su un vecchio libro ho letto una cosa strana, di cui riporto uno stralcio:

La cosa mi e' parsa subito assurda, e leggendo nel thread e in alcuni links ho avuto la conferma che il bus indirizzi e' di 24 bits (senno' come ci arriva a 16MB???)... E' cosi', vero? Il bello e' che nel libro la faccenda dei 23 bit e' ripetuta diverse volte Che faccio, lo brucio?

Grazie

No, anche se vecchio, glielo tornerei indietro e mi farei ridare i soldi (con gli interessi ): quelle informazioni sono palesemente false / errate.

P.S. Tra l'altro coi 68000 si potevano indirizzare fino a 64MB di memoria, ma capire come fare te lo lascio come esercizio, visto che sei in vena di studii...

[Gica78R]

Bus indirizzi a 23 bit nel 68000: svelato l'arcano!

Sempre sul famoso libro/manuale, e' riportata la piedinatura del 68000, ed anche in questo caso le linee per il bus indirizzi sono 23, e sono numerate da A1 a A23. Gironzolando in rete, ho trovato un documento che dice quanto segue:

Il processore 68000 dispone di:

• 16 bit di bus dati;
• 24 segnali di indirizzo, che permettono di disporre di uno spazio di indirizzamento pari a 16 MB di memoria esterna. Solo 23 segnali sono disponibili (A1-A23), mentre il segnale A0 e' usato internamente dal processore per pilotare i segnali UDS e LDS. I livelli dei segnali sono controllati dallo stato del segnale interno A0: se e' richiesto l'indirizzamento di un byte, A0 e' usato per accedere alla locazione di memoria (pari/dispari) opportuna. Un accesso a word ingnora lo stato del segnale A0.

Cmq non ho ancora capito come indirizzare 64MB con questo processore...
Pero' continuo a pensarci

Edit: non e' che posso usare quei due piedini GND che stanno vicino ai piedini del bus indirizzi? Tanto di GND ce ne stanno quattro!

[cdimauro]

Originariamente inviato da Gica78R

Bus indirizzi a 23 bit nel 68000: svelato l'arcano!

Sempre sul famoso libro/manuale, e' riportata la piedinatura del 68000, ed anche in questo caso le linee per il bus indirizzi sono 23, e sono numerate da A1 a A23. Gironzolando in rete, ho trovato un documento che dice quanto segue:

Sì, però la spiegazione l'hai trovata in rete e non sul libro...

Comunque, sì, il 68000 non ha un piedino A0, ma due per poter scegliere il tipo e quale dato leggere dal bus, che è sempre a 16 bit...

Cmq non ho ancora capito come indirizzare 64MB con questo processore...
Pero' continuo a pensarci

Edit: non e' che posso usare quei due piedini GND che stanno vicino ai piedini del bus indirizzi? Tanto di GND ce ne stanno quattro!

No, quella è la massa: non provare a collegarla a qualcos'altro!!!

Prova per esclusione: elimina i piedini di cui già conosci il significato / funzionamento... Te ne rimangono altri: fra questi ce ne sono alcuni "strani"...

[Gica78R]

Originariamente inviato da cdimauro

No, quella è la massa: non provare a collegarla a qualcos'altro!!!

Beh, ma i piedini per la massa servono proprio tutti e quattro?
Se cosi' non fosse, e se potessero essere controllati in qualche modo, si potrebbero collegarne due ad altre due linee di un ipotetico bus indirizzi a 26 bit...

Prova per esclusione: elimina i piedini di cui già conosci il significato / funzionamento... Te ne rimangono altri: fra questi ce ne sono alcuni "strani"...

Ok, credo di aver capito... Grazie del suggerimento!

[Marco71]

...i piedini di massa elettrica multipli servono solo ed esclusivamente per meglio instradare il riferimento elettrico circuitale "massa" appunto (che molti confondono troppo spesso con il concetto di "terra")...
Non possono essere utilizzati come piedini di segnale "logico" e a maggior ragione come segnali per il bus indirizzi (che ad esempio nel 80486 a causa dello snooping delle memorie cache interne è bidirezionale).
In epoca di Commodore 64 e poi anche 128 era in largo uso l'utilizzo della tecnica del "bank switching" per superare i limiti "fisici" dei vari Rockwell 6502/6510 e derivati.
Grazie.

Marco71.

[Masmo]

Ciao a tutti,
ho seguito con passione le vostre discussioni e volevo anche io dire
la mia sull'argomento.

Riguardo all'Atari st e Amiga erano entrambi dei bei computer, ogniuno
con i suoi pregi e i suoi difetti.

Io ho avuto un atari st dal 1990 al 1994, avevo entrambi i monitor e
devo dire che la configurazione con monitor a colori era essenzialmente
+ adatta al gioco, mentre con il monitor b/w le cose cambiavano di molto.

Un mio amico si prese il Mega ST 2 con Hd da 30Mb e stampante laser.
Bene, con questa configurazione, lui che era patito di desktop publishing,
poteva tranquillamente rivaleggiare con pc dal costo ben superiore. Aveva
Calamus come software per lavorare e devo dire che era veramente bello.

Io che studiavo informatica, lavoravo principalmente con il Borland turbo c ma
imparai anche ad utilizzare il devpac per l'assembler e il gfa basic.

Devo dire che con il monitor b/w era veramente un altro mondo, anche altri
ragazzi che studiavano con me all'università, patiti dei pc, quando videro
la configurazione b/w rimasero veramente stupefatti.

Considerate che in quel periodo li, i pc con i 286 costavano già parecchio
di + di quanto spesi io per comprarmi l'atari st (1.400.000).

Per quanto riguarda l'Amiga, non mi posso pronunciare + di tanto visto
che non l'ho mai avuto, ma credo che fosse una macchina stupenda
visto l'hardware che montava.

Io credo che per i giochi l'amiga fosse migliore dell'atari st, magari
su tanti giochi la differenza era minima, ma per quanto riguarda
la grafica e il suono era sicuramente superiore. L'atari st non aveva
grandi qualità grafiche e sonore, il processore audio era lo stesso
dell'msx, quindi non il top per quel periodo.

Io non credo che nell'amiga avessero messo tutti quei chip custom per
rallentarlo!! Siamo seri...

E' ovvio che poi magari in qualche gioco l'atari poteva essere un pochino +
veloce. Io mi ricordo alcuni demo (ce ne sono a bizzeffe vedi
http://www.lysator.liu.se/~celeborn/sync/page3.html e il demo
The dark side of the spoon ) le cose che riuscivano a fare con l'atari
erano impressionanti, se si pensa che l'atari non aveva alcun chip
custom di aiuto per la grafica.

Penso proprio che questi due computer abbiano fatto storia come a
suo tempo il c64/msx/vic20 ecc...

Per quanto riguarda 68000 vs 80486 mi sembra un pochino fuori
luogo confrontare cpu nate con 10 o + anni di differenza (non mi ricordo).

Semmai se proprio dovete confrontare qualcosa, fatilo fra il 68000 e
il 80286...

Quanto studiavo informatica, ero appassionato di benchmark (be, in effetti
lo sono tutt'ora http://themasmo.interfree.it) e ci divertivamo a creare
dei piccoli benchmark in assembler per 286 o 68000 e poi confrontare le velocità (sempre con quei ragazzi che adulavano i pc).

Be, le conclusioni furono queste:

L'80286 in effetti era + veloce nell'eseguire le istruzioni, però non era
il vincitore e vi spiego anche il perchè.

Il 68000 aveva 8 registri dati (d0-d7) e 8 registri indirizzi (a0-a7) di cui uno
(a7) usato per lo stack.

Tutti i registri erano a 32 bit, il fatto di avere il bus dati a 16 bit voleva dire
dire poco o nulla. Il 286 era un 16bit quindi tutte le operazioni di calcolo
interne erano su registri di 16bit e non di 32bit.

Se nel 68000 si voleva eseguire una moltiplicazione, il risultato andava
sempre su un singolo registro, mentre sul 286, dovevano essere utilizzati
2 registri per il risultato visto che un singolo registro poteva al massimo
contenere 16bit.

Vi sembra poco? Ma non finisce qui:

Il 68000 utilizzava 14 modi di indirizzamente, 7 di + del 286, nel 90% delle
istruzioni si potevano utilizzare qualsiasi registro a disposizione. Non c'erano
registri fissi per fare moltiplicazione/divisioni ecc.

Guardate questo codice qui di seguito:

MOMEM.L D3-D7,-(SP)
MOVE.L D1,D6
MOVE.L D2,D7
MOVE.L D1,D3
MOVE.L D1,D4
SWAP D4
MOVE.L D2,D4
SWAP D5
MULU D2,D1
MULU D4,D2
MULU D5,D3
MULU D5,D4
SWAP D1
ADD D2,D1
CLR.L D5
ADDX.L D5,D4
ADD D3,D1
ADDX.L D5,D4
SWAP D1
CLR D2
SWAP D2
CLR D3
SWAP D3
ADD.L D3,D2
ADD.L D4,D2
TST.L D7
BPL.S CHECKD6
SUB.L D6,D2
CHECKD6
TST.L D6
BPL.S DONE
SUB.L D7,D2
DONE
MOVEM.L (SP)+,D3-D7
RTS

Bene, questa routine calcola una moltiplicazione 32x32 bit..
Moltiplicatore in D2 e moltiplicando in D1, il prodotto viene
restituito in D1 (32bit bassi) e D2 (32 bit alti).

Non notate niente di strano?

Non accede mai alla memoria, usa solo i registri.... vi rendete conto
cosa vuol dire a livello di velocità?

Provai a fare la stessa routine su un 286.. un incubo, con quei pochi
registri dovevo fare sempre accesso alla memoria per salvare i dati
temporanei dei calcoli con il risultato che andava + lenta che non nel 68000.
Quelle cpu non avevano le cache delle cpu odierne!!!

Quindi il 68000 era veramente una cpu stupenda, si imparava a programmare
in pochi giorni e metteva a disposizione dell'utente istruzioni di una potenza
fuori dal comune per quei tempi.

E' ovvio che oggi solo quelli un poco fuori di testa si mettono a programmare
in assembler, al massimo si possono fare alcune routine ottimizzate per
sfruttare a pieno le capacità della cpu, poi si utilizzeranno sempre linguaggi
ad alto livello tipo C/Delphi/Basic Vari ecc...

Non 'ho + altro da aggiungere.

Anzi una cosa la voglio dire...

Io non tornerei mai indietro, i computer di oggi sono spaventosi anche se
non sfruttati al 100% come lo erano quelli di una volta.
Con un athlon 64 3500+ e un semplice visual basic si riescono a fare
cose impensabili per quei tempi.

Ciao
Massimo

[Marco71]

...hai ragione su "quasi" tutto...
Però ricorda che bisogna contestualizzare il livello di tecnologia disponibile ad un dato tempo...
Il Motorola 68000 "traslato" al livello tecnologico attuale del silicio e dei semiconduttori in genere, si papperebbe allegramente qualsiasi processore x86...
Come un ipotetico supercomputer futuro, basato su elementi logici ottici si papperebbe pure esso allegramente l'attuale BlueGene/L.
E' vero che oggi nessuno si accotenta più di nulla..vedo troppi ragazzini under 18 che maneggiano potenze di "calcolo" appunto impensabili per un disgraziato come me che all'epoca di "I Like Chopin" programmava il suo Sharp Pocket Computer PC1245 con 2.2 diconsi 2200 bytes di memoria utente....
Sono poi daccordo che il confronto non è "paritetico": un 68000 sarebbe da confrontare con un 80286 come detto...
Un 80486 integrava un nucleo potenziato 80386 + un coprocessore 80387 I.E.E.E 754/854 + 8 KBytes di memoria cache associata al cache memory controller 802385 per 1.2 milioni di transistor "equivalenti"...
Forse il 68040 nè aveva meno proprio anche a causa della mancanza del supporto in hardware alle funzioni trascendenti.
Grazie.

Marco71.