I have heard that earlier PICs that are quite tiny are to be programmed using assembly and not C. Later PICs had hardware instructions to make them easy to be programmed via C language. However, I am not sure what this means.
Later PICs had hardware instructions to make them easy to be programmed via C language. However, I am not sure what this means.
Early PICs had limited memory and were quite slow so the code had to be small, efficient, and not waste precious RAM. It is possible to get close to assembler efficiency with a well-tuned C compiler by using various tricks, but with a small program it's often easier to just write it in assembler. With larger programs the advantages of C come to the fore (source code more compact and easier to read, more portable, better type checking, less chance of making silly errors etc.).
However early PICs also had hardware limitations that made it difficult for C compilers to produce good code, including:-
Strictly 8 bit operation. The default integer size in C is normally at least 16 bits. Using 16 bit integers wasted precious RAM and dramatically slowed down processing. C's poor handling of integer overflow can make working in 8 bits tricky.
No user stack. The stack on early PICs was only used for storing return addresses and could not be accessed by program code. This made local variables and re-entrant functions harder to implement and less efficient.
Very small return stack. Some early PICs only had a 2 level stack. This severely limited the ability to nest subroutines.
Limitation on code placement. Some PICs could only call subroutines in even 256 byte ROM pages (eg. on PIC12C508 all subroutines have to be placed in the first 256 bytes of ROM).
No interrupts. Some PICs had to do everything by polling, so cycle counting was the norm for getting accurate timing. This is not compatible with C, which cannot guarantee that code will use any specific number of cycles.
Inefficient access to data in ROM. The 'Table Read' instruction reads a data byte by doing a 'computed goto' to a 'RET N' instruction that returns the immediate data byte embedded in the instruction. This is slow, wastes ROM space and cannot cross a 256 byte page boundary.
Paged RAM and I/O register access. PIC12/16 chips often have several banks because there is not enough memory space for linear addressing. The compiler may not be able to determine which bank is currently selected at run time, so has to insert more bank switching instructions than might be necessary with carefully crafted machine code.
Define earlier. The 16F series is from the earlier days (20 years ago?) Back then we would write MP-ASM and C code, then I found a C++ compiler for it too.
It all depends on what you are writing and how efficient the compiler is for it. The Hi-Tech C compiler, which I believe Microchip purchased (the whole company), was pretty darned efficient, and made really small hex files. True, you can make smaller code by hand writing assembly, but then how long do you want to spend writing code vs. making the project as a whole?
Your title does not quite agree with the text, so I'll refer to the text.
It was possible to use a cross compiler even on the earliest PICs, but there were significant compromises in the C you could write and in the generated code. Hitech C (now owned by Microchip) supported even the tiniest PIC, as does XC8. The paged memory, limited stack and so on made it difficult to write much in the way of serious C. There are usually ways around some of the limitations but it's typically an unpleasant choice. Particularly when you have only 16 bytes of RAM total and only 256 words of program memory total (PIC10F200).
They added registers and some instructions to better support C, such as the ability to read constants from program memory.
I would put it a bit differently, you could either write, at most, a fairly trivial program in C for the tiniest micro (perhaps with a lot of head scratching to try to work around the compiler limitations) or you could use it as it was intended, in assembler and do some fairly interesting and complex things (though the lack of interrupts in the smaller PICs was a pain).
Later micros such PIC24 series were designed with the compiler requirements in mind so that emitted code could be reasonably efficient and come closer to standard C.
I've never heard that (and it doesn't sound like it makes sense to me - every turing-complete instruction set can be a target of C), but what I guess is that:
C is a language that uses functions that you can call, and return from. To enable that, many architectures use what is called a stack, ie. kind of a pile of memory on which every function can put their "working scrapbook" on top, and when it returns, it just "walks back" the height of the stack.
This can be very elegantly be used if your hardware has a special stack pointer register.
Another thing (I don't know whether that is the case for any of the multiple PIC instruction sets) is adding hardware "call the function at address X" instructions, which inherently saves the position from which we jumped into the function (typically on top of the stack), and another "return" instruction, which jumps back to the saved location.
However, if you don't have a hardware stack, and only very few registers, and limited RAM, then you're getting into trouble very quickly, because you simply always need to hold on to more data than you can. You might not be able to fit a C program that software-builds all the needed functionality into the program memory of one of the smallest PICs, either.
There are the older pics then the pic32 which is completely unrelated and is a mips core. Naturally MIPS C compilers exist. The older pics had C compilers as well, but the instruction sets are not very C friendly, and compiled code has some bulk to it (in general). End of the day it is up to you but a C compiler for the older pic12's etc never made sense to me, the best optimizer in the world would still be inefficient and the platform is so limited.
Or you can certainly take the path of compile first then hand tune the asm where desired/needed.