Float to int conversion (using Bare Bones)
Re:Float to int conversion (using Bare Bones)
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...
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...
Every good solution is obvious once you've found it.
Re:Float to int conversion (using Bare Bones)
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.
Code: Select all
ENTRY (_loader)
SECTIONS
{
. = 0x00100000;
.text :
{
*(.text)
*(.rodata)
}
.data ALIGN (0x1000) :
{
*(.data)
}
.bss :
{
_sbss = .;
*(COMMON)
*(.bss)
_ebss = .;
}
}
Every good solution is obvious once you've found it.
Re:Float to int conversion (using Bare Bones)
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.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.
What do you mean about format conversion being done in userland? Sorry, I still don't get it :-\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.)
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.
Re:Float to int conversion (using Bare Bones)
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.marcio.f wrote: What do you mean about format conversion being done in userland? Sorry, I still don't get it :-\
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.
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 thought kernel would need to output what's being done, right?
Every good solution is obvious once you've found it.
Re:Float to int conversion (using Bare Bones)
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.
Code: Select all
#define OS_NAME "MyOS"
#define VERSION_MAJOR 0
#define VERSION_MINOR 1
(...)
printf("%s %d.%d\n", OS_NAME, VERSION_MAJOR, VERSION_MINOR);
Re:Float to int conversion (using Bare Bones)
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).
Re:Float to int conversion (using Bare Bones)
Thanks! I think I understand now. I must code a ?mini-printf? for the kernel and the ?normal? printf for the programs. Thanks againAR 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).
Re:Float to int conversion (using Bare Bones)
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.
Every good solution is obvious once you've found it.
Re:Float to int conversion (using Bare Bones)
Yes it is, thanks
P.S.: I still can't write that '7' to the screen, is there a way out?
P.S.: I still can't write that '7' to the screen, is there a way out?
Re:Float to int conversion (using Bare Bones)
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
Re:Float to int conversion (using Bare Bones)
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
@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
Re:Float to int conversion (using Bare Bones)
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 that I still can't help with a Cygwin debug session of my own. Can anybody else verify / falsify this on a Cygwin environment?
Every good solution is obvious once you've found it.
Re:Float to int conversion (using Bare Bones)
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.
What is it you wanted to test? Could you give me the steps? maybe I can try it out later.
Only Human
Re:Float to int conversion (using Bare Bones)
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'.
Every good solution is obvious once you've found it.
Re:Float to int conversion (using Bare Bones)
Yeah, I guess you're rightSolar 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).