Electronic – Does any MPLAB compiler e.g XC8 have built in functions to control PIC peripherals like in CCS PIC C

Every RTOS for a PIC which does not have a software-addressable stack generally requires that all but one of the tasks must have its work divided into uninterruptable pieces which begin and end at the top stack level; the "task-yield" operation does not use a function call, but rather a sequence like

// This code is part of task C (assume for this example, there are tasks
// called A, B, C
  movlw JumpC4 & 255
  goto TASK_SWITCH_FROM_C
TargetC4:

Elsewhere in the code would be some code like:

TASK_SWITCH_FROM_A:
  movwf nextJumpA  // Save state of task C
  // Now dispatch next instruction for task A
  movlw TaskB_Table >> 8
  movwf PCLATH
  movf  nextJumpB,w
  movwf PCL
TASK_SWITCH_FROM_B:
  movwf nextJumpB  // Save state of task C
  // Now dispatch next instruction for task A
  movlw TaskC_Table >> 8
  movwf PCLATH
  movf  nextJumpC,w
  movwf PCL
TASK_SWITCH_FROM_C:
  movwf nextJumpC  // Save state of task C
  // Now dispatch next instruction for task A
  movlw TaskA_Table >> 8
  movwf PCLATH
  movf  nextJumpA,w
  movwf PCL

At the end of the code, for each task, there would be a jump table; each table would have to fit within a 256-word page (and could thus have a maximum of 256 jumps)

TaskC_Table:
JumpC0 : goto TargetC0
JumpC1 : goto TargetC1
JumpC2 : goto TargetC2
JumpC3 : goto TargetC3
JumpC4 : goto TargetC4
...etc.

Effectively, the movlw at the start of the task-switch sequence loads the W register with the LSB of the address of the instruction at JumpC4. The code at TASK_SWITCH_FROM_C would stash that value someplace, and then dispatch the code for task A. Later, after TASK_SWITCH_FROM_B is executed, the stored JumpC4 address would be reloaded into W and the system would jump to the instruction pointed to thereby. That instruction would be a goto TargetC4, which would in turn resume execution at the instruction following the task-switch sequence. Note that task switching doesn't use the stack at all.

If one wanted to do a task switch within a called function, it might be possible to do so if that function's call and return were handled in a manner similar to the above (one would probably have to wrap the function call in a special macro to force the proper code to be generated). Note that the compiler itself wouldn't be capable of generating code like the above. Instead, macros in the source code would generate directives in the assembly-language file. A program supplied by the RTOS vendor would read the assembly-language file, look for those directives, and generate the appropriate vectoring code.

All microcontrollers can be programmed in a C-like language, all of them have the same basic peripheral types and comparable cores as far as features go. When you stay within the realm of real-time MCUs, they are pretty easy to jump between.

Probably the biggest differences are simply in the idiosyncracies of the tools. If you are accustomed to the ease of having preprogrammed bootloaders in your AVRs (down to pre-programmed USB bootloaders in the -U parts), you may have some trouble with having to buy a compatible JTAG programmer for certain ARM chips. If you're accustomed to the rich debugging features of JTAG-enabled chips, it may be a bit of a culture shock to go back to in-bound debugging in low-end PICs and AVRs. But that's something you get used to after using a toolchain for a while. Also, with some chips there is quite a significant cost associated with using their tools, e.g. Freescale and Renesas.

Don't be afraid to choose a different chip once in a while and learn to work with it. It will broaden your view and enable you to use more optimal MCUs in the future

Addendum: this doesn't really apply when you go to non-realtime processors like the ARM A-series, x86 and Cell. These are very difficult to program for on a low level, tools are expensive and the chips are hard to get and implement.