Waum sehen Array-Read[]/Write[]-Macros eigentlich so aus ?

[krümelmonster]

Was ich mich frage, ist, wieso die CoreArray-Read/Write-Macros so aufgebaut sind, wie sie sind.
Ich meine die Reihenfolge der Inputs.

Daß die ArrayOBC-Inputs ganz zu unterst angebracht sind, ließe sich noch damit erklären, daß OBC-Verbindungen ihre Information "sowieso teilen", also sofort, auch über Macro-Grenzen hinweg.
Aber dies wäre zunächst einmal nur eine Annahme. Läßt man sie beiseite, müsste der ArrayOBC-Input eines Read[]-Macros doch nach oben, wollte man sicherstellen, daß der Array ein "aktualisierter" ist. Na gut.

Merkwürdiger ist allerdings die Anordnung der anderen beiden Inputs:
Read[]: Zuerst wird der Wert eingelesen, dann erst der Index angegeben ?
Auch in Core hat man es mit der Reihenfolge der Abarbeitung von Events zu tun. Der oberste Eingang feuert zuerst.
Für mich würde es in diesem Fall bedeuten, daß zuerst ein Wert eingelesen wird und zwar in das Array-Element, daß vorher anvisiert worden ist. Anschließend wird ein neues Array-Element anvisiert.
Daß das so nicht gehen kann liegt auf der Hand. Ich gehe auch einmal davon aus, daß die Macros funktionieren.
Es wäre ja zu spaßig, wenn alle Welt immer nur zyklische Dinge damit basteln würde und sich ein solcher Fehler zyklisch selbst korrigieren würde.
Trotzdem - für meine Logik gehört das eigentlich vertauscht.
Gerald.

[herw]

...Merkwürdiger ist allerdings die Anordnung der anderen beiden Inputs:
Read[]: Zuerst wird der Wert eingelesen, dann erst der Index angegeben ?
Auch in Core hat man es mit der Reihenfolge der Abarbeitung von Events zu tun. Der oberste Eingang feuert zuerst.

wenn die beiden Eingänge zu unterschiedlichen Zeiten befeuert werden, dann ist wegen der inneren Struktur von READ[] der Clock-Eingang (der oberste Eingang) derjenige, der bestimmt, welcher Wert gesendet wird:

Kommt der Clock-Event vor dem Index-Event, dann wird der alte Index als Zugriffsadresse gewählt; sicherlich unerwünscht, wie du das oben erläuterst. Das heißt bei kritischen Schaltungen müsste man in der Tat sicherstellen, dass der gewünschte Index-Event vor dem Clocksignal aktualisiert wurde. Wenn diese Signale vom primary level kommen, muss man das dort ohnehin regeln, da es dort auch keine logische Gleichzeitigkeit gibt. Im core-level müsste man wenigstens auf (logische) Gleichzeitigkeit achten (Core-Handbuch S.65).

Für mich würde es in diesem Fall bedeuten, daß zuerst ein Wert eingelesen wird und zwar in das Array-Element, das vorher anvisiert worden ist. Anschließend wird ein neues Array-Element anvisiert.
Daß das so nicht gehen kann liegt auf der Hand. Ich gehe auch einmal davon aus, daß die Macros funktionieren...Gerald.

ich weiß nicht, ob Du da nicht etwas vertauschst: das READ[]-Modul liest keine Werte in das Array ein, sondern liest sie aus dem Array.

Aber das ändert nichts an der Folgerichtigkeit deiner Bemerkung.
Ich denke, dass der Clock-Eingang als oberster Eingang gewählt wurde, da sonst die innere Struktur des READ[] etwas seltsam aussehen würde. Anscheinend wurde darauf geachtet, einheitlich die clock-Eingänge nach oben zu legen

ciao herw