Ok, I understand what you meant by "stability" now. Unfortunatly this still does not follow. I learned this myself the hard way. About 12 years ago I bought a Watcom C/C++ compiler. Excellent compiler, very well respected and so too was the company. Large user base, good support, exactly what you are tallking about now. Along came a company called Powersoft, bought Watcom and very soon afterwards shutdown the compiler section. You couldn't buy the thing even if you throw cash at them. A few years later the compiler made its way into the open source domain where it is now limping along.
I understand your need for some kind or criteria to base your purchase on. It is the same for all of us. We all need to think of a way to identify what we should be spending our hard earned cash on or what we should be investing our time in. But size of user base is not it.
Ok, maybe picking a standard language like 'C' (so that if your tool vendor disapears you can move to another tool vendor) is the answer. Sure but only if you stick to the absolute standard specification of the language and don't use any of the compiler specific extensions or specialised libraries for which you do not have the source. I have been programming in C for a very long time, I have used many different compilers and I can tell you that porting an app between two compilers can be a real nightmare.
Ok, maybe picking 'C' because you want to learn 'C'. Fine but if you really just want to learn 'C' there are much better ways to do it than on a tiny embedded MCU. The GNU C compiler is free and so to is the debugger. An excellent way to learn 'C' and discover the pitfalls is to use these tools on a PC.
Ok, maybe picking 'C' because any program you write in 'C' is portable. So if you write a program for the PIC you can simply use it on an AVR? No things don't work this way. You need to put a lot of effort into writing a portable 'C' program especially for a small embedded MCU. Either you put a lot of effort in while you are developing your program and a little when you actually move it across, or you put a little effort in while you are developing your program and a lot when you actually move it across. Either way there is a lot of work involved in making the same program work on different embedded MCUs. Programming in C does not give you instant free portability.
It has library functions that read from and write to the USART. Some functions will operate on the USART directly others use FIFO buffering. There is no "printf" in XCSB because it is incredibly expensive. If you want to convert a 32 bit integer of floating point number to ASCII and then send it to the USART you would use the convert function followed by the write function. If you don't like this then you can write your own function to combine the two operations and be happy in the knowledge that the compiler will optimise this very well on your behalf. The real upside to all this is that XCSB will not "busy wait" while it is printing your formatted output, it will allow you to execute other tasks during this process (XCSB supports multitasking natively and not as an addon library).
Besides, what you are describing (the #use pragma) is a CCS 'C' extension. How would you port this code to (say) the HiTech 'C' compiler and get the same functionality without adding a lot more code yourself?
When I wrote the XCSB compiler it wasn't with the intention of writing another cheap BASIC or 'C' compiler. Or even to just create something that was easy to implement. It was with the intention of writing a compiler (that could be used by professionals) that would generate very efficient code for an embedded MCU. I wanted it to be easy to use and not have the 'C' free format pitfall. I tried to make it easy for both 'C' and BASIC programmers to use (staying clear of clever syntax and grammer). Unlike most C compilers XCSB uses a static run time stack. The positions of all the variables (including function locals and arguments) are calculated at compile time and not at run time, this means that they can be accessed directly without the need to calculate stack offsets at run time. The XCSB multitasking system takes all this into account generating task safe local variable and functions. With an addon multitasking library the user is often forced to jump through hoops to achive the same high level of run time performance.
Regards Sergio Masci