Source aus Programm wiederherstellen

[Fuerchau]

Wenn denn der Speicher das einzige Problem wäre.
Der einstufige Speicher ist eine unterstützung des Micro-Codes, liegt also quasi unterhalb des OS.

Verwende ich ein 32-Bit-Programm, kann ich eben max. 2^32 Bytes adressieren, nehme ich 64-Bit eben 2^64.

Dass ich den Speicher auch erhalte wird eben z.B. durch C-Funktionen wie malloc() realisiert.
In Windows-C wird durch malloc() eben die Windows-Implementation GlobalAlloc() aufgerufen, die mir dann den virtuellen Speicher zur Verfügung stellt (oder, wenn die Pagefile zu klein ist, eben einen Fehler auslöst).

In der AS/400 ist eben jede Adresse (Pointer) auf 128-Bit ausgerichtet und deshalb kann das MI-Äquivalent des malloc() mir virtuellen Speicher (egal wo dieser liegt) liefern.

Was du also machen kannst, ist eben per AS/400-C-Compiler einen Linux-Kernel zu erstellen, wobei du alle "Hardware"-spezifischen Funktionen durch eigene Treiber noch entwickeln musst.

[BenderD]

heißt doch nur, dass ein 32 bit Kernel von Linux die Speicher Variablen in 32 bit anlegt und ein 64 bit Kernel das in 64 bit tun muss.
Wenn ein Linux auf OS400 draufhockt, dann liegt zwischen Hardware und dem Linux Kernel noch der MI Kernel (das ist nicht dasselbe, wie MI!!!) und der Speicher in dem dieses Linux zu arbeiten glaubt ist virtual storage von OS400 (mit der Konsequenz, dass alle Hardware Treiber gefummelt werden müssen).
Hockt das Linux auf einer i direkt auf p (was wohl kaum wirkungsvoll abgeklemmt ist, weil das eh keiner tut - warum soll ich den MI Kernel für sehr viel Geld mitkaufen, wenn ich ihn n i c h t haben will), dann greift er direkt auf die Hardware (genauer gesagt, auf die dafür vorgesehene Schichtung, denn auch die hat ein MI - bei Intel Büchsen hat man das mal BIOS genannt).
Das einzige, wo IBM ein wirkliches Interesse am zunageln hat, ist dass man das OS/400 nicht direkt auf der p Hardware zum laufen kriegt. Die hierfür verwendeten Nägel sind dann Lizenzrecht, vielleicht ein paar Eproms und ein paar Fallstricke.

D*B

Wenn denn der Speicher das einzige Problem wäre.
Der einstufige Speicher ist eine unterstützung des Micro-Codes, liegt also quasi unterhalb des OS.

Verwende ich ein 32-Bit-Programm, kann ich eben max. 2^32 Bytes adressieren, nehme ich 64-Bit eben 2^64.

Dass ich den Speicher auch erhalte wird eben z.B. durch C-Funktionen wie malloc() realisiert.
In Windows-C wird durch malloc() eben die Windows-Implementation GlobalAlloc() aufgerufen, die mir dann den virtuellen Speicher zur Verfügung stellt (oder, wenn die Pagefile zu klein ist, eben einen Fehler auslöst).

In der AS/400 ist eben jede Adresse (Pointer) auf 128-Bit ausgerichtet und deshalb kann das MI-Äquivalent des malloc() mir virtuellen Speicher (egal wo dieser liegt) liefern.

Was du also machen kannst, ist eben per AS/400-C-Compiler einen Linux-Kernel zu erstellen, wobei du alle "Hardware"-spezifischen Funktionen durch eigene Treiber noch entwickeln musst.

[holgerscherer]

Das einzige, wo IBM ein wirkliches Interesse am zunageln hat, ist dass man das OS/400 nicht direkt auf der p Hardware zum laufen kriegt. Die hierfür verwendeten Nägel sind dann Lizenzrecht, vielleicht ein paar Eproms und ein paar Fallstricke.

D*B

Ein Stapel Papier, ein EEPROM und keine Doku, wo man fummeln müsste ;-) Ähnlich damals die Karten für interaktive Kapazität.

Aber ich frage mich immer wieder, warum man sich einen Akt machen will, Linux direkt und ohne Umwege auf der teuren iHardware laufen zu lassen. Man gewinnt ja nichts.

-h