OSDev.org

Hey all.

Just curious...

Assembly code for the Bootloader is 16bit, yup.
My bootloader loads a second stage, also in Assembly, 16bit.

Is there a way I can have the second stage in C?
16bit C is possible, I mean - MSDOS programs could be written in it.

So... questions are : What do I need to do to execute 16bit C code?
What does the bootloader need to setup?

Or is it jus the usual? Generate a freestanding plain 16bit binary from a 16bit C Compiler/Linker - have the Data segment set where we want it and jump to the code location?

Being able to write the Stage 2 in C would help me tremendously.

~Zeii.

zeii wrote:So... questions are : What do I need to do to execute 16bit C code?

You just need a small assembly stub that calls the main function.

Generate a freestanding plain 16bit binary from a 16bit C Compiler/Linker

And here is the problem: Find a assembler/linker for 16bit code

zeii wrote: Being able to write the Stage 2 in C would help me tremendously.

I don't think so, especially because in your hypotetical C second stage loader you'd have to use inline assembly to setup protected mode, 32 bit, the GDT and IDT, paging, the PIC (though these last two can be done mostly in C with just some bits of assembly), etcetera.
The only reason you'd want to use C in your second stage bootloader is because you're planning to do something complex, like GRUB. But then, why not use GRUB itself?

Because I dont want to use GRUB?

I want to have a reasonable amount of flexibility.

And also, I can deal with large amounts of C better than I can with
large amounts of Aseembler.

So, all I need is a 16bit C Compiler / Linker that generates 16bit Flat binary? And I can execute that?

Im curious, would I have to set DS to point somewhere or would the flat binary have a relative ORG?

~Zeii.

Hi,

zeii wrote:So, all I need is a 16bit C Compiler / Linker that generates 16bit Flat binary?

The Bochs project uses "Bruce's C Complier" to generate 16 bit code for their BIOSs. AFAIK it includes it's own toolchain (linker & assembler), it is freeware (or GPL or something) and has been ported to almost every platform (i.e. there shouldn't be any licensing problems if you wanted to port it to your OS one day).


Cheers,

Brendan

Does BCC support the usual C syntax? or do I have to write it K&R Style?

Also, do you know much about its inline Assembler syntax and is it possible to link it with 16bit NASM source?

~Zeii.

Also, I got a copy of Windows XP Today.
Could I not do the 'real' kernel developement under Linux...
but the Bootloader Developement under Windows?

Since, Borlands Turbo C 3.1 is free for all now? Is that not a 16bit compiler? (Although Im not sure how to produce freestanding binaries with TC).

Any advice or ideas would be appreciated.

As for BCC, Im having a tough time finding its sourcecode or a package that will install and work with Slackware.

~Z

Hi,

zeii wrote:Any advice or ideas would be appreciated.

My ideas are probably a little obscure, but IMHO there's only 4 things that are really important - porting the tools to your own OS eventually; a fast development cycle (edit, compile, test, debug, edit, compile, test, debug, etc); making it possible for other people to download and compile without too much hassle (regardless of whether you want other people to be able to do this or not); and finding tools that do what you need them to do.

For an example, currently my entire project uses NASM/YASM, make and a utility I wrote myself, and I use keyboard shortcuts to assemble it and test it (Bochs and Qemu) so I can have a very short development cycle (I can save a source file, press F12 to build everything and then F5 to F11 to test). Also, because of the tools I use I can shift the development to any OS I can think of rather quickly (it's gone from Win98 to WinXP to Redhat to Gentoo in the last 4 years).

With this in mind, does Turbo C suit your needs? IMHO for a bootloader (in the long term), it's far too much hassle using any C compiler considering that a large portion of the code will need to be in assembly anyway....

As for Bruce's C Compiler, I've never used it. The Bochs BIOS source code might be a useful example though...


Cheers,

Brendan

Hi.

My design has two peices of assembler and the rest is in C. The bootblock is assembler which loads the second stage and switches to pmode, and is 16bit. The second piece of assembler is placed at the start of the compiled C when it is linked to make the transition from asm to C. Built like this:
This has the following advantages:

• All the 16 bit code is in boot.asm
• The rest of the startup (IDT, PIC, setting up segments and stack) is in stub.asm, and is best done in assembler in 32 bit.
• The first byte of kernel.bin is the first instruction to execute from the second stage.
• The C code can easily call functions in the stub.asm so any grungy inline asm can be avoided, and vice versa.

You might be able to put 16 bit code at the start of the stub.asm and then switch to 32 bit, but I haven't tried that.

Hope this helps. If you want more details I'll dig out some code if you want?

I can get into 32bit Protected Mode fine and my kernel works fine there.

The thing is, im trying to develop a better Bootloader for my project.

And for that, I want to use 16bit C.

BCC has been hard to find in a sourcecode TAR.

And I have been given a copy of Windows XP Pro SP2 Legit, so... Might as well give it a whirl.

There is OpenWATCOM for 16bit Code on Windows.
There is also Borland Turbo C 1.0 which will generate 16bit code.

Im thinking of doing a massive redesign of Citadel. Massive redesign.
Im getting Andrew Tannenbaums book today, so hmm.

But, I have been told to change the Kernel from a plain binary to ELF.
If only to get the actual size of the Kernel in Memory, so I can place things like Stack and such accordingly.

And... Well, Id rather deal with Structs and such in C.
And id like to do the ELF Header reading before I get into 32bit.
So, I can tally the Memory sizes of the headers, the RODATA, the BSS and such, and end up with the actual Memory size of hte Kernel.

At the moment, the Filesize is the only thing I know and that is gathered at Boot, but the Filesize obviously != Memory Size.

So, Anyone have any tips on getting Turbo C 1.0 to output 'stand alone' 16bit code?

I heard Borland products of that age have strange problems working on Modern machines, that they break running on faster computers?

*Shrug*

~Zeii.

And I have been given a copy of Windows XP Pro SP2 Legit

Legit copies really exist? *stands in awe*



Disclaimer:
Humour purposes only, not representative of actual views or software used personally, blah blah blah

zeii wrote: I can get into 32bit Protected Mode fine and my kernel works fine there.

The thing is, im trying to develop a better Bootloader for my project.

And for that, I want to use 16bit C.

The same with me. It want to make my Bootloader in C to be able to use existing file system headers (if not code) for reading disks. Having a duplicate version in assembly is a fine way of making strange bugs. Also having the loader in 32 bit means a 32 bit disk driver instead using the BIOS, which is duplicating kernel code.
Any luck with Turbo C?

Hey, Woah - old topic.
Ah, me from the past.
Hello Meeeee.

Anywho, I dropped the idea of a 16bit C Bootloader, since I made this post I have got much better at understanding Assembly. I actually quite like Assembly now .

I have two stages, the second stage is full 32bit C. Which, is nice too.

However, if you are looking to do the stage1 in C, I can recommend you to the BC Compiler. Its kinda hard to find these days (Atleast it was for me) but it generates 16bit C code and it runs on UNIX and its derivatives.

If you run Windows, you should get Turbo C 3.0 from Borland - its free now in their Museum, however, I cant offer you any advice on how to compile freestanding code with that since I bailed on the 16bit C issue.

Oh, and GCC *can* compile 16bit C code aswell, just... its kinda... not... really 16bit code .

If you put asm volatile (".code16"); in your program, before any data - (says GCC Manual), GCC will compile the code to work for a i386 system operating in 16bit Real mode. HOWEVER, The addressing systems and such are STILL 32bit. It still uses 32bit registers, so EAX instead of AX. (Thats why its i386 16bit code, rather than generic 16bit). Dont quote me on this, if you want to learn more about the possibility of 16bit C code generated with GCC, check out the GCC Manuals. (GAS Manuals too)

Goodluck
~Zeii