calling 16bit and 32bit c function from asm

[lorax]

I have a fat12 boot sector, a kernel loader and a 32bit kernel. In loader I go into pmode and then jump into 32bit c kernel. Now I want to use c for some part of my 16bit loader code. But as I know gcc doesnt support 16bit code. So I decided to use tcc for compiling 16bit part. Is it possible to call 16bit C code and 32bit C code from an asm file compiled by nasm? And as I understand from the nasm complies coff format doesnt support 32 bit relocations. So which format should I use? Ill be glad if anyone give an example asm file calling 16bit C code(compiled with tcc) and 32bit C code(compiled with gcc) in it?

[Pype.Clicker]

Be prepared to face the ugliest nightmares as you try things like that. It's not necessarily impossible, but it will at least require that your 16-bit loader got linked against 16-bit ASM and that both are sufficiently kept apart of 32bit code.

No linker i'm aware of will be able to mix code coming from gcc with code coming from tcc. nasm can produce code that match each, but not both, so all you could have is either a 16 bit loader that only sees the 32bit kernel as an opaque array of bytes (e.g. no real linking between the two) or a loader that sees a 16-bit program as an opaque array of bytes (such as a COM program bundled in the binary).

may i ask why you want that 16 bits program so hard in your loader ?

[kataklinger]

Why don't you write that 16bits part of code in asm, enter the protected mode and continue running 32bits code running in C? Or if you cannot do that way (you want to use bios int 13h so you don't need to write your ata/atapi/fdd drivers?) you can think about three stages loading.

[lorax]

may i ask why you want that 16 bits program so hard in your loader ?

For more readablity. I mean my loaders 16bit part is becomming larger and larger(Enabling a20 line, checking vesa compatiblity, configuring pci devices and deciding the access type of pci, prompting user for some information, etc). So I thought to convert them into c to achive more readable code. But if it is hard or time consuming as you said, I may give up my opinion. Or as kataklinger said I may use three-stage loader.

Thanks for answers.

[kataklinger]

What are you asking user so early(in boot not in development process )? And why can't you do PCI stuff in pmode?

[lorax]

And why can't you do PCI stuff in pmode?

I do PCI stuff in pmode. But there are two mechanism to access pci config space. Interrupt 0x1A returns which mechanism should be used and last pci bus number. I couldnt find in pmode how to decide which access mechanism to use. So some pci stuff should be done before entering pmode I think.

And I inform user for hardware configuration and ask which vesa mode to use( My os can not change resolution and color depth yet

[Pype.Clicker]

so basically, what you need is not 16 bits C programs with your bootloader: it's a Virtual Monitor for VM86 mode ...

[kataklinger]

I couldnt find in pmode how to decide which access mechanism to use. So some pci stuff should be done before entering pmode I think.

Info about direct I/O access PCI under pmode and 32-bit PCI BIOS:
http://my.execpc.com/~geezer/osd/pnp/index.htm

[Pype.Clicker]

yeah, the problem is (like every pmode BIOS interface) that not all bioses have it. Especially, BOCHS doesn't.

[lorax]

so basically, what you need is not 16 bits C programs with your bootloader: it's a Virtual Monitor for VM86 mode ...

Is there a good tutorial or example on VM86 mode?

[Pype.Clicker]

well, we have http://www.osdev.org/osfaq2/index.php/VirtualMonitor

I'd recommend the OsLib (iirc) implementation as a reference. It was fairly simple to adapt to another OS, and there is also Tim Robinson's tutorial, which i find a bit harder to use for "real" programming ...

http://osdev.berlios.de/v86.html

[kataklinger]

yeah, the problem is (like every pmode BIOS interface) that not all bioses have it. Especially, BOCHS doesn't.

Still he can use direct I/O. He can try using mechanism type 1 it it fails switch to type 2, and if this fails ther is no PCI.

[Pype.Clicker]

as seen on the FAQ:

There are two incompatible methods for accessing the ports; on most chipsets, -b1 is the proper method ("PCI Configuration Space Access Mechanism #1"). On some chipsets (mostly the earliest ones supporting PCI), you will need to use -b2 ("PCI Configuration Space Access Mechanism #2"). USING THE INCORRECT METHOD CAN HANG OR RESET YOUR COMPUTER!,

I'd say i'd welcome a multiboot info about what PCI mode is to be used ... too bad they only thought about VBE modes ...