Why It is not recommended porting a OS to C51?

It can be done (I have seen it). It is a huge drain on resourses. RAM, ROM, and CPU cycles.
The way the 8051 stack and pointer handling are to blame.
You can not just save the stack pointer, and set a new task stack. The stack is too small and maxes out at less han 256 bytes. So the compiler makes a software stack. It has much more overhead. The task switch time is slower, so you will have less switches per second.

It can be done (I have seen it). It is a huge drain on resourses. RAM, ROM, and CPU cycles.

Hi,I am so glad to know there are some "products" about this point , Could u tell me the type of the C51, or some informations about the resources,such as the RAM, the speed, the run-time behaviour and others.

The way the 8051 stack and pointer handling are to blame.
You can not just save the stack pointer, and set a new task stack. The stack is too small and maxes out at less han 256 bytes. So the compiler makes a software stack. It has much more overhead. The task switch time is slower, so you will have less switches per second.

Thanks for your advices, you're right,we should set it less switches per second.

Why It is not recommended porting a OS(ucos) to c51?

Because the 8051 was not designed to run an operating system. In fact, the whole architecture has several quirks that make it decidedly disadvantageous to run an OS on a '51.

If I have a enhanced fast C51, and there is about 5~7K RAM, It's about two/three clocks per machine cycle working on 40Mhz, which means about 50ns for single-cycle instruction, Is it powerful enough for a OS?

That's not the question, at least not in any kind of commercial application. For the price of that enhanced fast C51 you can get a different processor which will run an operating system without any additional effort, or you'll be able to get a C51 that can do the same job (minus the operating system) for half the price.

Unless it's for educational or academic purposes, running an OS on a '51 does not make sense.

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).

It was not a "Product" In the end a science experiment.
It was a 6 clock phillips "RD" CPU 12 Mhz I think.
It the programmer wanted to learn RTOS. The code base was used in a bigger CPU in an expanded project. It works well there.
The 8052 was losing time with 4 tasks. The switch time had to be slowed down a lot to fix it.
The switch time is Key here. A 1ms switch time on a 2ms clock means 50% of the time is wasted. With a 10 ms clock only 10% is wasted. Does it matter in your project? That is for you to decide. In the end you will need More RAM, ROM, and a faster CPU to get equivilent performance. You may have better luck with Keils O/S. It is smaller, but I have not used it.

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.