Thema: EXTERN und GLOBAL in NASM

[bscreator]

Hallo,

Ich komm mit externen Unterprogrammen unter NASM einfach nicht zurecht. Um ein externes Unterprogramm aufzurufen, muss man es mittels GLOBAL für andere Module zugänglich machen. Dann kann mittels EXTERN darauf zugegriffen werden, so die Hilfe.

Ein externes Unterprogramm für andere Module via GLOBAL zugänglich zu machen ist kein Problem.
Aber das Aufrufen mit NASM via "EXTERN" funktioniert nicht.

Unterprogramm:

Code: [Auswählen]

GLOBAL print
print:
lodsb
cmp al, 0
je print_end
mov ah, 0x0E
int 0x10
jmp print
print_end:
ret
Hauptprogramm:

Code: [Auswählen]

EXTERN print

org 0x7c00
jmp start
hello db "Hello World",0
start:
xor ax, ax
mov ds, ax
mov si, hello
call far print   

Beim Kompilieren des Hauptprogramms kommen folgende Fehler:
"Binary output format does not support external references"
"Binary output format does not support segment base references"

Laut NASM-Hilfe (unter Help->Programming in NASM->Expressions->SEG) kann man ein Unterprogramm mittels CALL FAR routine oder CALL SEG routine:routine aufrufen, was jedoch nicht funktioniert.

Wie kann man ein externes Unterprogramm in NASM aufrufen ?

Vielen Dank,
bsc
 

[LittleFox]

Hi,

ganz einfach: das geht nicht wenn du flache binaries erstellen lässt. Du musst als Ausgabeformat eines wählen welches das unterstützt (bspw. ELF) und die erzeugten Objektdateien dann zusammenlinken (mit ld).

Bitte sag aber nicht das das Bootloader und Kernel werden soll ...

Grüße,
LittleFox

[Svenska]

@bscreator: Hast du ein IBM-Gerät der Baureihen 3270, 4860, 5140, 5150, 5155, 5160 oder 5511? Würde mich wirklich mal interessieren.

Gruß,
Svenska

[bscreator]

Ach mist : FLAT BINARIES,

hab ich wieder im Zusammenhang mit den anderen Ausgabeformaten vergessen. Stimmt, die beinhalten ja keinen zusätzlichen Header und anderes, sondern nur den Text,  bzw. Code im ASCII-Format.

Bitte sag aber nicht das das Bootloader und Kernel werden soll ...

Nee, bin zwar manchmal ein bisl verrückt, aber so verrückt auch wieder nicht 

Hast du ein IBM-Gerät der Baureihen 3270, 4860, 5140, 5150, 5155, 5160 oder 5511? Würde mich wirklich mal interessieren.

Könnte man bei mir zum Teil vielleicht meinen 

Aber das ist es nicht.
Nur welches Ausgabeformat brauch ich, um 8086-kompatible Binaries mit zusätzlichem Header anzufertigen ?

Vielleicht ELF

[LittleFox]

Hi,

wenn du unbedingt Flat binaries willst, lass die von NASM ELF Objecktdateien erstellen und linke die dann wieder zu einer flachen binary

Bitte sag aber nicht das das Bootloader und Kernel werden soll ...

Nee, bin zwar manchmal ein bisl verrückt, aber so verrückt auch wieder nicht 

Dann ist es ja gut

Grüße,
LittleFox

[Sannaj]

Nur welches Ausgabeformat brauch ich, um 8086-kompatible Binaries mit zusätzlichem Header anzufertigen ?

Das hängt ganz davon ab, wo du den Code ausführst. Wenn du einen Bootloader baust, musst du Flat Binary verwenden. Für den Kernel musst du das Format nehmen, was dein Bootloader unterstützt (bei GRUB sind das elf32 und a.out). Für andere Programme, das was dein Betriebssystem unterstützt. Wenn du wissen willst, wozu da was taugt, musst du "nasm -hf fragen".

[kevin]

GRUB unterstützt a.out nicht besser als jedes andere Format einschließlich flacher Binaries. Man braucht dann halt den erweiterten Multiboot-Header.

[Svenska]

Hast du ein IBM-Gerät der Baureihen 3270, 4860, 5140, 5150, 5155, 5160 oder 5511? Würde mich wirklich mal interessieren.

Könnte man bei mir zum Teil vielleicht meinen 

Wenn nicht, solltest du vielleicht nochmal über Sinn und Unsinn deines Projekts nachdenken. Welchen Emulator benutzt du? Der einzige, der wirklich einen PC emulieren kann (oder es versucht), ist MAME. Der nutzt das originale PC-BIOS.

GRUB benötigt den Protected Mode, ein 8086-Betriebssystem, was einen 386er zum Laden braucht, bringt nicht viel . Mir sind keine universellen Bootloader für 8086er bekannt, was auch daran liegt, dass das ursprüngliche PC-BIOS keine Festplatten kannte (die kamen erst mit dem XT hinzu) und jedes Betriebssystem seinen eigenen Bootcode benutzt. Ich kenne nur Bootmanager/Bootselektoren, wie z.B. den von XFDISK, den ich auf 286ern benutze. Das heißt, bscreator muss einen eigenen Bootloader (kann auch eine DOS-Anwendung sein) schreiben, wenn er ein OS dafür entwickelt.

bscreator: Ich möchte mal gerne wissen, was du eigentlich erreichen möchtest. Was soll dein Betriebssystem können und warum soll es 8086-kompatibel sein?

Gruß,
Svenska

[Sannaj]

Traditionell ist es so, das der MBR den Bootsektor der aktiven Pation einließt. Dieser erscheint dann genauso wie ein Diskettenbootsektor auch.

[Svenska]

Traditionell ist es so, das der MBR den Bootsektor der aktiven Pation einließt. Dieser erscheint dann genauso wie ein Diskettenbootsektor auch.

Mit Bootloader meinte ich nicht den MBR. Übrigens setzt das voraus, dass die Festplatte per int13 erreichbar ist und das BIOS den MBR auch einliest und ausführt. Das wurde erst mit dem XT bzw. damaligen SCSI-Controllern eingeführt.

Gruß,
Svenska

[erik.vikinger]

Hallo bscreator,


Die Frage nach einem Executable-Format für x86-Real-Mode-Programme wurde da (in einem Deiner Threads) schon man ausführlich beantwortet: http://forum.lowlevel.eu/index.php?topic=2631.msg30018#msg30018.

Das COFF-Objekt-Format kommt meines Wissens nach auch recht gut mit x86-Real-Mode-Segmenten zurecht ist aber nicht "executable" sondern nur "linkable", es wurde früher gerne als Zwischenformat (eben für die OBJ-Dateien) benutzt. Heute ist das natürlich alles längst ausgestorben weil keiner mehr für den x86-RM entwickelt, außer vielleicht die Leute die für GRUB o.ä. den Einsprung in den PM bauen und das ist so wenig das man dafür keine besonderen Dateiformate benötigt.


Grüße
Erik

[Dimension]

FLAT BINARIES, [...] beinhalten [...] Code im ASCII-Format.

Binary ist NOT equal to ASCII.

Linkt es, wenn du ELF benutzt?