Can NASM generate a header file / Run from Extended Memory

[vbguyny]

Currently, when I write a program that uses in my OS, I include the entire kernel with each program. Not only does this make my program 28 KB larger but it also eats at the 64 KB segment limit. As I have moved from the real to "unreal" memory mode I was beginning to wonder what it would take to do the following:

1. Remove the Kernel completely from being included in every program (This would have to stay in conventional memory as it uses BIOS).
2. Have the program load/execute from extended memory (hopefully this means programs larger than 64 KB).

But I have a bunch of questions. First off, I think I would need to create a header file in assembly that would have the locations of the segment:offset for each function in kernel that can be called from any program. Is there a utility that can generate an ".inc" file for me with the address of each method in my kernel?

I would then need to replace all of my ret instructions with retf for any public functions of my kernel. Also I would need to add 2 bytes to each of my argument parameters to account for the return segment. But how can retf work if I am using extended memory for my program? Won't retf only be able to return to the limit of conventional memory which is 1 MB?

Furthermore, assuming that I am able to execute my program (IP register) in extended memory, how will the other registers behave that use segment memory (SS, for instance)?

Thanks for your advice.

[BrightLight]

Why do you need the segment:offset of each kernel function? Just use an interrupt.
For example, (just an example, really) you put your kernel API at interrupt 0x5F. The handler for this interrupt might look like:

Code: Select all

int0x5F_handler:
	; Assuming EAX contains the function code...
	cmp eax, 0
	je reset_disk

	cmp eax, 1
	je quit_program

	cmp eax, 2
	je write_file

	; So on....

Then when your program wants to write a file to the disk:

Code: Select all

mov eax, 2
int 0x5F

[azblue]

Are you using unreal mode or huge mode?

In unreal mode your code and stack are still limited to 64K; it's only your data that's 4GB.

If your goal is to continue using the BIOS you may want to try v86 mode or switching back and forth between real and protected mode.

Though I'd question your decision to use the BIOS (assuming that's why you're avoiding protected mode), and I'd encourage you to look into writing your own device drivers. Directly dealing with things like PS/2 keyboards, hard drives, the PIC, the timer, is all relatively easy. Admittedly, floppies and CDs are harder, but not impossible; getting started in protected mode is not out of reach for anyone willing to put the work in.

[vbguyny]

@omarrx024: I was thinking about using interrupts a while ago (Same as int 21h or int 80h that MS DOS and Linux use, respectively) however the parameters are limited to the number of registers and I have functions that use up to more data than registers available (I also use x87's FPU)! Therefore, the stack is the better choice. I don't mind if the stack is limited to 64 KB, I am more concerned about my applications being restricted to 64 KB.

[vbguyny]

@azblue: As indicated in my original post, I am using unreal mode. The reason why I am still using BIOS is merely for the items you have listed but because I am wrapping *all* of the BIOS functionality, and then some, by my kernel. This includes printing routines, joystick handling, serial input/output, etc.

I'll take a look into v86 mode. Thanks.

[Kevin]

Where is it written that call/ret must be used with parameters on the stack and int/iret with parameters in registers? You can combine it any way you want.

[vbguyny]

@Kevin: I didn't know that! Thanks, I think I can figure it out from here.

EDIT: Ok, it looks like this is going to work however it is going to require me to update the correct offsets of each parameter as additional information is now being pushed onto the stack after the parameters are pushed from the original function.

Now that I can get my Kernel out of my programs they will be a lot smaller. However, how do I make my programs run in extended memory? It looks like they still need the CS and DS segments to be defined so does this mean it isn't possible under real/unreal mode or am I missing something.

Furthermore, the call instruction only appears to save the IP address so if my program is larger than 64 KB does this mean that I can only use jmp? What about retf, will it work if the CS isn't valid because I am in extended memory?

[BrightLight]

@omarrx024: I was thinking about using interrupts a while ago (Same as int 21h or int 80h that MS DOS and Linux use, respectively) however the parameters are limited to the number of registers and I have functions that use up to more data than registers available (I also use x87's FPU)!.

Then pass your parameters in memory, like Windows NT does.
For example, to write 200 bytes from address 0x600 to file.exe:

Code: Select all

mov eax, 2
mov edx, file_structure
int 0x5F

; more code...

file_structure:
.filename		db "file.exe"
.size			dd 200
.buffer			dd 0x600
; ---

[vbguyny]

@omarrx024: Thanks for the suggestion.

[vbguyny]

Could anyone please confirm whether or not I am able to use the call instruction if have a program running in extended memory?

[Unsigned]

Could anyone please confirm whether or not I am able to use the call instruction if have a program running in extended memory?

Everytime a segment register is modified, its hidden part will be recalculated. It will be got from the GDT/LDT in protected mode, or calculated on-the-fly in real mode. So if you use any far call or far ret, you will no longer be able to continue running a program from extended memory if you are using voodoo mode. Same goes for interrupts and irets. My advice is not to use voodoo mode. Use real mode or protected mode.
Aditionally, even when you use voodoo mode with code running in conventional memory, some BIOS calls or hardware interrupts may save and restore the FS/GS registers, therefore resetting them to act like real mode addressing again.