what are differences hardware?

Anything that has short enough real time requirements can usually be handled by an interrupt, even with an RTOS.

Even if you don't have an RTOS, your code will contain critical sections that increase interrupt latency. Just because you write it all yourself doesn't mean the problems scheduling a complex set of tasks go away.

In my opinion, the 8051 is poorly suited to a preemptive scheduler. Weak stack handling and awkward access to xdata mean you have a pretty big premium on keeping the stack out of xdata. (And by "stack", I mean the usual C stack, not just the return values maintained by the 8051 hardware stack.)

The compile-time call tree analysis that Keil does also goes out the window if you have preemption. Every task will have to be the root of its own call tree, so you'll get less benefit out of the overlay analysis and need much more memory. (You can see this problem reflected in the design of Pumpkin's Salvo, where you can only switch context at the "top level" of your task, which is to say when the stack is back at the top and you don't have to worry about preserving the contents.) You'll also likely wind up needing more "reentrant" routines to share between the tasks. Each task, like an interrupt handler, will be its own context from the point of view of the call tree.

Anything that has short enough real time requirements can usually be handled by an interrupt, even with an RTOS.

Even if you don't have an RTOS, your code will contain critical sections that increase interrupt latency. Just because you write it all yourself doesn't mean the problems scheduling a complex set of tasks go away.

In my opinion, the 8051 is poorly suited to a preemptive scheduler. Weak stack handling and awkward access to xdata mean you have a pretty big premium on keeping the stack out of xdata. (And by "stack", I mean the usual C stack, not just the return values maintained by the 8051 hardware stack.)

The compile-time call tree analysis that Keil does also goes out the window if you have preemption. Every task will have to be the root of its own call tree, so you'll get less benefit out of the overlay analysis and need much more memory. (You can see this problem reflected in the design of Pumpkin's Salvo, where you can only switch context at the "top level" of your task, which is to say when the stack is back at the top and you don't have to worry about preserving the contents.) You'll also likely wind up needing more "reentrant" routines to share between the tasks. Each task, like an interrupt handler, will be its own context from the point of view of the call tree.

"...Pumpkin's Salvo, where you can only switch context at the 'top level' of your task..."

Don't know that one - is it really preemptive multitasking, or is it more like the "cooperative" multitasking of Win3.1?

To answer my own question:

http://www.pumpkininc.com/

And the very first line on p2 of http://www.pumpkininc.com/content/doc/press/salvoflyer.pdf says, "Cooperative, event-driven,..."