JOEL4: x86 segments should be 16-bit values

When loading the task register with LTR, a 16-bit segment must be used.
A bug in the macro led the LTR instruction to try to load from a 32-bit
register, which failed during assembly.  This bug was only seen when
compiling with O1 or greater, since a memory location was used with O0
which does not exhibit the same behavior.

Signed-off-by: Joel Nider <joel@nider.org>
JOEL4: remove 'a' flag to compile with optimizations

A stray 'a' from a copied code example has led to a compilation error under
optimizations (O1 and higher). I'm still not sure why this caused a problem,
and why it wasn't seen with O0, but removing the 'a' fixes the problem.

Signed-off-by: Joel Nider <joel@nider.org>
JOEL4: O1 is now the default otimization level

Until now, the kernel was always built with O0 because of two compilation
bugs that prevented compilation under O1.  Now those two bugs are fixed,
(LTR and LDT assembler syntax bugs), the default optimization level will
now be O1.  O0 can still be used by passing DEBUG=y as a flag to make.

Signed-off-by: Joel Nider <joel@nider.org>
JOEL4: fix for LTR assembler syntax bug

When compiling with O1 and higher, the compiler emits an assembly sequence
that loads the task register (LTR) from a register rather than a memory location.
Since I was using a 32-bit value, the compiler naturally tried to load the LTR
from a 32-bit register.  However, the instruction can only load from 16-bit
register. Under O0 this was not seen because the memory syntax seems to be more
flexible, and the assembler was able to reference the memory as a 16-bit
location.

Signed-off-by: Joel Nider <joel@nider.org>
JOEL4: added some makefile documentation

Documenting the use of files.mk variables a bit better.  There is still a lot
more work to be done in this area.

Signed-off-by: Joel Nider <joel@nider.org>
JOEL4: beginning of support for dependency files

The first step to improving the make system. I am sick of having to clean and
rebuild all every time I touch a header file (which happens a lot right now
because of the number of inline functions).

Signed-off-by: Joel Nider <joel@nider.org>
JOEL4: not returning a value in taskListFindByID

The compiler should have caught this one. I was trying to return from a function
without returning a value. This caused an infinite loop while creating the root
task. I should probably add a check for this case in the createTask function
since this still may happen if all task ID's are really in use (not likely, but
the kernel should be able to detect this case.

Signed-off-by: Joel Nider <joel@nider.org>