Why It is not recommended porting a OS to C51?

1. Preemption kills overlay analysis

Compile-time assignment of absolute addresses to "stack" variables is a big size and speed advantage, particulary on the 8051. However, it does have costs. Preemptive tasks would mean a separate call tree for each task which must exist separately. The benefit of this optimization is much reduced.

2. Stack architecture

As has been mentioned, managing a stack on the 8051 is awkward. The hardware stack is necessary for function calls -- its use is hardwired into the instructions, after all -- but it's only 128 bytes. That works out to 64 function calls. Divide that by 4 tasks, and you can only call 16 levels deep in each task, which isn't nearly as much as it sounds like for a complicated program. (And if your program isn't complicated, why do you need an OS to help manage it?)

I've seen a reference here to there to systems that try to move all the stack data back and forth on a task switch to try to collect the remaining free space in idata into one place for the benefit of the currently running task. Clever, but a big overhead on task switching.

Once most of the stack has to move to xdata, code to access that stack becomes much larger and slower.

3. Addressable program store

The 8051 has a 64KB address space. You can get more with code banking, certainly, but it's less efficient. This is another take on the "complexity" question. If the program is so big and complex that it needs an OS and hundreds of KB of code, is the 8051 really the right processor for you?

You often get a chain reaction that explodes code size. Your code gets larger so you add bank switching which makes you code yet larger which means you move more things to xdata, including the stack, which makes your code yet larger...

4. Poor support for indirection

There's only one DPTR. (Even if your variant has more than one, it's really still just one in the instruction set, with some means to swap various DPTRs into the "real" DPTR. The cost to swap DPTRs is often close to the cost just to reload the one.) Lack of pointer registers means the 8051 becomes poor at handling stacks (see 1). It also means it's relatively poor at handling multiple instances of structs, like task control blocks.

1. Preemption kills overlay analysis

Compile-time assignment of absolute addresses to "stack" variables is a big size and speed advantage, particulary on the 8051. However, it does have costs. Preemptive tasks would mean a separate call tree for each task which must exist separately. The benefit of this optimization is much reduced.

2. Stack architecture

As has been mentioned, managing a stack on the 8051 is awkward. The hardware stack is necessary for function calls -- its use is hardwired into the instructions, after all -- but it's only 128 bytes. That works out to 64 function calls. Divide that by 4 tasks, and you can only call 16 levels deep in each task, which isn't nearly as much as it sounds like for a complicated program. (And if your program isn't complicated, why do you need an OS to help manage it?)

I've seen a reference here to there to systems that try to move all the stack data back and forth on a task switch to try to collect the remaining free space in idata into one place for the benefit of the currently running task. Clever, but a big overhead on task switching.

Once most of the stack has to move to xdata, code to access that stack becomes much larger and slower.

3. Addressable program store

The 8051 has a 64KB address space. You can get more with code banking, certainly, but it's less efficient. This is another take on the "complexity" question. If the program is so big and complex that it needs an OS and hundreds of KB of code, is the 8051 really the right processor for you?

You often get a chain reaction that explodes code size. Your code gets larger so you add bank switching which makes you code yet larger which means you move more things to xdata, including the stack, which makes your code yet larger...

4. Poor support for indirection

There's only one DPTR. (Even if your variant has more than one, it's really still just one in the instruction set, with some means to swap various DPTRs into the "real" DPTR. The cost to swap DPTRs is often close to the cost just to reload the one.) Lack of pointer registers means the 8051 becomes poor at handling stacks (see 1). It also means it's relatively poor at handling multiple instances of structs, like task control blocks.