3. monotonic_buffer_resource sorgt für DMA Interrupt Error

monotonic_buffer_resource sorgt für DMA Interrupt Error

  • D

    Sorry, war ein paar Tage Off, mich hat die Rüsselseuche aufgesucht, vom aller besten.☠

    @Finnegan sagte in monotonic_buffer_resource sorgt für DMA Interrupt Error:

    Ich muss tatsächlich sagen, dass ich bisher schwer beeindruckt bin. Ich hatte im "Thinking Modus" bisher nur zwei Fälle, wo diese KI einen Fehler gemacht hat. Den meisten Code versteht sie, ohne dass ich wie bei DeepSeek oder ChatGPT erstmal erklären muss, was da passiert.

    Dito.
    Nur wenn der Code oder das gesamte Konstrukt zu umfangreich wird, wird es meist auch nichts.
    Der VU Micro Code wird normalerweise in Low level Assambler Programmiert sprich so:
    https://github.com/ps2dev/ps2gl/blob/master/vu1/general_nospec_quad_vcl.vsm
    Das geübte Auge sieht es sind Dual-issue SIMD Instruktionen😨

    Das kann kein Mensch lesen (bzw nur mühsam), deswegen macht man einen Zwischenschritt, man schreibt den VU Code in Vector Command Line (VCL) übersetzt das in VSM und das wird ver-Assmbliert.
    Siehe:
    https://github.com/ps2dev/ps2gl/tree/master/vu1
    und
    https://github.com/jsvennevid/openvcl

    Wenn man nun VCL schreibt und man kommt nicht weiter, dann schafft es google Gemeni irgendwie trotzdem VCL code zu schreiben ohne das es überhaupt weiß wie der code Funktioniert.
    Man muss es aber dennoch mit zuarbeiten füttern. Vor allem Register dump's sind wichtig.

    Aprops Dump, mein Problem ist zurück nur anders.
    Es steht nicht mehr DMA Bus error, sondern TLB...:

    # TLB spad=0 kernel=1:12 default=13:36 extended=37:47
*** Unexpected reply - type=BREAKR result=PROGEND
dsedb S> dr
 at=70030c00  v0-1=00000030,00000010  a0-3=00000001,01ffe000,36000000,0018003f
 t0-7=001c003f,b000e020,b000c800,00800000, 205ab300,a0000000,00000004,0000001f
 s0-7=00000001,00420000,0078c790,000000dd, 004288c0,07ffd8f0,002f0fa0,07ffe2c0
 t8=80025980 t9=00000030   k0=80016ed8 k1=00000000   gp=00425d70 sp=8001d470
 fp=005b0000 ra=80000304   lo=00000024 hi=00000000   sa=00000000 PC=80000d80
 badvaddr=40000b26 badpaddr=86a08480
 $cause   = 0x40008024 [ BD2 CE0 EXC2=Reset IP7 EXC="Breakpoint" ]
 $status  = 0x70030c02 [ Cu210 EDI EIE IM3 IM2 KSU=Kernel EXL ]
  0x80000d78: 0x00000000  nop
  0x80000d7c: 0x00000000  nop
->0x80000d80: 0x03ffffcd  break   0xfffff
  0x80000d84: 0x00000000  nop
  0x80000d88: 0x00000000  nop
  0x80000d8c: 0x00000000  nop
  0x80000d90: 0x00000000  nop

    ra (0x80000304) ist auch hier wider absoluter Müll

    Wenn man jetzt noch weiß das der IOP auch noch Ausgaben macht, dann steht da:
    terminate called after throwing an instance of 'std::bad_alloc'
    what(): std::bad_alloc

    Das Problem ist der Cache-Algorithmus, dieser schreibt bei jedem DMA Transfer, die Daten dahin zurück wo er sie ursprünglich mal herbekommen hat. Das Müllt mir Ruck Zuck die monotonic buffer resource zu.
    Ich habe da jetzt eine unsynchronized_pool_resource ringsum gebaut und es ist Ruhe im Karton.

    0
    F
     1 Antwort
  • F

    @D_Key sagte in monotonic_buffer_resource sorgt für DMA Interrupt Error:

    https://github.com/ps2dev/ps2gl/blob/master/vu1/general_nospec_quad_vcl.vsm

    Interessant. Was ist das mit den zwei Spalten die scheinbar auch noch einen anderen Dialekt verwenden?
    Ist das paralleler Code für zwei "CPUs" die am selben Takt hängen und mit den ganzen NOPs synchronisiert werden?

    Ich glaube das ist schon ein Beispiel für das was ich mit "kompliziert zu programmieren" meinte 😉

    Ich kämpfe zum Glück nur mit einem "Strang", dafür aber mit 2 "Betriebsmodi" der x86 CPU und habe es in der Lowlevel-Runtime viel mit verschachteltem 16- un 32-Bit Code zu tun, die teilweise unterschiedlichen Regeln folgen. Das Hauptprogramm ist 32-bit, aber BIOS (Firmware) und OS (DOS) sind 16-bit Code. Das kann auch kompliziert werden, zumal der 16-Bit Modus (Real Mode) auch noch mit diesem unsäglichen segmentierten Speichermodell arbeitet (das existiert zwar auch noch im 32-Bit Modus, aber da findet meist alles in einem einzigen 4GiB großen "Segment" statt).

    Wobei die Hauptschwierigkeit ist, einen "transparenten" Layer zu schaffen, er diese ganze Komplexität wegabstrahiert. Den überarbeite ich gerade, daher schwirrt mit da im Moment auch wieder der Kopf. Der User bekommt davon letztendlich nichts mit, der darf ganz normal in modernem C++26 programmieren, ohne zu wissen, wie dicht am "Metall" sein Programm letztendlich arbeitet: Bau einen Buffer Overflow in deinen std::vector-Zugriff ein, und es kann durchaus passieren, dass du damit den DOS-Kernel überschreibst. Mit lustigen Resultaten 😉

    Es ist aber genau diese uneingeschränkte Umgebung, wie zu alten "16-bit DOS-Zeiten" die ich mit diesem Projekt anstrebe. Nur eben ohne den limitierten Speicher und dieses segmentierte Speichermodell. Zielgruppe: Retroprogrammierungs-Enthusiasten, die Demos und Spiele mit modernen Tools schreiben wollen (Aktuellster GCC, C++26, GDB-Remote-Debuggig, LTO-Optimierung, etc.).

    1
Anmelden zum Antworten