Context switching is one way to implement multitasking. The other popular method is co-operative tasking. In co-operative tasking each task has a time slice and must complete it's work within that time slice so that another task may execute. Most of my products have a common set of tasks:
1/ Communications. This task gets activated when a data packet is received. The serial interrupt takes care of the receiving this data. The communications task checks the recv packet, processes the request and creates a reply packet.The transmit data is handled by interrupt.
2/ i/o. most of my i/o is check switch inputs and turning relays on/off. Therefore this does no have to be done too quickly. This task executes every 100mS.

3/ user interface. This is the lowest priority task, as we done care if the user has to wait another 10mS or so. This would normally update the lcd.

To implement this is very easy and code efficient.

Have a timer interrupt set a flag every 10mS (or whatever time you choose). This value sets the time slice for the tasks.

have a dispatch routine that waits for the timer flag to be set, reset it, then check the task flags for the highest priority task. When found, reset that task's task bit and jump to that task.
When that task returns, go back to the top of the dispatch routine. The process runs again.

You can implement task timers to schedule tasks to run at regular intervals. At the top of the dispatch routine, decrement a variable (task timer) for each task, if that variable goes to zero, set it's task bit. The task reloads it's task timer variable when it has finished it's processing.

This code can be implemented easily in 'c' or assembler. It chews up only about 500bytes in 'c' or about 100 bytes in assembler. Other benefits are that you don't need to protect variables shared between tasks (as only one task runs at a time, and runs to completion), with context switching, a context switch may occur at any time during a task's execution, so you need to protect shared variables (this is similar to what you must do with interrupt routines). Also there is only one stack and again only one task runs and runs to completion so your overall stack size is small.

Downsides: one task can hog the cpu. If programmed correctly this is not an issue. The basic rule is that one task is not allowed to hog the cpu, it has a time slice and must finish within that time.

The time when a task actually executes can vary depending on what other higher priority tasks need to run. In most instances this is not too much of an issue.

A different approach to writing you code needs to be adopted as each task has it's time slice in which to work. If the required task takes longer than this time slice, it needs to be split up. State machines would be used here.

Windows implements a form of co-operative tasking using an event queue. An event is read from the queue and the required code runs to process that event. Then it's back to the event queue. If any of the event code doesn't finish in a reasonable time (ie ASAP) the user interface grinds to a halt!

So, if you can accept the limitations of the co-operative method, you can write a very efficient application, easily, that gives the appearance of a context switching system. An interesting item to note is that a lot of automotive fuel injection systems use the co-operative technique for their processing. Obviously the time critical things are done by interrupts but the general processing is done co-operatively. Hopefully this gives you some food for thought.