Why It is not recommended porting a OS to C51?

Yes,No body encouraged runing an OS on 51's architecture, But, I have to do it ,It's an order from my boss. I have no choice except trying my best to finish it,Then the final decision is up to the upper.

In fact, the whole architecture has several quirks that make it decidedly disadvantageous to run an OS on a '51.

Could u tell me what's the quirks? Thanks.

Yes,No body encouraged runing an OS on 51's architecture, But, I have to do it ,It's an order from my boss. I have no choice except trying my best to finish it,Then the final decision is up to the upper.

In fact, the whole architecture has several quirks that make it decidedly disadvantageous to run an OS on a '51.

Could u tell me what's the quirks? Thanks.

I have no choice except trying my best to finish it,Then the final decision is up to the upper.

Ah, the woes of the clueluess boss. Well, let's just hope you'll remember this episode when ever you get to the position to hand out assignments like this, and be prepared to accept technical feedback a little more openly than your boss appears to.

Could u tell me what's the quirks? Thanks.

In a nutshell: the stack is in the wrong memory space.

By consequence it's quite small, and near impossible to make any larger. This in turn practically forces C compilers to rely on static control flow analysis to allocate automatic variables and function arguments statically. Static control flow analysis and OS usage don't mix very well at all.

By the time workarounds for all this are in place, you end up with an 8051 emulating a CPU architecture crucially different from its own, and that wastes a lot of CPU resources.

But, I have to do it ,It's an order from my boss.

Ouch. Is he trying to torment you or does he just have no clue ? Or does he like wasting company resources (aka money) on wild goose chases ?

Porting an OS to the '51 is an economically unwise decision. Even if a manager doesn't understand the technical implementation, he should understand when he is wasting money.

If you succeed, you will need to use a '51 derivative that's more expensive than one that will do the job without an OS. It might even be more expensive than a chip of a different architecture that will run an OS without having to jump through major hoops.

I have no choice except trying my best to finish it

You have the choice to quit the job now, instead of being sent on a task which, at best, will waste your time and leave bad marks on your resume.

Could u tell me what's the quirks? Thanks.

The memory architecture ! The 8051 architecture is absolutely bad at doing context switches (which are what an operating system does).

Hey, All the guys here, I'd appreciate you so much! I think I have got the ideas from this lovely place.

For the working I am doing now , I'll finished and show my boss he was wrong, Tell him that's the question we have discussed before.

Anyway, You guys really give me a lot help. Thanks

Yes, Nobody encouraged runing an OS on 51's architecture, But, I have to do it ,It's an order from my boss.

This is one consulting I will do for free (1 hour max) have your boss e-mail me

Erik

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.