Trimming down the (huge) float lib to only do what we want

[M52]

Sounds like a plan

[ColErr]

What do we need from the lib for the kernel?

[M52]

I think we need to think about this differently. We should add Float support to the kernel. The kernel itself probably shouldn't have to use it. It is just that the kernel makes these things available for future operating systems.

it is a bit of a wager. Does every OS really need this? Well...I say, up to some limited extent, yes. Let's just jam the most basic functions in...

[ColErr]

That's what I'm saying. Instead of adding it into the kernel, allow the kernel to load libraries. This way we can still keep it small, but allow people the option to add it in. Hell, make a whole bunch of libraries that can be loaded, and offer then alongside the kernel, but I don't think it should be part of the kernel.

[dilbertfan]

The kernel must use it for task scheduling

[M52]

Well how do you plan to make task scheduling? Why does that need float's?

I know it's probably complicated to explain but, I honestly can not see why you'd need to have floats for that...

[viccuad]

I also cannot see why the kernel must use floats for task scheduling. please explain! :)

[dilbertfan]

The kernel task scheduler deal with decimal numbers in its operation (for percent of clock calcs), which thePalindrome says require float

[viccuad]

Mmm maybe im wrong, but since you cannot assign a program the clock tick number 143,7 (only 143 or 144), I dont see the need for floats.

[dilbertfan]

for calculating percent time shares requested by a prog, but if someone has a better idea give it

[viccuad]

Using floats, we can calculate percents like 57,4% or 23,1% Using integer, we can only calculate percents like 57% or 23%, but i think is not so bad, and we are just saving some cicles calling a function and calculating it like an integer.

Can it be do with integers?

[thePalindrome]

I'm not 100% sure that there wouldn't be issues, but we'll just go ahead and see what happens...

[M52]

Okay maybe I am misunderstanding this, but isn't it easier to assign clock ticks to each program instead of a percentage-wise share?

Even if the latter is used, we might as well use integers because honestly, that 0.99 percent isn't going to matter too much...

[thePalindrome]

iirc the percentage was for assigning priority, but I'd have to ask around, dig in chat logs to find it...

[ColErr]

Ok, then would it be possible to either A) Use "Half" Precision (16 bit) floats, or B) Use fixed precision

I'm just worried about the speed of using full 32bit floats for something being done in the background. Even 16 bit floats would still be somewhat slow I would think. And there is an IEEE spec for half precision floats.

[M52]

It sounds very bad to me to introduce an aspect that we know is going to be slow into the very object that is so time critical!

Ints all the way! You wont probably run more than three programs at once so you get 33, 33, 33 share, meaning you do not use 1 percent...well...you do. For the kernel. Anyway, that is the only loss we could possibly suffer.

So what we need to find out is:

Is 1% of the total timeshare more or less than the time it takes to handle floats? If it is less, we use ints, if it is more we use floats.

[dilbertfan]

netserv+CLI are 2 progs, so more then three

[ColErr]

I have the beginnings to my IEEE spec float lib up, going to keep working on it. If we want to move it away from IEEE to suit our needs better, let me know. Should be a lot faster, and use less space than the current one.

[M52]

I am still figthing for INTEGERS!!!

xD

No but seriously, floats introduce completely unneeded overhead. The kernel needs to be light and fast, if an OS wants floats they can either program their own methods for that or use our lib (which we whould have to make/rewrite).

And if you guys really want mathematical precision built-in, then we should use fixed size precision. Actually, coming to think of it, providing basic datatypes isn't too bad of an idea. maybe that is an OS task...maybe not...it's one of those borderline things....

[Callum6677]

I say integer based task scheduling all the way

[viccuad]

do you really even know what are you talking about, using percentages for assigning priority?

it seems to me that you have never ever readed anything about how kernels work. we need to get documented, this is not an easy task... don't try to make a guess and hope it will work.

there are a lot of reasons why that is not the correct approach, but just one: do you really want to make calls to a float library every and each time you are in the process scheduler? really?

another one: do you really want to get that part, so important, promt to errors and bugs if someone changes the float library after without thinking that it is used for a key task in the preemtive process scheduler?

also, you dont assign priority by percentages. that doens't make any sense. what if you run another process more? you recalculate each percentage for the already running processes that were there before?

as i have said in other issues, lets go the linux way...... Linux way: each process has an integer as it's priority. the bigger the number, the less the priority.

• priority 0: init process. all processes are forked from this one, all are their sons.
• priority 1-1000: rest of processes. 1 is more prioritary than 2, and so on.
• kernel processes don't go into the process scheduler. you always run kernel first, and if you have space runtime, you fill it with other processes.

preemtive kernels need to deal with fast process response time, good throughput for background jobs, avoidance of process starvation, reconciliation of the needs of low- and high-priority processes....

just a peek: we need to change priorities each second, to, for example, prevent process starvation. like: -what if you have the lifesystem and piloting processes with priority 3 and a less important process with priority 10? lets say that our algorithm has a ordered queue of processes, by priority. if the algorithm for the task scheduler don't changes the priorities between epochs, then, always takes the piloting and lifesystem processes because of their priority. the other process with priority 10 starves to death.

I do really think that we should all get documented before thinking this kinds of things, i think it can really save time in the future.