Re: New GCC compiler for 8086 cpu's

[Alan Cox <gnomes@lxorguk.ukuu.org.uk>]

> A simple solution for the kernel stacks is to use the user stack in
> kernel mode, this is:
> 
> DS = ES = Kernel segment
> SS = User data segment.

DS != SS requires far pointers.

Think about

	char x[40];
	char *p = x;


p now points to SS:something which is not the same as DS:something.

> Of course, this leads to problems. And the current kernel will require
> very careful inspection and corrections. But I think this is doable by
> enforcing some simple rules.
> 
> What do you think?

It doesn't work because you can take the address of a stack based object,
and not only that the compiler will do so itself internally when
generating code.

So to fix the stack you need a per process store for stacks and to do
something on task switch akin to


switch:
	while nothing else to run
		idle();
	if we are now the only/next thing to run (usual case)
		return;
	save our kernel stack somewhere
	(asm code to set ds: es: rep movs restore)
	change task
	load new kernel stack
	(ditto)

Note btw you can't use prefixes with rep movs on 8086 because there is a
CPU errata that a restarted rep instruction sometimes forgets the
prefixes!

The fancier version is to hash processes by stack (so say slots 1,5,9,13
use stack 0, 2,6,10,14, stack 1 .. etc). You have to keep the stack you
use for a given process constant but you can attempt to make sure that
usually a switch doesn't cause a copy in or out of stacks.

It turns out that on a small single user machine in particular the number
of task switches between tasks is miniscule. From the shell you switch
once to the app, once back to wait(), then back to the app and probably
don't switch again to anything but idle state unless the user changes
console, exits the program or runs a sub process. Now and then cron or
similar will briefly juggle things around but that's about it.

Fuzix uses the simple algorithm above on many platforms for the same
reason and it work extremely well even on a 4MHz Z80.

Alan