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...

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.

__________________
Mein Profil beim ICCF (International Correspondence Chess Federation)
https://www.iccf.com/player?id=89948&tab=3

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...

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.

__________________
Grusse,
Ruud Martin

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.

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...

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).

__________________
Mein Profil beim ICCF (International Correspondence Chess Federation)
https://www.iccf.com/player?id=89948&tab=3

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.

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

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...

__________________
Mein Profil beim ICCF (International Correspondence Chess Federation)
https://www.iccf.com/player?id=89948&tab=3