Hardware > Hardware (High-End)
Atari St mit Vampire 500 FPGA Turbokarte
1ST1:
Auf Suska habe ich auch schon verwiesen, auch auf die MiST-ST-Cores (z.B. wegen implementierung einer Grafikkarte, scheinbar müssen die für den digitalen Grafikausgang die Originalgrafik nochmal implementieren). Eine FPU ist aber schon im 68080 drin, ihr fehlen nur ein paar (im Amiga?) garnicht benutzte Befehle, für die keine "Chipfläche" ver(sch)wendet werden soll. Das müsste halt mal von unserer Seite überprüft werden (welche Befehle, werden die in ST-Software auch nicht verwendet?). Eine rudimentäre "neue" MMU gibts auch schon, ich habe auch schon darauf verwiesen dass die Funktion der 68K-MMU für MiNT gebraucht wird. Oder das MiNT Kernel-Team müsste sich mit der Apollo-MMU auseinander setzen und schauen, ob die in MiNT alternativ nutzbar wäre.
mfro:
--- Zitat von: 1ST1 am Di 18.10.2016, 20:27:24 ---Nochwas gefunden, das macht sprachlos...
--- Code: --- CPU MHz CARD MIPS
68020 14 A1200 2
TG68 Mist 4
68020 28 Blizzard 1220 4
68030 26 ACA1233 4.2
68030 50 6
Coldfire 266 Firebee 8
68040 28 19
68040 40 27
68060 50 32
68060 80 A1200+Apollo1260 46
68080 78 Vampire GOLD 86
68080 92 Vampire GOLD2 165
--- Ende Code ---
Die 8 Mips der Firebee sind natürlich bescheiden. Das liegt daran, dass in dem MIPS Benchmark der DBRA Befehl benutzt wird, den Coldfire nicht kann, und emuliert werden muss. Ansonsten stünde die Firebee deutlich besser da,
--- Ende Zitat ---
Ich habe mir den bewussten "Benchmark" mal angeschaut, der diese Werte liefert. Leider gibt's keine Quellen dazu, also musste der Disassembler ran. Die innere Schleife, die da gemessen wird, macht folgendes:
--- Code: ---addil #16,%d0
addil #16,%d1
addil #16,%d2
addil #16,%d3
addal #16,%a0
addal #16,%a1
addal #16,%a2
dbf %d6,0x486
--- Ende Code ---
Gemessen wird da also letztendlich nichts anderes als wieviele (in dieser Kombination in der Realität nicht auftretende) add-Instruktionen die CPU pro Sekunde ausführen kann. Praktisch werden tatsächlich die "MIPS" (Millionen Instruktionen Pro Sekunde) gemessen.
Und "natürlich" mit Befehlen, die der Apollo-Core tatsächlich parallel ausführen kann. Die Schleife ist sozusagen auf den Core "maßgeschneidert". Da ist nix gegen einzuwenden, aber keiner sollte glauben, daß das Ergebnis die reale Performance widerspiegelt.
Die Tatsache, daß die Firebee bei diesem Benchmark so miserabel abschneidet, liegt nicht *nur* an dem dbf-Befehl, den der ColdFire emulieren muß. adda.l gibt's auf dem Coldfire auch nicht. Gemessen wird hier also im wesentlichen die Geschwindigkeit der m68k-Emulation der cf68klib.
Jetzt bin ich einfach mal frech und baue den synthetischen Benchmark, der zu nix nütze ist, einfach mal so um, daß die Firebee den "Coldfire-native" ausführen kann:
--- Code: --- move.l %[loops],d6
add.l #1,d6
1: addi.l #16,d0
addi.l #16,d1
addi.l #16,d2
addi.l #16,d3
lea 16(a0),a0
lea 16(a1),a1
lea 16(a2),a2
subq.l #1,d6
bne.s 1b
--- Ende Code ---
Der Code macht im Effekt genau dasselbe, ist immer noch zu nix nütze, aber eben mit Befehlen, die der ColdFire-Prozessor direkt (und in einem Taktzyklus) ausführen kann. Dann sieht's plötzlich ganz anders aus:
--- Code: ---ran 7.595000 seconds, MIPS: 210.664917
--- Ende Code ---
Daß da nicht 264 steht - entsprechend der FireBee-Taktfrequenz von 264 MHz - liegt daran, daß ich der Fairness halber nicht durch 9, sondern noch immer durch 8 geteilt habe, Coldfire muß die dbf-Entsprechung in zwei Befehle/Taktzyklen aufteilen. Die Interrupts habe ich im übrigen auch nicht abgeschaltet, weil ich nicht weiß, ob das Original das tut.
Aber das ist noch nicht das Ende der Fahnenstange. Schließlich geht's hier nur darum, (ansonsten sinnlose) Befehle so schnell wie möglich auszuführen...
Also noch ein bißchen frecher:
--- Code: --- move.l %[loops],d6
add.l #1,d6
1: addi.l #16,d0
mac.l d0,d1,acc0
addi.l #16,d1
mac.l d0,d1,acc0
addi.l #16,d2
mac.l d0,d1,acc0
addi.l #16,d3
mac.l d0,d1,acc0
lea 16(a0),a0
mac.l d0,d1,acc0
lea 16(a0),a1
mac.l d0,d1,acc0
lea 16(a0),a2
mac.l d0,d1,acc0
subq.l #1,d6
bne.s 1b
--- Ende Code ---
Auch der Coldfire-Prozessor kann (manchmal) zwei (in diesem Fall ebenso unnütze) Befehle gleichzeitig ausführen, wenn man seine EMAC Units ein wenig beschäftigt. Die Befehle sind alles andere als trivial (eine Multiplikation und eine Addition in einem Befehl), trotzdem werden sie in einem Taktzyklus abgearbeitet (im besten Fall, den ich nicht hinbekommen habe, auch in einem halben).
--- Code: ---ran 12.935000 seconds, MIPS: 262.852717
--- Ende Code ---
Warum hier keine besseren Werte rauskommen (also "echtes" superskalar x 2), weiß ich (noch) nicht. Die EMAC Units sind ein bißchen zimperlich, was die Registernutzung angeht und ich habe noch zu wenig damit gemacht um wirklich dahintergekommen zu sein, welches Register man wann "ungestraft" anfassen darf.
Die Werte des Apollo-Cores sind selbstverständlich beeindruckend. Einen so komplexen CPU-Core wie den des 060ers mit der Taktfrequenz ans Rennen zu bekommen, ist alles andere als trivial. Ich betone, ich will den hier absolut nicht schlechtreden, mir geht's nur darum, die Sinnlosigkeit solcher Benchmarks aufzuzeigen.
1ST1:
Darf ich das mal ins apollo-Forum rüberposten? Vielleicht lassen die ja die Variationen mal auf dem Apollo-Core laufen?
mfro:
--- Zitat von: 1ST1 am Fr 21.10.2016, 22:28:56 ---Darf ich das mal ins apollo-Forum rüberposten? Vielleicht lassen die ja die Variationen mal auf dem Apollo-Core laufen?
--- Ende Zitat ---
Klar darfst Du. Allerdings wird der zweite Teil nicht laufen bzw. in die entsprechenden Apollo-Gegenstücke umgewandelt werden müssen (falls es die gibt).
Der erste Teil wird niemanden erstaunen, der ungefähr weiß, was in der cf68klib passiert, bringt also keinen wirklich weiter.
Die fehlenden Instruktionen/Adressierungsarten sind zweifellos eine Einschränkung der Coldfires/FireBee, aber - mit realem Code - bei Weitem nicht so drastisch wie der "Benchmark" den Eindruck erweckt.
Dasselbe gilt übrigens auch für (zumindest einen) der anderen Benchmarks, den ich mir kurz angeschaut habe. Dort wird in einer Schleife mit NOP-Instruktionen gemessen (also, wie lange es dauert, "nichts" zu tun).
Dummerweise ist der ColdFire aber "beim Nichtstun besonders langsam". Die NOP-Instruktion braucht nicht nur selbst 6 Taktzyklen, sondern macht auch noch einen Pipeline-Flush (danach läuft die CPU mit nochmal sechs Takten Latenz erstmal neu an). Ersetzt man die NOP-Instruktion durch TPF (macht auch "nix", aber in nur einem Zyklus und spart sich den Pipeline-Flush), läuft die entsprechende Schleife 12 Mal schneller (aber auch das ist sehr synthetisch: kein realer Code wird unnötig lange "nichts" tun).
1ST1:
--- Zitat ---ADD.L #imm,An is fully supported by Coldfire.
Please check this yourself in Coldfire Programmer Reference Manual Page 4-4
--- Ende Zitat ---
Boah, die Antwort hier herüber zu setzen ist mir zu viel, er hat sehr ausführlich geantwortet... Du hast die äußere Schleife vergessen und die damit zusammenhängende Sprungvorhersage. Jedenfalls so tief bin ich in der 68K Assembler-Geschichte nicht mehr drin dass ich da jetzt eigenständig antworten könnte, ihr beide aber schon. Schau mal, vielleicht beteiligst du dich auch direkt an der Diskussion...?
http://www.apollo-core.com/knowledge.php?b=1¬e=2559
Für die Allgemeinheit nur kurz: Der Apollo läuft derzeit bei 80-90 MHz, was mit dem verwendeten bezahlbaren FPGA zusammen hängt. Damit kann Apollo aber schon flüssig MPEG dekodieren, laut Aussage bei manchen Videos sogar flüssiger als ein PPC mit 600 MHz in einem Amiga-NEO System. Man kann auch eine Vampire in der Preisklasse der Firebee bauen, mit einem entsprechenden FPGA und dann taktet das Ding bei 200 MHz, und wenn die ATARI- und AMIGA Gemeinde zusammen stehen würden und es verlangen würden und sich leisten könnten wäre auch ein ASIC mit 1 GHz möglich... Klingt auf jeden Fall vielversprechend.
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln