The piclist seems very quite regarding PIC topics lately so I thought I'd=20 try to add something interesting. Before we get bogged down into which is better assembler or high level=20 language consider how you would feel about a compiler that generates code=20 that is optimised beyond your wildest dreams. Imagin that you don't need to resort to sneaky tricks or hand crafted=20 assembler embedded in your high level code. That you don't need to=20 labouriously generate complicated tables in excel or matlab and then=20 painstakingly shoehorn them into you high level code. Imagin that you can=20 execute thousands of lines of complex code and have the result available=20 in the time it takes to execute a single machine cycle. And better still,=20 imagin you can do all this without having to learn some new complicated=20 language. Basically it comes down to this: the compiler executes as much user code=20 as possible during the compilation process and works out the bare minimum=20 that needs to be executed in the target. Most modern compilers can play=20 tricks with constants. They can convert complex expressions (that involve=20 only constants) into a simple constant result and use that result instead=20 of computing it at runtime on the target. Some compilers will even track=20 the way constants are used within variables and predict what is in a=20 variable at a given point in the executable. But what I propose is far=20 more complex than this. It involves allowing user functions to actually=20 take part in the generation of values which the compiler can then use as=20 constants. [ BTW executing code at compile time has a hidden benefit, in some case=20 you can use this to debug source code!!! But more of this later. ] This is one of the features of a new compiler I am writing for the PIC.=20 The language is very much like C but with a few extensions. It will be=20 very easy for C programmers to use involving minimal transition. It is=20 expected that the average C programmer will not need to fully understand=20 the the extensions in order to write highly efficent code using the new=20 compiler. It is also expected that non-C programmers will find the=20 extensions greatly beneficial and they will allow them to quickly=20 and easily start writing highly optimised code. The main new features that should be of most benefit to non-C programmers=20 will likely be the new intrinsic string data type, dynamic arrays and=20 dynamic structures. These greatly reduce the need for a heap and stack and= =20 will allows novice users to circumvent some of the biggest headaches they=20 normally encounter when starting to use C. These extensions do not impact=20 on the efficency of the generated target code. Another feature of this new language is 'mutable' types. This will allow=20 functions to taylor their behaviour depending on the actual types of=20 arguments passed to them and the result expected from them. A global variable can be declared as mutable and assigned a value returned= =20 by a function. That function can then perform some complex operation to=20 determin what the global should actually be (maybe a complex structure=20 depending on command line arguments provided at compile time) and return=20 it. The compiler can then use the complex structure, or parts of it, as=20 constants in the target. Functions within this new language are overloadable. Functions with=20 mutable arguments are not intended to replace function overloading but are= =20 an addition to it. In C function overloading is determined soley from the=20 arguments. This new language will also be use the return type to determin=20 overloading. Function can determin what type of value should be returned and in the case of a function having a mutable return type will be able to= =20 have multiple return points each providing a different type of result. During compile time execution the new intrinsic string data type are=20 dynamic objects and become static objects in the target. Effectively they=20 turn into standard C char arrays in the target but with the benefit that=20 their size does not need to be explicitly resereved until their use has=20 been decided. Because of their size attribute, the compiler is able to=20 track their use and detect many cases where indexing of their content=20 would go out of bounds (this would not be the case in char arrays=20 allocated a the heap). The added bonus of the intrinsic new string type is= =20 that copying and comparing strings and character arrays does not require=20 the use of the standard C functions such as strcpy and strcmp but instead=20 can now be handled much more naturely using the assignment and comparision= =20 operators Likewise during compile time execution arrays are dynamic objects and=20 become static objects in the target. As with strings, bound checking is=20 much easier for the compiler using dynamic arrays than using arrays=20 allocated from a heap. As already mentioned another feature of this new language is dynamic=20 structures. Their benefit is not immediately obvious. During compiler=20 execution of the code, structures can have members added or removed. The=20 behaviour can be thought of as similar to that of C's conditional=20 compilation using the '#if' preprocessor construct within a structure=20 declaration. But, unlike the C version, within this new language the=20 user's code can determin if an attribute is required. E.g. a user might=20 call an initalisation function (a library function) within their startup=20 code and this function determins if a particular feature needs to be=20 enabled. Within C (using conditional structure members) this would require= =20 the user "#define" some preprocessor symbol. This makes configuring and=20 using library functions much simpler for the users of this new language=20 while allowing the compiler to generate highly taylored and optimised=20 code. Furthermore, the decission to disallow conditional compilation through a=20 seperate preprocessor stage allows the compiler to much better detect=20 coding errors that would later result from some unforseen combination of=20 conditional compilation switches. Looking through "mature" code written in= =20 C that has been ported to multiple platforms will often show a rat's nest=20 of conditional compilation and will often have sections which have not=20 been maintained but are unusable should they ever be enabled. Previously I mentioned using the ability of the compiler to execute source= =20 code during compilation as a way to actually debug source code. This is=20 actually very easy to do by simply using the '?' operator anywhere in an=20 expression. The '?' operator is a unary operator (as is logical not '!')=20 and it can be used to print values during compile time execution. So if=20 you want to check that a function is producing what you expect you can=20 easily add a seperate global declaration and assign the result of the=20 function you are having problems with to the global. That gets the=20 compiler to execute the function and anywhere in there you can add some=20 '?' operators to see what the function is producing. I know this isn't=20 perfect but how many times have you wondered if a small snippet of code is= =20 actually doing what you expect. Now you can simply cut and past the=20 snippet into a function and try it. In the future I plan on having a third= =20 execution mode. This will run on a PC as a counterpart to the executable=20 running of the target. This wont be part of the compiler. It will run in=20 parallel to the target and you will be able to write all the code in one=20 place using the same language. The PC component will behave as one task=20 while the target will behave like another task. Your tasks will be able to= =20 commumicate with each other and you will be able to use this to debug your= =20 target. This PC counterpart is already mainly written as part of the=20 compiler execution core (the bit that executes the source code in the=20 compiler). It shouldn't be too much work to split it off. Work on this new compiler is well advanced and much of it is based on my=20 preceading XCSB compiler. XCSB already has very good optimisation for the=20 PIC (at least as good as the best available C compilers). I expect this=20 new compiler to show at least better optimisation for normal (100-1000=20 line or so) user programs and would be very surprised if it did not=20 provide ***HUGE*** gains for very large complex programs. BTW XCSB already has built-in multitasking. So, regarding the PIC, that's what I've been upto, what about you? Regards Sergio Masci --=20 http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .