Would this not make it "stdcall" rather than "cdecl"?
It's a mess!
Absolutely and the way I'm doing it is even messier
Frank, but it is the only workaround I've figured out so far to mimic segmentation as in MASM.
Distance is not a major concern as this 16 bit segment of my loader is probably going to be within 4 to 5 sectors, and I've got 63 to work with before data and/or code are out of reach, as far as being near is concerned. If it does become problematic, I'll just move it to a place where it's within 32k of any caller.
This is the part of the boot sector that brings us to next sector which is @ 80:0
FILE1
jmp 0x7c0:Start ; So I know CS is 7C0
nop
Start cli ; Disable interrupts
..... More code here
.Read_Disk push es
mov ax, LOAD_BASE
mov es, ax
xor bx, bx ; ES:BX = LOAD_BASE:0
mov cx, 2 ; Load second sector
mov ax, 0x220 ; AH = 2, AL = 32 sectors (16,384 bytes)
int DISK_IO
pop es
jc Prompt.Error
jmp LOAD_BASE:0 ; Execute main body of startup code
FILE2
; ============================================================================================
; Sector 2
; --------------------------------------------------------------------------------------------
mov ax, 0x507
int VIDEO
mov ah, YELLOW << 4 | BLACK ; Yellow border with WHITE text
mov al, D_GREY << 4 | BLACK ; Dark grey background with BLACK text.
push ax
mov ax, 7
push ax
push Begin
>>>>> OP CODE FITS HERE <<<<
Begin: mov ax, cs
mov ds, ax
mov es, ax
push Prompt ; Work in progress
call ShowS
xor ax, ax
int 0x16 ; Wait for keystroke from operator
mov ax, 0x500 ; Switch to Page 0
int VIDEO
hlt
jmp $ - 1
/dev/sdb is my kill, crash and burn drive and I sure hope I never forget to use "b" as sda is my M$ drive and sdc is my Linux drive.
dd if=FILE1 of=/dev/sdb
dd if=FILE2 of=/dev/sdb seek=1
Now I have an image that which I can test with whatever, each of which have an origin of 0, but the first and last line of FILE1 sets CS appropriately to make this segmentation model work the way I want it to.
As documentation is severely fragmented. I'm designing a boot loader that will tell which drive I'm booting from, what the contents of all the registers are. A display of all interrupts 0:0000 - 0:037F I think it is and the contents of most of BIOS data area.
As I see it, there are two "issues" we need to deal with. One is the "order of parameters" - that's just a case of which way the "other language" writes 'em: "frame (page, body, border)" vs "frame (border, body, page)". We push 'em where we push 'em. The other issue is "who cleans up stack" - caller or callee. You've got a "callee cleans up" function. I think "cdecl" would be "caller cleans up". (I forget which way Pascal does that) As you point out, the code is easily modified for another calling convention, if need be.
16-bit code also has the "near call" vs "far call" distinction. You've got a "near call". If it were a "far call" the return address on the stack would include segment as well as offset, and the parameters would start two bytes further up the stack. (data might be "near" or "far" as well)
Once this code has done its job and hopefully the community will participate and let me know the results on thier versions of BIOS, it will be moth balled and I'll probably go right into protected long mode before I even leave boot sector. The point being, a larger 16 bit project should certainly be aware of those points you brought up Frank.
