Diskussion:Stapelspeicher/Archiv/1

message: Ich vermisse einen Verweis auf einen double-ended-Queue, auch Prioritätswarteschlange oder zweiendige Warteschlange genannt.
Eine Prioritätswarteschlange ist sowohl ein Heap als auch ein Stack, da man Elemente vom Anfang als auch vom Ende entnehmen kann.
siehe auch Buch "Algorithmen" von Robert Sedgewick, ISBN: 3893193014
Ich hatte dies schon eingearbeitet, das wurde aber von Benutzer:Coma gelöscht. -- Shmia 11:42, 11. Okt 2005 (CEST)
replies: text: Eine Prioritätswarteschlange ist etwas anderes als eine Warteschlange. Was eine zweiendige Warteschlange sein soll, erschließt sich mir nicht, zumindes nicht, wofür das gut sein soll. Was dass dann noch mit einem Stapelspeicher zu tun hat erst recht nicht. Eine Prioritäswarteschlange ist auch garantiert kein Stack. Elemente vom Anfang und vom Ende entnehmen zu können zeichnet weder einen Stack noch einen Heap (bzw. eine Prioritätswarteschlange) aus. Was in dem Buch steht, weiß ich nicht. Es ist entweder falsch, der Autor arbeitet mit anderen und insbesondere unüblichen Bezeichnungen oder du hast das Buch falsch verstanden. --Coma 15:19, 11. Okt 2005 (CEST)
replies: text: Vielleicht sollte man es so formulieren - eine Deque ist eine allgemeinere Datenstruktur, die gleichzeitig als Stapelspeicher, als auch eine Warteschlange benutzt werden kann. Ich glaube soweit sind wir uns einig. Eine Prioritätswarteschlange kann nun ebenfalls zu einem Stapelspeicher werden, wenn die gepushten Dinge alle die gleiche Priorität haben. Ich denke, dies sollten wir eher weglassen. -- Shmia 17:31, 11. Okt 2005 (CEST)
thread_title:  Prioritätswarteschlange 

message: Im Review kam nicht mehr viel, ich gehe also mal davon aus, dass er soweit schon ganz gut ist. Hab zwar selbst viel zu beigetragen, aber da das schon lange her ist, stimme ich trotzdem mal mit ab. --Koethnig 13:12, 18. Jan 2006 (CET)
replies: text:  Hmm, was hat das mit der Wahl zu tun? Die Existenz eines anderen mögl. schlechteren Artikels kann ja nicht Einfluss auf diesen Artikel hier haben? Das eine ist eine Datenstruktur, das andere ein Prinzip. Die Datenstruktur arbeitet mehr oder weniger zufällig nach dem Prinzip. Was willst du da sauber trennen? Wenn man über das Prinzip spricht, verlinkt man dorthin, wenn man über die Datenstruktur spricht, verlinkt man zur Datenstruktur! --Koethnig 22:47, 18. Jan 2006 (CET)
thread_title:  Lesenswert-Diskussion Januar 06 (abgelehnt) 

message: Wie kommt es zur Formulierung "Ein entsprechender First In – First Out-Speicher nennt sich Warteschlange." unter "Verwandte Themen"? Der Verweis auf Warteschlange zum Thema Datenstrukturen ist nicht falsch, aber zum Stack "entsprechend" bedeutet LIFO (Last in - First Out) und nicht FIFO!
Wenn keine Einsprüche kommen mache ich eine Korrektur.--Wiki und ylvie 02:18, 31. Dez. 2006 (CET)
thread_title:  Verwandte Themen 

message: Ich denke die Symbolik/Metapher "Keller"-speicher sollte in diesem Artikel ebenfalls kurz geklärt werden. Die meisten die davon zum ersten Mal hören werden wohl eher denken: "So ein Schmarrn, was hat denn ein Keller mit Informatik zu tun?"
Ich stelle mir das so vor, dass mit Keller zur Begriffsentstehungszeit sinnbildlich ein Kohlenkeller gemeint war, auf den man jedes Jahr die Kohlenlieferung schüttet und dann übers Jahr von oben die Kohlen absammelt zum verfeuern. Die untersten Kohlen sind also die ältesten und nicht zu sehen und können erst zuletzt verwendet werden (LIFO). Im Gegensatz zum Begriff Stapelspeicher ist eben beim Kellerspeicher nur das Oberste zu sehen, die anderen Elemente sind verdeckt. Da heute kaum noch jemand selbst mit Briketts Kachelöfen befeuert ist IMHO die Symbolkraft des Wortes Kellerspeichers geschwunden und stiftet eher Verwirrung.
Gast Peter (Der vorstehende, nicht signierte Beitrag – siehe dazu Hilfe:Signatur – stammt von 88.73.247.210 (Diskussion • Beiträge) 12:54, 27. Feb. 2007 (CET)
thread_title:  Name Kellerspeicher 

message: Ich finde die Begriffe Top of Stack(TOS) und Bottom of Stack(BOS) sehr wichtig und würde vorschlagen die in das Bild ein zu bauen. --Reuti 19:30, 5. Aug. 2008 (CEST)
replies: text: Ehrlich gesagt: noch nie gehört. --PeterFrankfurt 02:29, 6. Aug. 2008 (CEST)
replies: text:  sehr sehr komisch, wie nennst du den Anfang und das Ende des Stacks ? --Reuti 15:04, 11. Aug. 2008 (CEST)
replies: text: Einfach Top und Bottom, ohne das "of Stack" dabei und ohne diese Abkürzungen, wobei vor allem TOS ja nun seit den 80ern für was ganz anderes steht. (Stacks gab's schon vorher, weiß ich.) --PeterFrankfurt 01:18, 12. Aug. 2008 (CEST)
replies: text:  Soweit ich weiß wird in vielen hardwarenahen Programmiersprachen dieser Begriff verwendet und auch benutzt. Beispiele Google Suche von TOS BOS (Der vorstehende, nicht signierte Beitrag – siehe dazu Hilfe:Signatur – stammt von Reuti (Diskussion • Beiträge) 13:34, 12. Aug. 2008 (CEST)

text:  Also ich habe nun wirklich viele Jahre lang in purem Assembler kommerziell programmiert (65xxx und Z80, lesenderweise beim C(++)-Debuggen noch ein paar weitere), aber diese Abkürzungen sind mir da nie über den Weg gelaufen. --PeterFrankfurt 00:27, 13. Aug. 2008 (CEST)
replies: text:  Sehr Sehr komisch, als Student bekommt man sowas in den Kopf gehackt und dann nichts :) Naja dann lassen wir die Diskussion fallen, denn Redicts bestehen ja von TOS und BOS zu Stapelspeicher. --Reuti 11:02, 13. Aug. 2008 (CEST)
replies: text:  Das wird hierbei mit den Unis so wie mit den Schweizer Kantonen sein: Das ist von Uni zu Uni verschieden... --PeterFrankfurt 22:27, 13. Aug. 2008 (CEST)
thread_title:  Anfang und Ende 

message: Zitat: Der Stapel wächst "nach unten", in Richtung niedrigerer Speicheradressen. Dies ist historisch begründet: Legt man bei begrenztem Speicher den Stack an die höchstmögliche Adresse, minimiert man die Wahrscheinlichkeit, dass andere Programmdaten (die z. B. hinter dem Programm abgelegt werden) mit dem Stapel kollidieren.
Dieses historisches Phänomen ist zwar nicht falsch, erscheint mir aber in Hinsicht auf die ursächliche Laufrichtung des Stacks als barer Unsinn. Der Grund findet sich m.E. in der bei 8-Bit und 16-Bit Prozessoren weithin üblichen Basis-Index-Addressierung, und auch die heute übliche Intel-x86 Architektur kennt modrm-Befehle, bei der für einen Lade-/Speicherbefehl die Register SP,BP,etc als Basisregister mit einem (im Maschinencode eingeschriebenen) Offset verrechnet werden. Offsets, hier eben bei Callframes, werden in der Regel positiv angegeben, man greift also vom Basisregister in Richtung höherer Adressen zu. Daher ist es sinnvoll, neue Callframes an niederen Adressen starten zu lassen und direkt über den TOS-Zeiger mit hardcodierten positiven Indexwerten zu gehen. GuidoD 13:39, 4. Okt. 2008 (CEST)
replies: text: Also ich weiß ja nicht, ob das so viel miteinander zu tun hat. Einen ganzen Frame aufmachen tut man ja (in alter Zeit, vor der Einführung dafür optimierter Befehle) durch ein Addieren bzw. Subtrahieren des Stackpointerregisters statt durch wiederholtes Pushen. Wenn man so rechnet, sind beide Richtungen eher gleichberechtigt. Und bei reiner Assemblerprogrammierung, wie sie in der Einführungszeit der Mikroprozessoren noch viel verbreiteter war, hat man sich wenig um Callframes geschert, sondern einzelne Variablen bzw. Register auf den Stack geschoben. --PeterFrankfurt 00:24, 5. Okt. 2008 (CEST)
replies: text:  Nicht Callframe-Creation sondern Callframe-Usage - der Callee kann Variablen via SP addressieren. GuidoD 06:00, 5. Okt. 2008 (CEST)
replies: text:  Ja, aber dazu muss der Frame erstmal da sein, sprich der SP um die Frame-Größe versetzt werden. Und dafür hatten ältere Prozessoren einfach keine eigenen Befehle, man musste entweder viele Pushs von Hand machen oder den SP in den Akku übertragen, dort rechnen und wieder zurück damit, Aufwand, den man nicht so gern trieb. Ich rede hier ja von direkter Assemblerprogrammierung, wie sie damals herrschte, und nicht von Compilerbauern. Man muss sich vor Augen führen, was es zur Einführungszeit der Mikroprozessoren für ein Umfeld gab: gar keins! Es gab neben Assemblern ein, zwei Basic-Interpreter und ein paar grandios scheiternde Hochsprachencompilerversuche (UCSD-Pascal irgendwer? Aua), und Anwendungssoftware hat sich in meinem Bekanntenkreis an der Uni damals ziemlich genau jeder zweite User von Null an selber programmiert. Callframes waren da noch gar nicht am Horizont zu sehen, bei Mikroprozessoren. Bitte also nicht die Technik, die sich erst später entwickelt hat, als allgemeingültig für alle Mikroprozessoren (auch die früheren) hinstellen. --PeterFrankfurt 01:17, 6. Okt. 2008 (CEST)
thread_title:  Laufrichtung 

message: Von HP hatte ich mal einen Artikel, der zu dem Thema behauptete, daß ein Stack mit 4 Einträgen für jedes Problem in Postfixnotation ausreichend wäre. Hat da noch jemand die Quelle? Es ging damals um den HP41, der 4 Einträge in seinen Stack aufnehmen kann. --Harald Wehner 23:10, 28. Dez. 2008 (CET)
replies: text: mathematisch gesehen ist diese Behauptung Unsinn, es ist ganz leicht, Gegenbeispiele zu konstruieren.  HP hat möglicherweise etwas ähnliches gesagt, dann aber eher so in der Richtung "in der Praxis tauchen keine Probleme auf, die mit einem Stapel der Tiefe 4 nicht lösbar wären". Da wiederum gebe ich denen recht. --Herbert Klaeren 23:17, 28. Dez. 2008 (CET)
replies: text: Klar, bei zu großer Komplexität muss man dann zurückgreifen auf Zwischenspeicherung von Hand in Variablen bzw. separate Speicherzellen, das geht alles, aber mit größerem Stack ginge es eleganter und schneller. --PeterFrankfurt 01:03, 29. Dez. 2008 (CET)
replies: text: Wenn ich mich recht erinnere (das war vor über 20 Jahren!) ging es nur um die "normalen" arithmetischen Funktionen (auch sowas wie Funktionen, die auf einen Operanden angewendet werden, wie Sinus() und so weiter) und warum HP keine Klammern braucht. Damals waren bei den Taschenrechnern ja 10 oder 20 Klammerebenen en vogue. Ein Problem muß also so umformuliert werden, daß man es mittels 4-Ebenen-Stack lösen kann. Und die Behauptung war eben: Das geht immer - soweit ich mich erinnere. (Wie gesagt, über 20 Jahre...) --Harald Wehner 08:21, 29. Dez. 2008 (CET)
replies: text: Also das kann ich mir nicht vorstellen, dass das immer gehen soll. Rein von der Logik her: Wenn mehr als drei (zwei Operanden, einer im Sinn), nämlich vier, Stackelemente gebraucht werden, dann gibt es bestimmt auch Fälle, wo man noch mehr braucht. Ich kann jetzt kein Gegenbeispiel aus dem Ärmel schütteln (Freiwillige, irgendwer?), aber das sieht nach einer sehr mutigen Behauptung aus, wobei man auch vorsichtig sein muss, ob HP selbst das überhaupt so behauptet hat. Ich habe übrigens nichts gegen HP, habe für meinen HP 25 (noch nix 25C) damals noch ungeheuer teure 548 DM bezahlt! --PeterFrankfurt 00:46, 30. Dez. 2008 (CET)
thread_title:  Postfixnotation 

message: Ich denke, dass wir unbedingt eine deutsche Entsprechung zu en:Call stack brauchen, da dieser ein sehr wichtiges Werkzeug beim Abhandeln von Unterprogrammen ist. Viele Artikel, wie z. Bsp. Dynamischer Speicher verweisen auf diesen Artikel, obwohl dort nicht die Datenstruktur, sondern der Aufrufstapel im Hauptspeicher gemeint ist. --Kockster 15:35, 9. Jul. 2008 (CEST)
replies: text: Stimme dem voll und ganz zu. Ich bin eigentlich auf der Suche nach dem Call Stack bei diesem Artikel hier gelandet. Und in der Einleitung steht, dass der Stack von der Hardware unterstützt wird... das bezieht sich doch auf den Call Stack oder etwa nicht? Wenn ich mir meinen eigenen Stack programmiere, dann hat der doch keine Hardware-Unterstützung. Es sieht also für mich so aus, als sei dieser Artikel zumindest irgendwann mal in der Absicht verfasst worden, den Call Stack und nicht die Datenstruktur zu beschreiben. --GGShinobi (Diskussion) 22:52, 3. Jul. 2012 (CEST)
replies: text: der call stack heisst auf deutsch Laufzeitstapel, und natürlich kannst du, wenn du Assembler programmierst, auch den Hardwarestack für eigene Zwecke verwenden, solange du keine Unterprogrammsprünge verwendest. Für die höheren Programmiersprachen ist der Hardwarestack natürlich unsichtbar, weil die ihn wirklich für die Implementierung eines Laufzeitkellers brauchen.  Stapelspeicher ist aber ein ganz allgemeines Prinzip und übrigens praktisch die einzige Datenstruktur, die im Prinzip durch ein deutsches Bundespatent aus dem Jahr 1959 geschützt ist. --Herbert Klaeren (Diskussion) 23:12, 3. Jul. 2012 (CEST)
thread_title:  Aufrufstapel (Call Stack) 

message: Vorsicht Freunde, die Seite hat Schräglage!
Der Stack ist eine der ältesten Errungenschaften der Mikroprozessorei. Es handelt sich um Hardware. Er diente und dient noch immer dazu, den Programmzähler (PC, programm counter) bei Unterprogramm-Aufrufen zu stellen. Da man i.a. nur ein RAM zur Verfügung hat, man aber neben den Adressen angesprungener UPs auch Daten speichern will, schreibt man die Daten im Adressbereich von unten nach oben (hintereinander), den Stack hingegen von oben nach unten (rückwärts beginnend beim RAM-Ende RAMEND). 
Dazu ermittelt man im ersten Schritt jedes Programms die Größe des RAM und setzt den Stapelzähler (stack pointer - SP) darauf. Der Rest passiert automatisch beim Aufruf von Unterprogrammen. Der Stack Pointer wird beim Einstieg (RCALL irgendwas) in ein Unterprogramm (Hardware) erniedrigt, beim Ausstieg mit RET oder RETI wird er wieder erhöht. Das geht vollautomatisch, i.a. ohne daß der Programmierer darauf Einfluß nimmt. 
; STACK initialisieren am Beispiel ATMEL ATmega8
:ldi r16, LOW(RAMEND)      ; LOW-Byte der obersten RAM-Adresse
:out SPL, r16              ; Setze SP low-Teil
:ldi r16, HIGH(RAMEND)     ; HIGH-Byte der obersten RAM-Adresse
:out SPH, r16              ; Setze SP high-Teil
RAMEND ist in einem prozessorspezifischen File vereinbart (Assembler: m8def.inc oder C-Header iom8.h) z.B. als
:.equ	RAMEND		= 0x045f	; start of stack pointer (läuft rückwärts)
Gäbe es keinen Stack, so gäbe es in Assembler nur RJMP und kein automatisches RETURN nach einem RCALL. Der Stack merkt sich also die Rücksprungadresse aus einem Unterprogramm.
-- Heinzelmann 15:09, 1. Apr. 2009 (CEST)
replies: text: Hmm, das ist jetzt Atmel, ähnlich wie bei x86 oder 8080 oder so. Z. B. für meinen geliebten 6502 stimmt das alles überhaupt nicht, da dessen Stack auf die Page 1 fixiert ist (aber auch von oben nach unten wächst). Also sind Deine Ausführungen schon mal nicht allgemeingültig. Und der Stack an sich ist auch keine Errungenschaft der Mikroprozessoren, den gab es auch schon vorher bei den diskreteren Computerhardware-Varianten. Und unter den Mikroprozessoren gibt es mindestens einen, den SC/MP, der hat überhaupt keinen Subroutine-Call, das mussten Programmierer sich aufwendig zu Fuß basteln (kenne ich aber nur vom Hörensagen). Wie gesagt, wir müssen hier allgemeingültig bleiben und uns deshalb auf den kleinsten gemeinsamen Nenner beschränken. --PeterFrankfurt 01:22, 2. Apr. 2009 (CEST)
replies: text: PeterFrankfurt hat völlig recht, die Ausführungen von Heinzelmann sind sehr spezifisch auf eine bestimmte Prozessorfamilie bezogen.  Und der Stack ist zwar bei modernen Mikroprozessorarchitekturen normal, aber das Konzept ist viel älter. Das steht auch ausdrücklich im Artikel. --Herbert Klaeren 08:57, 2. Apr. 2009 (CEST)
thread_title:  Schieflage 

message: Wie denn? Erschließt sich mir nicht. --213.221.250.85 16:43, 7. Dez. 2010 (CET)
replies: text: Der Satz kommt mir auch ziemlich schräg formuliert vor. Was gemeint ist, ist die Überprüfung von Klammerstrukturen, dass also zu jeder "Klammer auf" eine entsprechende "Klammer zu" gehört. Das kann man natürlich auch mit einem Stapelspeicher überprüfen: bei "Klammer auf" push, bei "Klammer zu" pop - im Fall von XML nur dann, wenn es das richtige "closing tag" ist.  Dann muss hinterher der Stapel leer sein... --Herbert Klaeren 19:43, 7. Dez. 2010 (CET)
thread_title:  "Mithilfe des Stapelspeichers lassen sich einfach Terme oder Syntaxen auf richtige Verschachtelung prüfen, so wie es oft im Internet bei BB-Codes oder XML-Dokumenten der Fall ist." 

message: Die angegebene Implementierung ist sinnlos. Ein Stack, der durch ein Array implementiert ist, könnte direkt durch ein Array ersetzt werden. Man sollte ein Beispiel eines richtigen Stacks mit Zeigern einbauen. -- Mfnalex 19:29, 10. Jan. 2012 (CET)
replies: text: Ich habe die Implementierung durch einen Stack der mit Zeigern arbeitet ersetzt. --PrototypePHX (Diskussion) 17:37, 30. Jun. 2012 (CEST)
replies: text: ja, aber das ist hier trotzdem kontraproduktiv. Der Witz beim Stack ist ja gerade der, dass er sich extrem leicht verwalten lässt, man braucht im Prinzip nur einen Index in einem Array zu verwalten.  Alle eingebauten Hardware-Stacks (z.B. beim Intel) arbeiten genau so. Die Version mit den verzeigerten Listen ist größenordnungsmäßig komplizierter.  Was Mfnalex hier als „richtigen Stack mit Zeigern“ bezeichnet, ist gar kein Stack, sondern - spätestens in deiner Implementierung - eine verzeigerte Liste. --Herbert Klaeren (Diskussion) 19:16, 30. Jun. 2012 (CEST)
replies: text: Stimmt, ist mir beim Programmieren dann auch aufgefallen, habe mir aber nichts weiter dabei gedacht. Kopierkonstruktor und Zuweisungsoperator sind deswegen ja auch nicht besonders hübsch ... --PrototypePHX (Diskussion) 20:39, 30. Jun. 2012 (CEST)
thread_title:  Implementierung 

message: Im Text steht: "Der Stapel wächst also nach unten." heißt das, Richtung kleinere Speicheradressen? - "Der Stapel wächst also nach unten, in Richtung der kleineren Speicheradressen." könnte man doch dann schreiben. --Ost38 11:31, 23. Feb. 2008 (CET)
thread_title:  Richtung 

message: So, wie der Abschnitt vorher war, hat er Compile-Zeit und Laufzeit vermischt. Ich habe den Laufzeit-Teil nach oben verschoben. Außerdem war die Darstellung des Parsing-Prozesses falsch. Ich habe sie darum entsorgt und statt dessen auf Kellerautomat verlinkt. Wäre es evtl. besser, auf entsprechende Parsing-Algorithmen zu verlinken? -- UKoch 18:55, 21. Nov. 2011 (CET)
thread_title:  Abschnitt "Compiler" 

message: Ich habe soeben einen vermeintlichen Tippo („Samuelson“ statt richtig „Samelson“) korrigiert, allerdings in einem Zitat:
Fußnote 1 zu ISBN 3-540-11722-9, S. 222.
Es besteht also leider die Möglichkeit, daß das Zitat selber den Tippo enthielt.
In dem Fall sollte der Fehler stehen bleiben.
Es wäre schön, wenn jemand in ISBN 3-540-11722-9, S. 222 nachsehen könnte, ich habe keinen Zugriff darauf.
--H.Marxen (Diskussion) 13:54, 27. Aug. 2013 (CEST)
thread_title:  Tippo im Zitat