Noch einmal Raspberry Pi

...

Eben. Die Unterschiede zwischen Bankswitching, Segmentierung und Paging sind subtil und außer für Betriebssystemprogrammierer (die hier wohl ohnehin nicht mitlesen) weitgehend irrelevant.

Typischerweise klebt man heute noch ein wenig Magie an das Bank- switching-Register und nennt es dann MMU. Fertig die Laube.

XL

Konnte auch der 6502.... (um ihn nicht zu vergessen)

SINCLAIR, off course. What else ;-)

Nja. Das alte AMIGA OS1.3 (Betriebssystem), speziell das 2.0, wurde in

Das konnten auch die 386SX Prozessoren.... (16/32), obwohl der 68000 da schon den 8088 und Anfänge des 8086 als Mitstreiter gesehen hat ;-) Der echte 386er war da noch in der Ferne bzw. unbezahlbar zu der Zeit.

Kann mich an 4-5000DM 386DX (16-25MHz) Rechner erinnern (die SX kamen etwas später...) Die 32/32 Varianten von Motorola waren (zu der Zeit) aber auch nicht viel billiger, wohlgemerkt.

Spätestens mit NT4.0 kam alles anders....

RISC wurde mit dem P6 (RISC-Kern) assimiliert. Den Rest an Spaghetti-Software, außer 68k Profi-Arbeit ;-), sehen wir Tag für Tag. Und es wird immer langsamer, obwohl die Rechner immer schneller werden.

Am 15 Apr 2013 19:37:01 GMT schrieb "Daniel Mandic" :

Besser mit einem "f". Der Unteschied zwischen "selbstverständlich" und "neben der Spur" ist evident.

Marc

Gerrit Heitsch :

Was ist eine extern sichtbare Adresse? Wenn man sich um so etwas nicht kümmern muss, beginnt man ein Code-Fragment brav an einer 16-er-Grenze und hat dann 64kB relativ zum Segment, mit dem dann letztlich adressiert wird. Dasselbe für das nächste Code-Fragment. Wer Bandwürmer größer 64 kB an einem Stück generiert, dem gehört sowieso eins auf die Finger - in der Architektur, einen Abstraktionslevel oberhalb, sieht man so nicht die Code- sondern nur die Segment-Adresse. Wer die augenblickliche absolute Adresse wissen will, der rechnet sie explizit aus, mit Segment*16+Register. Das ist eine ausnehmend schnelle Rechnung.

Diese Art des Zugriffs setzt wahrscheinlich voraus, dass man alle Compiler vorher auf den Mond geschossen hat, die als Betriebsbedingung haben, dass man vor Gebrauch das Hirn ausschaltet. Ich hatte garkeinen externen solchen, als da selbst das vorgehende Bootstrap-Forth von einem 16- auf ein derartiges 32-Bit-Modell in der Datenbehandlung, plus beschriebener Adressbehandlung als 16-Bit-Code, crosscompiliert hat. Bekanntlich ist Forth sein eigener Compiler, und wenn man das Ding passend dressiert, macht's es das auch. Ein kleiner Assembler ist sowieso Teil von Compiler und Crosscompiler ("Metacompiler").

Sprüche von so etwas wie externer Sichtbarkeit versteh ich von daher nicht. Das ist redundanter Privatquack, wenn es nur vom Compiler auferlegt wird, mit der Arbeitsweise des Geräts nicht begründet ist.

Wenn es darum geht, dass es für eine Adresse viele mögliche Varianten gibt, um sie darzustellen, muss man eben bei entsprechendem Bedarf den Akt einer Normalisierung zwischenschalten. Das ist je keine Hexerei.

Intel x86 - das war nie aus einem Guss, mit erkennbarem Anfang und Ende des Designs, das ist eher ein nach und nach zusammengenagelter, windschiefer Palast, sozusagen, mit ein paar wenigen zweckbezogenen Registern als Ausgangslage.

Eigentlich kann man in 64 kB ja leidlich umfassende Programmerln schreiben, wenn man weglässt, was an aufgeblähtem Firlefanz sonst herumgeschleppt wird. Damals hat man beim Design vielleicht noch daran geglaubt, der Gebrauch des Verstands sei ausbaufähig. Nachher hat es stattdessen gereicht, Rechenzeit zu verschwenden.

Konnte ja niemand voraussehen, dass hernach Verstandesgebrauch zum sparsam einzusetzenden Luxus wird und Rechnerkapazität aus vollen Kübeln geschöpft wird, statt andersherum.

Ja, schon. Das liegt wohl auch daran, dass man begleitet von dem Eindruck hantieren kann, die Möglichkeiten seien immer schön geordnet alle vor einem ausgebreitet. Das beflügelt die Phantasie.

Ich hatte seinerzeit parallel auf der einen wie der anderen CPU ein Forth gepflegt und ausgebaut (stabil ab 1992), parallel zur Debatte um einen neuen Forth-Standard (dann als ANS-Forth 1994, als ISO-Forth 1998), und war mir eigentlich nie sicher, welche CPU ich denn nun bevorzugen würde. Gut, wenn man das dann auf dem 8051er zum Laufen bringt, schaut man, dann man dem nicht so genau auf die Assembler-Beine schauen muss.. Verglichen mit anderen Fragen war das aber eher nebensächlich - so muss man sich bei Forth ständig mit einem "Me too!"-Geschmäckle herumärgern, wenn immer wieder eifrige Kollegen "richtig großer Systemfuzzi" spielen wollen, zurück bleibt dann eine Wiese voller Rohrkrepierer und keiner hat je etwas daraus gemacht. Aus praktischen Erwägungen war ich dem enthoben - Systembastlerei für das Arbeitsgerät nahm etwa bis 40 Prozent, der Rest waren Applikationen (vor allem beruflich), mit den je aktuellen Versionen geschrieben. Und so, wie die Applikationen sich bewährten, konnte man auch sehen, wie das zugrundeliegende Arbeitsgerät rund und robust läuft (z.T. nach wie vor). Aber auf Dauer, also wenn man nach Jahrzehnten rechnet, ist das irgendwann ermüdend, immer und immer wieder doch nur von "me too!"s zu hören, "aber ich!" praktisch nie davon, dass man sich über etwas umfangreichere Applikationen austauschen könnte. (Es lassen sich einige Erfolgsgeschichten nachschauen, was sich dann gern hinter Nebelwänden von NDAs abspielt, aber diesseits von jenen bröckelt es doch recht krass ab).

Gut, letztlich durfte ich mich in der Rolle fühlen, als ob da ein schön dicker System-ISO-Standard (zu einer Token-Maschine) quasi alleine für mich geschrieben worden wäre, nun ja, möchte man da fragen, vielleicht ist Zen eine Brille, wenn aus dem eigentlich auch nichts anderes wurde, als nur, dass ich damit eine etwas dickere Applikation schrieb. Oder so ähnlich (dem Stand meiner Information entsprechend; keinesfalls möchte ich die Arbeit von mitwirkenden Kollegen damit geringschätzen).

Dann wundert einen im Rückblick (das ist nun auch schon wieder etwas her) eher, warum man denn nun Intel- oder Motorola-Diktion bevorzugen soll, wo es hernach doch eher Anlass für ein Lächeln ist, wenn es beides gibt, als da ja beide ganz witzig sind, und sieht es als Bereicherung, wenn hernach sich viel konstruktiver Eifer um die Bändigung der Erfindungen der AVR- und ARM-Architekturen entfaltet.

Um so ganz vorsichtig wieder in die Kurve zum obigen Betreff einzubiegen.

So ein Schwachsinn. Mich hat noch nie in linuxlastingen Gruppen und Mailinglisten jemand auch nur ansatzweise beleidigt. Irgendwas machst Du falsch.

-ras

und

Nanu, noch nie dem Schil* begegnet? Oder hatte der nur 'nen schlechten Tag? ;)

Guido

Wie lautet die Volksweisheit doch so treffend:

"Wie man in den Wald hineinruft, so schallt es heraus"

Dazu fällt mir ein: Capitalization is the difference between "I helped your uncle Jack off a horse" and "I helped your uncle jack off a horse" :-)

Viele Grüße, Johannes

Am 15.04.2013 21:37, schrieb Daniel Mandic:

Ich erinnere mich an die erste 286/12-er Prozessorkarte die kurz nach mir im Ingenieurbüro Einzug hielt. Original Intel *iSBC 286/12 CPU board, etwa DM

Bernd

Wohl ungekehrt. Der SX hatte keine FPU, der DX schon. Für den SX konnte man die damals dann noch nachbestücken. Habe sogar ein Handbuch für den Nachrüst-Coprozessor von damals noch aufgehoben.

Gruß, Johannes

Am 15.04.2013 20:20, schrieb Gerrit Heitsch:

besteht

Richtig.

Das war für damalige Verhältnisse eigentlich sogar ziemlich genial, denn damit konnte man sehr schnelle Taskwechsel machen. Und man musste nicht für jedes Segment immer die vollen 64k nutzen, sondern konnte wegen der Verschiebung eben beliebige Segmente fast beliebig im Speicher positionieren. iRMX86 war da ein sehr brauchbares RTOS. Habe ich viel mit programmiert, inklusive Devicetreiber für Multiprozessorsysteme. Später dann mit iRMX286 im protected mode.

Bernd

Am 16.04.2013 10:43, schrieb Johannes Bauer:

Nein, es gab zunächst nur die DX, später dann auch die abgespeckte Sparvariante.

Bernd

Er tut/tat dasselbe wie hier: er kam rein, pöbelte erstmal rum und "wunderte" sich dann über das Echo...

Thomas

Gerrit Heitsch schrieb:

Ich könnte mir vorstellen, dass der Hintergedanke dabei ein schneller Taskwechsel war: Register auf den Stack, Segmentregister umschalten - fertig. So lange jede Task mit je 64 kB für Code uns Stack und 2 * 64 kB für Daten auskommt, eine feine Sache. Immerhin bot der 8085 (bzw. Z80) ja nur 64kB für alles zusammen.

Der erste WordStar für den 8086/8088 hatte noch die alte Programmstruktur mit Overlays ...

Ade

Reinhard

Bernd Laengerich schrieb:

nte

Würde der werte Herr Bauer aber auch nur einmal ein Datenblatt lesen, würde ihm auffallen, daß der 80386DX keinen Fließkommaprozessor eingebaut hat, sondern als Coprozessor den 80387 benötigt. Desgleichen

der 80286. Auch der hätte gerne den 80387 als Coprozessor.

Lustig finde ich, daß über diese Bauelemente in Vergangenheitsform geredet wird. Nun, ich habe hier noch funktionierende Exemplare.

Holger

Johannes Bauer schrieb:

Nein, war schon richtig rum. Intel hat etwas Zeit gebraucht um draufzukommen, dass man 386er mit defekter FPU nicht gleich wegschmeißen muss ...

Ade

Reinhard

Ah, okay. Wieder was dazugelernt!

Viele Grüße, Johannes

Am 16.04.2013 11:27, schrieb Reinhard Forster:

Die 386 haben keine FPU, dafür ist der 387 zuständig. Und das mit der defekten FPU beim 486SX halte ich (unabhängig davon, was in Wikipedia steht) für eine UL.

leider was falsches gelernt....