Hardware > Hardware (Classic 16-/32-Bit)
PAK68/2 Platinen Projekt ...
czietz:
--- Zitat von: Arne am Fr 10.06.2016, 18:47:08 ---/CIIN - in Zusammenhang mit /BR, /BG und /BGACK
--- Ende Zitat ---
/CIIN verhindert doch nur, dass ein vom Bus gelesenes Datenwort im Cache landet? Das ist bei IO-Zugriffen natürlich richtigerweise aktiviert, das ist auch genau das, was das GAL im Artikel macht.
Wenn ich aber nun ein Wort aus cachebarem RAM lese (/CIIN = high), landet es im Cache und zukünftige Lesezugriffe werden natürlich aus dem Cache bedient und landen nicht mehr auf dem Bus.
Wenn sich dann aber das Wort im RAM durch einen DMA-Zugriff ändert, wie teile ich der CPU per Signal mit, dass dieses Wort im Cache invalidiert werden soll? Klar, per Software geht das (Cache Control Register) aber per Hardware-Signal? /CIIN hilft nach meinem Verständnis dort nicht weiter, weil die CPU ja gar keine Bus-Zugriffe auf die betroffene Adresse macht. Eigentlich kann ich da nur wie von joejoe geschrieben den kompletten vom DMA erreichbaren RAM vorsichtshalber als nicht-cachebar markieren.
czietz:
--- Zitat von: czietz am Fr 10.06.2016, 18:31:09 ---Invalidieren TOS-Versionen, die auf einem 68030 laufen, denn wenigstens den Cache für den entsprechenden Speicherbereich, bevor sie DMA-Zugriffe starten? Dann wären nur Programme gefährdet, die den DMA direkt programmieren, an TOS vorbei.
Wie ist das eigentlich im TT gelöst?
--- Ende Zitat ---
Und das kann ich mir selbst beantworten mit dem TT030 Companion [1]: "any program which uses DMA directly (as opposed to making the BIOS or XBIOS calls) needs to invalidate the caches after the DMA operation completes".
Also: Es kümmert sich nicht die Hardware darum, nach DMA den Cache zu löschen. TOS auf dem TT macht es, aber Programme die eigene DMA-Zugriffe machen (z.B. Festplattentreiber) müssen sich auch selbst um den Cache kümmern. Wenn man nur nach dieser Devise entwickelte Software einsetzt, kann man allen RAM cachebar machen und das GAL wird -- wie von mir schon geschrieben -- sehr einfach.
[1] http://dev-docs.atariforge.org/files/TT030_Companion-Dev_Notes.pdf
joejoe:
--- Zitat ---? /CIIN hilft nach meinem Verständnis dort nicht weiter, weil die CPU ja gar keine Bus-Zugriffe auf die betroffene Adresse macht
--- Ende Zitat ---
na ja, die CPU liest natürlich trotzdem vom Bus. Wenn aber bei allen relevanten Zugriffen durch eine Hardware-Logik das CIIN-Signal aktiviert wird, landen die Daten der betreffenden Adressen eben nicht im Cache, damit sollte das Problem auch lösbar sein. Wobei /CIIN = A24 das Thema dann recht simple löst.
Arne:
Alternativ könnte (ein gepatchtes) TOS 3.06 das CI-Bit der Pagedeskriptoren für non-cacheable Bereiche setzen. Hab mir aber die MMU nie genau angesehen.
czietz:
--- Zitat von: joejoe am Fr 10.06.2016, 19:27:53 ---na ja, die CPU liest natürlich trotzdem vom Bus. Wenn aber bei allen relevanten Zugriffen durch eine Hardware-Logik das CIIN-Signal aktiviert wird, landen die Daten der betreffenden Adressen eben nicht im Cache, damit sollte das Problem auch lösbar sein.
--- Ende Zitat ---
Drücke ich mich irgendwie unverständlich aus? Es geht doch gerade darum, dass wenn ein Wort einmal im Cache ist, es kein Hardware-Signal mehr gibt, der CPU mitzuteilen, es nicht mehr zu verwenden, weil es unterdessen von DMA modifiziert wurde. Genau in diesem Fall hilft /CIIN überhaupt nicht mehr weiter, denn es hätte schon beim ersten Zugriff gesetzt sein müssen, als man evtl. noch gar nicht wusste, dass DMA später in diesen Speicheradresse schreiben würde.
Entweder muss die Software nach DMA den Cache invalidieren (wie es Atari beim TT empfiehlt und ich bereits schrieb) ...
--- Zitat von: joejoe am Fr 10.06.2016, 19:27:53 ---Wobei /CIIN = A24 das Thema dann recht simple löst.
--- Ende Zitat ---
... oder man muss das komplette ST-RAM vorsorglich als nicht-cachebar markieren (wie Du vorgeschlagen hast und ich ebenfalls bereits schrieb) und halt auf die Vorteile des Caches für das ST-RAM verzichten.
Beides ist keine optimale Lösung, weil man im ersten Fall auf anständig programmierte Software angewiesen ist und im zweiten Fall Performance verschenkt, gerade das langsamere ST-RAM gar nicht zu cachen.
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln