Sergio, You make some very valid points. And that's all well and good. However, I have used several "C", "BASIC", "PASCAL", and other HLL's that while they keep track of important, but maybe somewhat elusive, details, I have found that typically, the output code is substaitially larger than when I write in assembler. I understand that the newer compilers are better at keeping bloat down, bit I still contend that assembler is more space efficient. And when you have only a few K words (or bytes) of memory to work with, you want to be as frugal as possible with them. And if the HLL's output code is larger than my assembler, why should I go to the trouble of buying it, learning It, and using it, just to save myself a little bit of trouble keeping track of resources the processor is using, and on top of that, having the code larger. Programming in assembler has some implications that come with it. One of those is that, you, as the programmer, are responsible for keeping track of information such as resource utilization. This includes thing such as register use, variable size(s), constant sizes, hardware peripheral usage, etc., etc. That comes with the territory. Granted, the HLL's do keep track of most of that for you, but I don't know if I'd say it's a worthwhile tradeoff for me. Also, in all of the HLL's I have used, when looking at the assembly listing file, the program jumps all over the place. I assume this is because of optomizations, memory utilization, etc. But to me, that is utterly ridiculus. There is no compelling reason to have the compiler output that way. At least I can't think of one anyway. So, I guess that brings us back to where we started. And that is that I prefer assembler. I think HLL's are the "Arcane" and "Cumbersome" code generating tools. They cost more money to buy. They have a learning curve that I have to ascend. They really aren't that efficient in memory use. And honestly, I tend to like keeping track of my variables, registers, and such. It gives me a good feeling when I'm done with some code to be able to fire up a project, and have it work like it was intended. It says that my tracking of the details of the program were spot on. Now, I'm not saying all my programs work right out of the hole. I, like anyone, have bugs in nearly every program I write. But I usually find the bugs in short order because most are simple typos. My fingers aren't as sleek and nimble as they once were. They are now fat, and clumsy most of the time. So, when I go back and fix the typos, assemble, program, run, and find I have a logic problem, I fix it in short order. And like Bob Axtell was saying, you can write the code, simulate it's operation to test functionality, and if not correct, you can fix it without leaving the IDE. The bottom line is I prefer assembler, with all the problems and glory that comes with it. I prefer not to use an HLL unless the customer dictates. However, if you or anyone else wants to use an HLL, then by all means don't let me disuade you. To use an HLL would be your preference. And who am I to tell you what you prefer? Or what you should prefer? Programming in general, and PIC programming in particular, should be carried out in whatever form pleases you or whatever you are comfortable with. For me, this happens to be assembler. For you, as well as many others, that is an HLL of some sort. I can respect that. Maybe at some point in the future, this viewpoint may change, but I doubt it. I have been working with PIC's since about 1990 or so. When I first started, Microchip offered 4 parts. And all you had was the free assembler that Microchip provided. I thought that was a great deal. Here it is going on 20 years later, and I still prefer assembler. Maybe it's because of all the years of doing without an HLL that has been ingrained into my head, so that now I am so used to assembler that I can't change or don't want to change. But with all the processor choices Microchip presents today, all the different languages available, with many different compilers supporting each of thos languages, it seems to me that virtually anybody can pick whatever form of tools for programming they desire or prefer, and go with those, and not affect anyone in the process. So, to each his own. For me, assembler. For you, an HLL. Everybody pick whatever suits you and start programming. There are billions of projects and products that haven't been built or even invented yet, So people get busy. I guess I'm done now because I'm tired. And I have to get back to work. And Sergio. Thanks for the list of benefits of HLL's, and for the opportunity for me to write and post my editorial. I really didn't plan on this longwinded soapbox speech, it just came out that way. If this offends anyone, I apologize. That was not my intent. Regards, Jim -----Original Message----- From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On Behalf Of sergio masci Sent: Tuesday, March 04, 2008 5:39 PM To: Microcontroller discussion list - Public. Subject: RE: [PIC] Mixing MPASM and C (Hi-Tech PICC) On Mon, 3 Mar 2008, PAUL James wrote: > > Rikard, > > I can't help you with your request, but you have brought up a point > that I have answered before. That is, you have come across something > that I have run into in the past. And it further justifies my opinion > that HLL's for the PIC series is not the big boon that they are made > out to be. I hear people often saying that the Microchip instruction > set is "Arcane" or "Cumbersome". However, I think it is just fine. I > think the HLL's Are the Arcane, Cumbersome ones. Therefore, I still > do most of my > programming in assembler. Only if the > Customer requests an HLL be used, do I depart from my norm of assembler. If you've been programming in assembler for a long time chances are that you'll have a lot of code hidden away somewhere which you can reuse in some way or other. Whether it is a set of subroutines, macros or just application code that you can cut and past I'll bet there is a lot of it. Over time you may even develop a style that lets you slot pieces together like building blocks - a protocol that spcifies how data is passed around between the subroutines and macros. With all this in place you will probably spend most of your time (while developing a new gadget) filling in the cracks between your building blocks and optimising bits of code all over the place. In effect you will spend more of your time optimising and debugging than writing new code. Why waste your time doing this - this is what a compiler does, and it can try lots of different combinations of optimisations each and every time you make the smallest change. It wont forget that a variable has changed from an 8 bit integer to a 16 bit integer at some obscure point in your code (e.g. when you are passing it to a macro). It wont complain at having to change everything just to squeeze one more byte out of your executable. A big problem that many assembler programmers seem to have with regards to using HLL is what they perceive to be the verbosity of the HLL source. They resent having to write lots of HLL source code that gets compiled down to maybe a trivial couple of machine code instructions. What they fail to understand is that the HLL is actually allowing them to tell the compiler things about the program that the assembler programmer cannot. In an assembler program a lot of info remains in the head of the programmer. The programmer may know that at a given point in the executable a register is being used as a loop counter but the assembler itself does not. Whereas in a HLL the compiler knows about loop counters, it knows about the code inside a loop, it knows if the loop counter is being used as an index. It knows how to perform optimisations based on all this information - and when the program get modified it knows how to compensate. The assembler programmer has to do all of this the hard way and possibly do a lot of testing to ensure that all the changes behave as expected. Yes you may need to write a lot more source code in a HLL to do something trivial BUT there is a lot less time spent filling in cracks and tracking down obscure bugs that arise due to a small code change. Regards Sergio Masci -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist