Mich würde mal interessieren wie so der interne Datenspeicher beim Rechnen ausschaut. Also ganz platt mal ne Hartkopie vom "Speicher" während des Rechenvorgangs.
Ist das alles nur CODE oder wie ich mir auch vorstellen könnte aufgrund der "älteren" Programmierung "relativer Klartext". Welche Umfänge nimmt das an. Wie oft z.B. wird eine DIA A4 Seite voll neu berechnet mit Code ...

Welchen Speicher, und vieviel ist das in DIN A4 Seiten, hat z.B. mein 8bit Polgar (um mal nen langsameren zu nehmen) ?

64KB = 33.000 Seiten Die macht sich auch mein 8biter ständig voll ?
Das da viel hin und her geschoben wird ist mir klar - aber das das schon mit dem kleinen diesen Umfang hat ...

Ist bestimmt auch vom Modus, sprich gegönnte Rechenzeit abhängig - also mehr als 5sec/10sec kriegt meiner nicht - damit ich noch ne Chance habe

Stell ich mir das so richtig vor :
Brute force alles durchrechnen was mit dem 1. Halbzug geht.
Intern listen und weiter mit dem 2. und 3. Halbzug und dann später auf Basis dieser "Listen" selectiv weiterrechnen ?

Kommt der überhaupt rechenleistungstechnisch darüberhinaus in der wenigen Rechenzeit ?

Von dem Umfang was da alles an Daten bewegt wird macht man sich gar keine Gedanken - daher auch dieser Trööt ...
Das ist ja schon interessant mal einzusteigen wie das so funzt - gibts da nen Link zum Thema ?

Hallo Stefan,


Ich bin kein Programmierer, deshalb sind das alles eher Spekulationen als Tatsachen, was ich jetzt von mir gebe!

Gerade die ältere Programmierung dürfte mehr auf Asssembler (Maschinensprache ohne jeglichen Klartext) basieren, da der Speicherplatz damals deutlich beschränkter war als heute und Assembler deutlich weniger Platz braucht als eine in Klartext lesbare Programmiersprache. Und vor allen Dingen ist Assembler in der Ausführung um ein Mehrfaches schneller!

Sein ROM hat 64 KB; eine Schreibmaschinen Din A4 Seite hat ca. 2000 Bytes, das ergibt in etwa 33000 Seiten.

Heutzutage hat ja jeder Büro-PC Platz und Speed im Überfluss, da braucht man nicht mehr platzsparend und geschwindigkeitsoptimiert programmieren...

Wenn ich zurückdenke, was man z. B. aus den <64KB eines Commodore 64 mit Programmiertricks alles herausgeholt hat; da könnten sich die Programmierer von heute viele Scheiben abschneiden...


viele Grüße,
Robert

Hallo Robert,
mir geht es genau so wie Dir. Ich habe ein Buch hier vorliegen und das gibt folgendes dazu an:
Man rechnet mit 75 Anschläge pro Zeile, 40 Zeilen pro Seite.
ein ASCII-Zeichen kann mit 1Byte gespeichert werden (ein Farbpixel verbraucht 3Byte, Rot-Grün-Blau-Anteil)
1 Seite =75x 40=3000 Zeichen
Daraus berechne ich :22000 Seiten.
Ich weis aber nicht, ob meine Rechnung stimmt.

Paul

Hallo Paul und Robert,

so langsam zweifle ich an meinen Rechenkünsten...
Dein Beispiel hat mit Robert's eines gemein - ich verstehe es nicht!
Wenn eine Seite (wie Robert beschrieb) ca. 2000 Byte hätte und ich mal der Einfachheit halber auf 2048 Byte "aufrunde", so sind das doch bereits 2 KB, oder etwa nicht? 64 KB / 2 KB (Seite) = 32 Seiten! Bei deinen 3000 Zeichen (= 3000 Byte) wären es dann so gesehen rund 21 bis 22 Seiten - und aus! Wo kommen denn bei Euch die vielen Nullen her?
Liege ICH hier falsch oder was geht ab? Muss mich sonst wohl mal einem umfassenden Systemcheck unterziehen...??

Gruß, Willi

Lieber Willi,
es sind 22 Seiten. Bitte kein Systemcheck durchführen. Ich habe im Kopf 10 hoch 3 und 10 hoch 6 vertauscht.

Paul

Hallo Paul und Robert,

so langsam zweifle ich an meinen Rechenkünsten...
Dein Beispiel hat mit Robert's eines gemein - ich verstehe es nicht!
Wenn eine Seite (wie Robert beschrieb) ca. 2000 Byte hätte und ich mal der Einfachheit halber auf 2048 Byte "aufrunde", so sind das doch bereits 2 KB, oder etwa nicht? 64 KB / 2 KB (Seite) = 32 Seiten! Bei deinen 3000 Zeichen (= 3000 Byte) wären es dann so gesehen rund 21 bis 22 Seiten - und aus! Wo kommen denn bei Euch die vielen Nullen her?