----- Original Message ----- From: Byron A Jeff To: Sent: Sunday, January 19, 2003 3:11 AM Subject: Re: [PIC]:Various laguages, which is right for me? > On Sat, Jan 18, 2003 at 04:06:31PM -0800, Aaron Moore wrote: [snip] > > Anyhow, my original plan was to use the MPLabs assembly > > language because it was free. However I do have some background in c++ > > programming, and wouldn't mind considering a basic or c based language. > > But I've heard that the c language has a lot of overhead, and doesn't > > make things much clearer. The overheads are not necessarily due to C, some things are just a pain to do on the 14 bit PIC cores. Try writing a macro to add two 32 bit integer variables together. Try moving data from one RAM page to another. Try searching a data table (16 bit integers) held in code space on a 16f628 or an 16f84. A good C compiler generates lots of code to do this because it's hard to do. But a good compiler constantly checks for all sorts of conditions that might result in a short cut - it is very difficult to do this yourself with macros in assembler. > > As with all projects, it depends on the task. Each of the three possibilities > has it's pros and cons: > > 1) Assembly: Pros: standard, free, lots of examples, efficient. Cons: can be > slower to develop, and harder to maintain. > 2) HLL (C, Basic, JAL) Pros: higher abstractive level simplifies development > Cons: can have code size and performance efficiency issues Yes. A crap compiler will generate crap code, however a good compiler will generate code that can be within 90% of that generated by an EXPERT assembler programmer (not a mediocre or novice programmer an expert). You pays your money you takes your choice. To put things in perspective a 10 instruction sequence produced by a compiler is 10% off the equivalent 9 instruction sequence produced by the expert. > 3) Hybrid Assembly/HLL Pros: Shortens the development cycle while allowing > for high performance bursts when required. Cons: requires understanding > both levels of development and profiling to understand where to recode. > Also you may still have resource issues. > > Which one to pick depends on the project. But the further I get along in > the process the more that I find it harder to "get it right" as opposed to > "get it efficient". So I'm starting to lean heavily towards HLLs because they > assist in helping "get it right." Yes I agree, however I've been arguing for a while now that an assembler with built-in high level code generation facilities gives better control over the generated code than a HLL with retrofitted control over the code generation. > > > > > > I'm also curious about JAL, and how/what that is, > > JAL is a Pascal like HLL for embedded systems project developement. It was > developed by our own Wouter van Ooijen and was recently released as GPLed > Open Source Software. It was a wide variety of user support libraries and > a large user base. In addition to standard HLL tools, JAL adds embedded > systems support such as bit variables and embedded assembly. Since JAL > compiles to native assembly it is both code space and execution efficient. Not to rain on Wouter's wonderful language but you should be aware that JAL only supports 8 bit unsigned integers directly. Also JAL is not the only compiler that generates directly executable optimised machine code. > > The beginning is a great time for you to experiment. Take a couple of very > small projects and try writing them in assembly and JAL. Then compare the > development process of the two. > Good advice. [snip] Regards Sergio Masci http://www.xcprod.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.