GOTOs verhindern das RAM-Cachen - ist das richtig?

[NicoDE]

Zitat von Chewie:

Auf Maschinenebene gibt es nur Sprünge, keine Funktionen.

Bei einem 'call' wird die Rücksprungadresse auf den Stack gelegt und bei 'ret' selbige wieder vom Stack geholt. Das würde ich nicht mehr als Sprung bezeichnen.

[Chewie]

Hm, ich schon. Nur weil zusätzlich noch was auf den Stack gelegt wird, wird trotzdem gesprungen.

[ripper8472]

Ob ihr das nun Sprung nennen wollt oder nicht, der Programmzeiger wird trotzdem auf einen anderen Speicherbereich gesetzt. Und das bei Call und Jump.

[Hansa]

fast OT: goto landet im Nirwana. Das ist das Problem. Strukturierte Programmierung ist damit fast unmöglich. 8)

[dizzy]

Nochmal zum Thema Pipelining: Der Cache kann keinen Sprung vorhersagen, da der Sprung letztendlich vom Prozessor ausgeführt wird. Und sobald der Opcode in der CPU ist, hat er den Cache bereits passiert. Eine 100% zuverlässige Sprungvorhersage ließe sich nur mit einem 2. vorgeschalteten Prozessor machen, der zumindest Sprünge erkennt, und auch deren Ziele berechnen kann. Und das so schnell, dass durch das Springen im RAM, im Cache kein Bubble entsteht. Und für die entsprechende Schnelligkeit wäre für diesen Prä-Prozessor bestimmt auch eine Pipeline nötig... . Ist eine Frage von Kosten/Nutzen

Was aber duchaus stimmt: Auch mit GOTOs ärgert man eine Pipeline ganz schön, aber auch mit calls und jumps.
Der wirkliche Grund dafür dass GOTOs in Ungnade gefallen sind, ist wie bereits erwähnt die Tatsache dass Code dann sehr schnell sehr unleserlich und sehr schwer zu warten wird.

[ripper8472]

Ich habs noch nie probiert, aber es müsste rein theoretisch möglich sein, mit so einem goto aus ner Rekursion zu springen, *irgendwo anders* weiterzumachen, dann wieder in die Rekursion zurückzuspringen und regulär beenden. Muss man nur zusehen, dass man nur dann zurückspringt, wenn der Stackpointer auch wieder die richtige Position hat... Nur mal zum Thema "Schwachsinn mit Calls und Jumps" *g*

[dizzy]

Hmmm, ich wage mal zu vermuten, dass die Labels/Sprungmarken lokal begrenzt sind, du also nur innerhalb einer Prozedur hüpfen kannst.
Aber prinzipiell ist es ja auch in einer normalen Rekursion möglich kurz rauszuspringen, da du ja auch Funktionsaufrufe dort machen kannst. Nur ist der Rücksprung halt garantiert.

[ripper8472]

aber die Pipelines werden in jedem Fall geleert!

[Tubos]

Zitat:

Nochmal zum Thema Pipelining: Der Cache kann keinen Sprung vorhersagen, da der Sprung letztendlich vom Prozessor ausgeführt wird. Und sobald der Opcode in der CPU ist, hat er den Cache bereits passiert. Eine 100% zuverlässige Sprungvorhersage ließe sich nur mit einem 2. vorgeschalteten Prozessor machen, der zumindest Sprünge erkennt, und auch deren Ziele berechnen kann. Und das so schnell, dass durch das Springen im RAM, im Cache kein Bubble entsteht. Und für die entsprechende Schnelligkeit wäre für diesen Prä-Prozessor bestimmt auch eine Pipeline nötig... . Ist eine Frage von Kosten/Nutzen

Wäre das dann Hyperthreading?

Werden Sprünge jetzt gecacht oder nicht?

[ripper8472]

Sprünge werden nicht gecacht, um es einfach auszudrücken. Der Prozessor kann nicht vorahnen, wohin gesprungen wird.

HyperThreading (von Intel) simuliert 2 CPUs. Wenn eine CPU mit dem Cachen beschäftigt ist, bekommt die andere die volle physische Zeit. Sonst teilen sich beide die physische CPU.