Umstellung von *.com in *.exe ... Vorteile?
Michael Poremski
ich nutze eine etwas ältere Programmiersprache zur Maschinensteuerung,
dessen ausführbare Datei eine *.com Datei ist.
Da die Programme mehr oder weniger an chronischem Speicherplatzmangel
leiden (*.com Dateien können ja mit Programmcode, Variablen etc. nur
in einen 64k Segment liegen) überlege ich seit geraumer Zeit, ob es
nicht möglich wäre hieraus eine *.exe Datei mit zumindest einmal
getrennten Segmenten für Programmcode, Variablen (Stack etc.) zu
machen.
Ich habe natürlich sämtliche Sourcen, die sind allerdings in Intel
Assembler 1.0 geschrieben ... :-(
Meine Fragen:
1. Wie hoch wird der Aufwand sein solch ein Programm umzuschreiben?
=> Erfahrungswerte reichen :-))
2. Welcher Assembler ist weitestgehend Intel 1.0 kompatibel? - Sprich
es sind hunderte von Seiten Assemblercode, die auf einen neuen
Assembler komplett manuell umzuschreiben ist praktisch kaum
möglich! - Oder gibt es Automatismen für solch ein Vorhaben?
3. Es gab ja einmal den Blinker - der konnte mit relativ geringem Auf-
wand mehr Speicherplatz durch Virtualisierung (?) von Realmode
Programmen schaffen. Wäre das vielleicht ein einfacherer Weg?
Was würdet ihr empfehlen?
Herzlichen Dank!
MfG Michael
---
---
MfG Michael Poremski
Steffen Christgau
> Maschinensteuerung,
> dessen ausführbare Datei eine *.com Datei ist.
> Ich habe natürlich sämtliche Sourcen, die sind allerdings in Intel
> Assembler 1.0 geschrieben ... :-(
Vielleicht nicht ganz on topic aber ein Vorschlag. Belasse alles, was
direkt mit der anzusprechenden Hardware zu tun hat, in Assembler. Den
Rest (Programmablauf) packst du dann in eine Hochsprache deiner Wahl,
deren Compiler das Linken von Funktionen aus Object-Dateien (oder
ähnlichem) unterstützt.
MfG Steffen
Heiko Nocon
>(*.com Dateien können ja mit Programmcode, Variablen etc. nur
>in einen 64k Segment liegen)
Das ist doch Unsinn.
Beim Laden von *.com-Dateien wird nahezu der gesamte RM-Speicher
reserviert (der größte freie Block) und steht dem Programm exklusiv zur
Verfügung. Dementsprechend kann es sein Variablengerümpel und seinen
Stack völlig problemlos fast über den gesamten Speicher verteilen.
Platzprobleme könnten also allenfalls der Code und die
vorinitialisierten Daten bekommen. Und auch das läßt sich lösen, indem
man den Kram in Module (z.B. weitere *.com-Dateien) zerlegt und händisch
nachlädt. Das hat obendrein den Vorteil, daß man Module bedarfsgerecht
nachladen kann und immer das Maximum an Speicher für die variable Daten
zur Verfügung hat.
Ach so: Assembler, die auf Grund irgendwelcher abstruser
"Speichermodelle" solche Art der Programmierung unterbinden, taugen nix.
Michael Poremski
Welchen Assember, Linker usw. würdet ihr mir empfehlen um den alten,
Intel Assembler von 1985 (!) langsam abzulösen? Das Problem ist wie
beschrieben, er sollte (muss!) nahezu 100% Syntaxkompatibel sein, da
ein sehr aufwendiges (manuelles) Umschreiben kaum möglich, erwünscht,
ist.
Der Intel Assembler 1.0 kommt kaum mit "modernen"
Environmentvariablen, geschweige denn mit aktuelleren Betriebssystemen
als MS-DOS aus ... Wäre schon vorteilhaft zumindest einmal die Tools
wie Editor usw., die man unter Windows nutzt nutzen zu können :-))
Spiro Trikaliotis
Michael Poremski <michael....@t-online.de> schrieb:
> Welchen Assember, Linker usw. würdet ihr mir empfehlen um den alten,
> Intel Assembler von 1985 (!) langsam abzulösen?
Ich kenne den Intel Assembler zwar nicht, kann mich aber erinnern, dass
früher gerne als Argument pro MASN gesagt wurde, dass dieser
hundertprozentig kompatibel dazu wäre.
Wie gesagt, ob das stimmt kann ich leider nicht beurteilen.
HTH,
Spiro.
--
Spiro R. Trikaliotis http://opencbm.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/