OSDev.org

What AR wanted to say is this:

Once you have userland applications running on top of your kernel, they will call kernel functions, e.g. through the C Standard Library. (At some point, fopen() has to call the kernel...)

Now, the userland application might have some important data currently stored in FPU registers. If your kernel does not touch any FPU registers at all, you do not have to save / restore them as the FPU remains untouched anyway. But if your kernel fiddles with FPU registers, you have to save / restore, which eats many CPU cycles and some memory.

Anyways, format conversion of <stdio.h> is something that should happen in userland, anyway... only very few things from the standard lib have to be done in kernel space. (Stream open / close, read / write, signal handler registering, that kind of stuff.)

-msoft-float replaces hardware FPU calls with library calls, i.e. leaving the FPU registers untouched. However, you have to provide those libraries...

marcio.f, try this as replacement for linker.ld (linking .rodata into .text section instead of a section of its own):
If that helps, I'd be obliged if someone would fix it in the Wiki.

Solar wrote:Now, the userland application might have some important data currently stored in FPU registers. If your kernel does not touch any FPU registers at all, you do not have to save / restore them as the FPU remains untouched anyway. But if your kernel fiddles with FPU registers, you have to save / restore, which eats many CPU cycles and some memory.

My kernel doesn't need or will work with float numbers, I was just testing to see how format conversion for floats could be done.

Anyways, format conversion of <stdio.h> is something that should happen in userland, anyway... only very few things from the standard lib have to be done in kernel space. (Stream open / close, read / write, signal handler registering, that kind of stuff.)

What do you mean about format conversion being done in userland? Sorry, I still don't get it :-\
I thought kernel would need to output what's being done, right?

I tried that linker script but still don't get any '7' on the screen, instead a '0'. Attached are the files I'm using. This kernel.c is as simple as possible (no printf and alike) just to test float numbers.

marcio.f wrote: What do you mean about format conversion being done in userland? Sorry, I still don't get it :-\

Usually you design the C standard lib in such a way that the vast majority of its code runs in userland (i.e., non-priviledged code), or at least can run in userland, with only a few functions actually interfacing with the kernel.

Format conversion in the printf() function family is something that should run in userland. The kernel doesn't need it, and userland code doesn't have to call the kernel to do it. Only when all the coversion is done and you have a char array containing the finished output string do you call the kernel to actually print that to screen.

So it's OK for you to try your hands on float conversions while still in the kernel, but you could do so just as well in a userspace app since it's nothing that would end up in the kernel anyway.

I thought kernel would need to output what's being done, right?

The kernel is the only one having hardware access, so you need the kernel to print a string to screen or file. But you don't need the kernel to assemble that string.

I think I'm beginning to understand , but how can I actually separate non-privileged code from kernel code, i.e. for the printf function? What I mean is, if I do something like:
in the very beginning of the kernel, just to print some information, I have to convert some integer numbers to string, right? That's the part that confuses me.

He means you shouldn't need full printf functionality at the kernel level, you will still need a basic printf for panics and status reports but it should be minimalist. The real printf that is used by programs doesn't need to be in the kernel (and may actually be better if it isn't).

AR wrote: He means you shouldn't need full printf functionality at the kernel level, you will still need a basic printf for panics and status reports but it should be minimalist. The real printf that is used by programs doesn't need to be in the kernel (and may actually be better if it isn't).

Thanks! I think I understand now. I must code a ?mini-printf? for the kernel and the ?normal? printf for the programs. Thanks again

I hacked together a new page for the Wiki, LibraryCalls, which elaborates on the issue of kernel-space vs. user-space library implementation. Tell me if it's helpful.

Yes it is, thanks

P.S.: I still can't write that '7' to the screen, is there a way out?

i have an idea, it may not work but, tell gcc to use fpu in the prosessor, it will be vary fast with the right instruction set and can be enabled by this: http://www.network-theory.co.uk/docs/gc ... ro_64.html

Thanks for the suggestion but it has generated a panic on Bochs ::)

@all
Thanks for your help but, as some people pointed out, there's no reason for using float numbers on kernel so I'll just ?forget? about it

I know I'm being a pain, but you do have an issue there, and "just forgetting" about it will probably bite you later. I suggest weeding it out right now, so you don't make the same mistake again (when it might be even harder to debug).

Sorry that I still can't help with a Cygwin debug session of my own. Can anybody else verify / falsify this on a Cygwin environment?

Sorry I can't really read through all this but I do have a CYGWIN cross compiler setup.
What is it you wanted to test? Could you give me the steps? maybe I can try it out later.

He followed the BareBones example code from the Wiki, adding the code snipped quoted initially to his main(), and doesn't get the '7' he expected but a '0'.

Solar wrote: I know I'm being a pain, but you do have an issue there, and "just forgetting" about it will probably bite you later. I suggest weeding it out right now, so you don't make the same mistake again (when it might be even harder to debug).

Yeah, I guess you're right