AW: Lang Emus auf Reflection Modul
 

Danke Markus, ja, die Ausstattung entspricht den Bildern des Genius in der Wiki. Beim Genius ist auch die Angabe der Speichergrößen/nutzung in meinen Augen sehr passend beschrieben mit "RAM 768 KB (512 KB Hash)". Die 256 KB RAM die nicht zum Hash gehören sind sehr schneller Arbeitsspeicher in dem das Programm läuft und andere Daten wie Suchbaum und Zwischenergebnisse der Berechnungen etc. abgelegt werden.

Wenn ich das richtig sehe, hast Du da übrigens 40 MHz Motorolas auf Deinen Modulen, die sind also quasi "untertaktet", was man eher selten sieht... ;)

Grüße
Andreas

AW: Lang Emus auf Reflection Modul
 

Naja, das kommt immer darauf an, wie die Software den Prozessor ausnutzt. Die in Internetquellen genannten Prozentzahlen gehen von verschiedenen Voraussetzungen aus. Der reine Prozessor (68030) bringt etwa 5 % mehr Performance als der 68020. Ist jetzt die Bus-Architektur im Gerät noch die des 68020 dann bleibt es dabei. Erst mit einem speziellen Bus-Interface werden die Speicherzugriffe um etwa ein Drittel erhöht. Summasummarum kommt man dann auf einen Performancegewinn von 15-20 Prozent. Aber eben nur, wenn die Gesamtarchitektur des Gerätes stimmt. Wie jetzt natürlich der Genius 030 hier intern aufgebaut ist, weiss ich nicht. Aber ich könnte mir schon vorstellen, dass eben kein spezielles Bus-Interface eingebaut ist. Das würde die nur geringen Unterschiede erklären.

AW: Lang Emus auf Reflection Modul
 

Vom technischen Aufbau her haben die 68030 Module bzw. TM auf jeden Fall ein besseres (schnelleres) Interface als die 68020. Nämlich unter Verwendung von 256 kByte statischen RAMs mit 20ns Zugriffszeit im Vergleich zu den sonst verwendeten dynamischen RAMs mit 70-100ns.

AW: Lang Emus auf Reflection Modul
 

Ich habe vorhin im Flugzeug in der Selective Search gestöbert und bin auf eine mögliche Erklärung für das Durcheinander gestoßen: Der Faktor 1,25 stammt wohl wirklich ursprünglich von Larry Kaufman, obwohl seine Test an den Elite-Rechnern nur den Faktor 1,18 ergeben haben. Einigen Tabellen nach glaube ich, dass dieser Faktor der leichteren Umrechenbarkeit so gewählt wurde, denn auch andere Faktoren sind eher glatt.
Ich werde daher wohl meine CPU-Liste mit dem Faktor 1,18 versehen.

AW: Lang Emus auf Reflection Modul
 

Das Bus Interface und der Speicher sind 2 verschiedene Dinge. Der statische RAM dürfte vermutlich für die Hash-Tables gedacht sein. Das beschleunigt natürlich den Zugriff auf solche Informationen. Mit der reinen Rechenleistung hat das aber wenig zu tun.

Mit Bus Interface meine ich den Datenbus, der programmtechnisch benutzt wird. Der 68030 besitzt ein zusätzliches synchrones Bus Interface (zusätzlich zu dem asynchronen das ebenfalls vorhanden ist). Wird dieses programmtechnisch angesprochen, dann laufen einige Dinge etwas flotter ab. Das ist aber ein programmtechnisches Problem. Man kann ein Programm auch auf den 68030 anpassen, ohne dieses Interface direkt anzusprechen (muss man bei Assembler-Programmierung auch, da der 68030 einige Anweisungen des 68020 nicht mehr hat, bei Hochsprachen macht das der Compiler). Inwieweit King Richard das aber gemacht hat, weiss wohl nur er selbst.

AW: Lang Emus auf Reflection Modul
 

Hochsprache hat Richard nicht benutzt (benutzen können), einfaches Umstellen eines Compiler-Schalters scheidet also aus... Die Frage ist, wie kompliziert die Anpassung aufs Bus-System ist. Wenn es mit wenig Zeitaufwand machbar war, wird er es gemacht haben. Ansonsten vermutlich eher nicht.

Es ist von der Speichergröße nach Analyse der Hardwareausstattung wie oben schon ausgeführt tatsächlich so, dass der PROGRAMM-Speicher der schnelle mit den statischen Bausteinen mit 20ns Zugriffszeit ist! Es sind dies 256 kByte bei 68030. Während der Hash mit 512 kByte bis 8 MByte im DRAM mit 70-100ns je nach Modell liegt.

Und deswegen denke ich, dass dieser schnellere Speicher das Programm schon im Ablauf beschleunigt. Zumindest gegenüber einem 68020, welcher den schnellen statischen RAM eben nicht hat.

Sorry, falls es unklar formuliert war. Ich kenne mich mit Motorola Innenleben nicht wirklich gut aus, da ich damals direkt den Sprung von U880 (Z80) und 6502 auf 386 gegangen bin...

AW: Lang Emus auf Reflection Modul
 

Eher unwahrscheinlich dass der schnelle Programmspeicher solche Auswirkungen hat. Der schnellste Motorola kann die Befehle nicht so schnell abarbeiten wie der Speicher die Daten liefern kann. Insofern bewegen sich die Vorteile durch die schnellen ROM-Speicher wohl eher im Promillebereich. Viel wichtiger wäre hier der Speicher für den Hash gewesen. Damit hätte man tatsächlich noch mehr herauskitzeln können.

AW: Lang Emus auf Reflection Modul
 

Das Programm legt nicht nur Daten im Hash ab. Insofern halte ich die 20ns RAM nicht für falsch dimensioniert. Ich kann mir auch nicht vorstellen, dass die H&G Entwickler hier aus Spaß schnellere Chips als notwendig verbaut haben...

Dass der Hash langsamer ist, hat vermutlich Platz (Genius) als auch Kostengründe (TM, hier wäre zumindest Platz gewesen). Vl. waren es aber auch pragmatische Erwägungen, dass es beim Hash doch nicht soo viel ausmacht? Also der Vorteil durch den Hash an sich ist enorm. Den dann gegen hohe Kosten nochmal etwa um Faktor 3 zu beschleunigen, bringt ev. nicht mehr den entscheidenden Gewinn. So mag die Überlegung gewesen sein...

AW: Lang Emus auf Reflection Modul
 

Im Richard Lang modulen wird dem schachprogramcode kopiert nach dem meist hochgeschwindige RAM. Am besten dem sogennante cache rams (~20ns), die genutzt werden im TM. Die Hash tabelle brauchen eigentlich keinem schnellen ram. Deswegen das im TM diesem ram SRDAM ist (>50ns) . Warum ? die Hash soll schnell sein, aber im code ist zugriff am Hash nur relativ wenig. Die programm code soll die schnellste sein. Nicht dem Hash zugriff.

Kopieren dem code ist wegen das die Eprom sehr langsam ist, und dabei nur 8 oder beim 2 eprom 16 bit breit. Die Tasc machen exact dasselbe.

Im zeitem dem modulen war dem cache RAM sehr teuer, entgegen dem SDRAM.

Ubrigens werden die Cache RAMS nicht als L2 oder L3 cache genutzt. Wenn das so war, dan war einem kopie nicht benotigt nach das RAM.

AW: Lang Emus auf Reflection Modul
 

Die 68020 hatte eine kleine Pipeline (damit kann die Ausführung eines Befehls schon begonnen werden während der vorige noch bearbeitet wird). Allerdings muss die Pipeline oft weggeworfen werden, d.h. der Nutzen ist gering und braucht ein optimiertes Programm (z.B. durch Umstellung von Befehlen ohne nötige Reihenfolge).
Außerdem wurde ein kleiner Cache (256 Bytes) vorgesehen, das vermeidet viele der sonst eventuell nötigen Waitstates. Allerdings profitieren dabei vor allem kleine, oft hintereinander genutzte Programmteile ohne zu viele Speicherzugriffe für Daten. Kleine Schleifen, die mit Daten in Daten in den Registern arbeiten sind also ideal.

Bei der 68030 kommt jetzt noch ein Datencache von 256 Byte hinzu. Damit werden Rechnungen auf kleinen Datenmengen gut beschleunigt, aber bei "richtigen" Programmen geht die Trefferquote schnell in den Keller. Nur wenige Variablen (die bereits bevorzugt Register belegen) profitieren davon, meist wirft ein Zugriff etwas anderes raus, was dann ein paar Takte wieder geladen werden muss. Der Cache ist also besser als nichts, aber nicht z.B. mit den 32 KB bei Rechnern mit 80386 und 33 MHz vergleichbar ist.

Der Zugriff auf Hashtables ist nur ein kleiner Teil der Berechnung eines Knotens, d.h. der Zeitaufwand für Waitstates bei vier oder sechs Zugriffen pro Knoten (8 oder 12 Bytes erst lesen und dann ggf. speichern) spielt letztlich keine große Rolle.
Es ist daher eine durchaus plausible Rechnung, wenn statt einer externen Cachelogik mit extra RAM (mehrere Chips für 32 Bit-Zugriffe) gleich statisches RAM für den normalen Speicher vorgesehen wird und für die Hashtables langsameren und preiswerteren Speicher. Außerdem wird durch die Trennung die Aufrüstung einfacher und preiswerter möglich.

AW: Lang Emus auf Reflection Modul
 

Danke Ruud für die Bestätigung der Überlegungen zum ROM. Es macht anders wirklich keinen Sinn und erklärt, warum langsame EPROMS ausreichen und vor allem 1 einziges mit 8 Bit Breite...

Aus theoretischen Erwägungen müsste der interne (sowieso sehr kleine) Cache unwirksam sein, da der externe 20ns SRAM auch ohne Waitstates genutzt werden kann. Zumindest bei den genutzten Frequenzen von 25 oder 33 MHz. Bei den Intel-System gab es damals sogar den Effekt, dass ein Cache Miss zu einem langsameren Speicherzugriff führte, als wenn gar kein Cache vorhanden gewesen wäre...

AW: Lang Emus auf Reflection Modul
 

OK, soweit so gut. Die Überlegung ist schon logisch. Sinn macht es trotzdem nicht. Der Geschwindigkeitsvorteil macht bei den damaligen Prozessoren keinen Unterschied (im Gegensatz zu den heutigen Prozessoren, da werden schnelle SRAMs z.B bei Grafikkarten eingesetzt). Der einzige Vorteil wäre allenfalls der, dass man den Speicher mit einer Batterie puffern kann um z.B. eine programmierbare Eröffnungsbibliothek oder eine alte Stellung zu speichern (geht beim Genius meines Wissens). Dieses Prinzip wurde z.B. für das BIOS eines PCs früher verwendet (heute nimmt man da Flash-Speicher). Der 68030 ist gar nicht schnell genug um den Vorteil des SRAMs ausnutzen zu können. Das Programm wäre auch mit DRAM nicht wirklich langsamer. Eventuell liegt der Sinn des SRAMs auch in der Ansteuerung des elektronischen Schachbrettes begründet... da könnte es zumindest Sinn machen (SRAM wird gern bei Echtzeitsystenen eingesetzt. Die Brettansteuerung wäre da durchaus vergleichbar).

AW: Lang Emus auf Reflection Modul
 

Beim Mac II (68020 mit 16 MHz) wurden 130ns-RAM benutzt, mit 2 Waitstates.
Schnelleres RAM mit 80ns hätte 1 Waitstate bedeutet.
Beim Mac IIci (68030 mit 25 MHz) wurde auf das 80ns-RAM mit 2 Waitstaes zugegriffen, so dass ein 32 KB großer Cache (SRAM mit 25ns) verwendet wurde, dies brachte minestens 15% mehr Geschwindigkeit.

Diese Zahlen passen auch zu den PC aus den Jahren.

Nun ist aber der Aufwand bei Mac und PC für einige MB Hauptspeicher gedacht und bei einem Schachcomputer bringen die paar Takte pro Knoten beim Speicher für Hash nicht so viel und 256 KB SRAM dürften billiger als 32 KB SRAM plus Cachelogik plus DRAM sein. Jeder Chip weniger spart Geld.

AW: Lang Emus auf Reflection Modul
 

Hartmut, ich hatte das oben bereits beschrieben. Für den Stellungsspeicher gibt es einen eigenen SRAM. Bei den Modulsets befindet sich dieser im Display-Modul inkl. Pufferbatterie. Bei den TMs auf der Hauptplatine. Jeweils in (preiswerter) langsamer Ausführung um 100ns.

Die Brettansteuerung ist zwangsläufig in jedem Mephisto Modulset enthalten. Sie erfolgt über Adressdecoder im Modul und durch diese aktivierte Register/Latches direkt im Brett. SRAM Speicher ist hierfür nicht vonnöten und auch gar nicht in jedem Modulset enthalten.

Die 20ns SRAMs im 68030 Genius und TM machen die Verwendung nur eines einzigen 8Bit Eproms in langsamer Ausführung erst möglich. Sicher hätte man hier auch langsamere Speicher benutzen können, die wären preiswerter gewesen und hätten weniger Platzbedarf gehabt. Es muss also einen Sinn ergeben, genau diese schnellen Chips einzusetzen. Und den sehe ich im Einsparen von Waitstate Zyklen. Bei 33 und mehr MHz Takt sind 100ns RAMs ohne Waistates nicht ansprechbar, es sei denn man arbeitet mit Tricks wie mehreren Bänken die interleaved angesprochen werden. Dies wäre im Genius Modul vom Platzbedarf her schwierig geworden.

Ich schließe mich Solwac an: die Speicherzugriffe werden beschleunigt und das System ist insgesamt platz- wie auch kostenoptimiert.

Grüße
Andreas

AW: Lang Emus auf Reflection Modul
 

Naja, ich bin auch Informatiker. Und nebenbei mit den Macs aufgewachsen (Solwac allerdings vermutlich auch, nachdem er die Macs als Beispiel hernimmt. (Mein erster Rechner nach meinem 64er Hobby war ein Mac Plus 68000, später die Mac II Serie und auch die frühen Power PCs, beruflich war ich damals im Mac-Service als Techniker). Insofern sage ich mal: "Nicht alles was in der Computerherstellung, auch der Schachcomputerherstellung, so gemacht wurde, war auch wirklich sinnvoll. Und da bilden die Schachcomputer keine Ausnahme, die "Profis" bei Apple waren teilweise auch nicht besser.

Da gebe ich Dir recht. Sowohl was die 100ns-RAMs betrifft als auch was das eventuelle Tricksen angeht. Allerdings. Zu den Zeiten als diese Prozessoren groß waren wurde bereits mit schnelleren DRAMs gearbeitet. Von den Spezifikationen für einen 68030 mit 25 MHz wurden normalerweise 80ns-RAMs und keine 100er verwendet. Wenn in den Mephistos langsamere verbaut wurden, dann hat man das System eher künstlich gebremst. Als ich damals Mac-Händler war, hatten die 030er ab 25 MHz Takt standardmäßig 80 ns-RAMs eingebaut. Bei Speichererweiterungen habe ich den Kunden damals meist sogar schnellere 70 ns oder 60 ns Speicher verkauft (noch schnellere gab es damals nicht). Es wäre also durchaus möglich gewesen mit schnellerem DRAM zu arbeiten.

wäre mit dem richtigen DRAM auch gegangen... wenn man natürlich nur die nimmt, die den Mindestanforderungen entsprechen erreicht man natürlich nur wenig. By the way. Hier ist eher der Burst-Modus des 68030 relevant, der entsprechend viel Speicher auf einmal abfragt ohne dass der Prozi jedes byte anfragen muss. Da liefert dann auch das DRAM die Daten schneller als der Prozi sie überhaupt verarbeitet, weswegen ja auch ein entsprechender Prozessorcache vorhanden ist. Auch SRAM liefert die Daten nicht schneller als der Prozessor sie anfrägt. Zwar ist (zumindest symetrisches) SRAM von den Systemzyklen relativ unabhängig, aber nichtsdestotrotz muss der Prozessor die Daten anfragen und auch verarbeiten. Und genau da ist eben das Problem. Er kann es nicht. Bei den heutigen Rechnern würde ich dir allerdings sofort recht geben. Die Speicherbausteine halten mit den Geschwindigkeiten der Prozessoren schon lange nicht mehr mit. Nur ist der Speicherbedarf auch so angestiegen dass man allein aus Kostengründen mit SRAMs nicht mehr arbeiten könnte.

Eben nicht. SRAM braucht etwa die 4fache Siliziumfläche wie gleichartiger DRAM. Da kann man nun wirklich nicht mehr von "platzoptimiert" reden. Selbst wenn man jetzt noch eine Cachelogik (oder zumindest die bei DRAM erforderlichen Kondensatoren) dazurechnet, wäre der Platzbedarf geringer und kostengünstiger. Der Performanceverlust wäre hingegen bei diesem Prozessortyp wohl eher vernachlässigbar. Inwieweit das dann kostenoptimiert sein soll... Klar, wenn ich Solvacs Rechnung zugrundelege, könnte man das rein theoretisch denken aber...

Da gebe ich Dir natürlich recht. Die Aussage wird aber dadurch relativiert, dass bei den Mephistos sowieso DRAM verarbeitet wurde, nämlich für den Hash-Speicher. Insofern hat man also bereits SRAM und DRAM vereint. Die Cahchelogik ist jetzt bei den Kosten nicht mehr wirklich das große Problem und eigentlich eher Sache des Prozessors, der ja bereits einen kleinen Cache hat (der auch durchaus ausreichend ist). Daher erschließt sich mir nicht, wo hier die Kosteneinsparung liegen soll.

Gut, mag sein, dass sich die Entwickler bei H&G was dabei gedacht haben, als sie die Dinger so entwickelt haben, wie sie eben jetzt sind. Umsonst macht man so eine Mixtur aus SRAM und DRAM sonst nicht. Ich zweifle nur daran, dass es wirklich so effizient ist, wie man es sich vorgestellt hat.

Der einzig wirklich gute Effekt ist der geringere Energieverbrauch, der bei der Benutzung von SRAM anfällt. Allerdings habe ich meine Zweifel, dass das die Idee der Platinenplanung war...

AW: Lang Emus auf Reflection Modul
 

Jungs,

Und dann noch etwas interessantes.
Beim Richard Lang Modulen gibt es auch, beim nutzing SDRAM, das die CPU (68020) dem ganze SDRAM bereich periodisch lest und schreibt. Das wird vonaus dem interrupt gemacht.

Wenn ich die emulationen geschriebe haben habe ich bemerkt das 5% von dem CPU grosse bereiche von RAM gelesen und geschrieben werden, mit einem copy instruktion wobei source=destination.

Wenn ich es gut habe passiert das nicht beim dem TM fur dem SDram, da ist SDram ******* logic aussen dem cpu da.

... anderung, fremd, da wird einem r e f r e s h wordt als nicht erlaubt gegeben im forum ;)

AW: Lang Emus auf Reflection Modul
 

Ne, ich habe nie wirklich mit einem Mac gearbeitet. Aber die Macs sind im Netz gut dokumentiert. ;)

Die schnelleren Chips bieten natürlich Vorteile bei anderen Frequenzen als 25 MHz, aber reicht es schon um sicher einen der zwei Waitstates zu vermeiden?

Du rechnest in Transistoren, H&G wird aber in Platinenflächen und Kosten für die Chips gerechnet haben. Der Energieverbrauch wird erst bei möglichem Batteriebetrieb eine Rolle gespielt haben.

AW: Lang Emus auf Reflection Modul
 

Die Frage kann ich natürlich nicht für jeden Rechner beantworten. Beim 68030/33 sollte es aber eigentlich reichen, zumal sich im Bursst-Modus des Prozessors dieses Problem in der Regel nicht oder nur selten stellt. Ich hatte damals bei meinen Macs ja auch Schachprogramm drauf (es gab nicht viele, aber es gab sie). Bei den Macs mit 030-Prozessor machte sich schnelleres RAM deutlich bemerkbar. Beim 020 eher weniger (aber der hatte eben auch nicht den Burst-Modus des 030ers)

Öhm, ich kenne zwar theoretisch den Transistoraufbau eines SRAMs, aber ich habe die Transistoren eigentlich nicht erwähnt. Ich sprach von der Siliziumfläche. Ich weiss ja nun nicht genau ob die Speicher jetzt in Form von SIMMs oder sowas verbaut wurden (wenn ich mir die Höhe der Module ansehe, dann vermutlich nicht) oder direkt auf die Platine gesetzt wurden (was wahrscheinlicher ist). Aber in letzterem Fall hat das natürlich auch direkten Einfluß auf die benötigte Platinenfläche. Und über die Kosten von SRAM müssen wir ja nicht reden. Sie sind höher als bei DRAM. Genau deswegen irritiert mich die ganze Geschichte ja. Sie ergibt keinen wirklichen Sinn. Aber gut... selbst bei heutigen Computerplatinen ergibt manches nur wenig Sinn. Sonst hätte man ja im Netz nix zu motzen, grins

AW: Lang Emus auf Reflection Modul
 

:D