sergio masci wrote: > On Tue, 4 Mar 2008, PAUL James wrote: > > >> 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. >> > > I understand your concerns. Yes there are some awful compilers around that > generate tons of code but there are also some very good ones that generate > code that is on a par with a respectable assembler programmer. > > Some of these compilers can be used very effectively on PICs with meger > resources e.g. the 16F628 > > >> 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. >> > > Yes I understand your point. But what if the HLL's output code is on a par > with yours and it saves you a lot of time and effort. Would it not be > worthwhile then? I mean when it comes right down to it, when you're > working on a boring project for someone else, would you not rather finish > it quickly, and get back to your own pet project or other leasure activity > - or maybe just move on to another paid project and earn a little more > money? > > >> 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. >> > > Yes I know this only too well. I've been programming in assembler since I > was 16 and I've made my share of mistakes :-) > > >> 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. >> > > Actually depending on the processor and HLL you are using there might be. > > Some processors have limitations on the size of a jump or branch which > the compiler gets around by jumping to another jump that leads to the > destination. > > Some languages such as C have an "early out" mechanisum that allows the > outcome of a condition to be established before the entire condition has > been evaluated. These can end up looking like a rats nest of conditional > jumps but an assembler programmer would be forced to implement it the same > way. > > e.g > if ((a == b) && (d == e)) > > here if (a == b) is false there is no point evaluating (d == e) because > the outcome cannot be true. > > Also some compilers generate stubs for unknown code. In this situation a > compiler would point all jumps to these stubs and fill in the stubs > with the jump to the actual destination when it is discovered. > > >> 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. >> > > Actually my experience has been different. I have seen a lot of > respectable assembler source generated by compilers. It's hard to justify > taking 10 to 20 times longer to produce a program to your boss when others > using a HLL seem to be producing executables which seem as big and fast as > yours. > > >> They cost more money to buy. >> > > There are some that are available for free or not much more. > > >> They have a learning curve that I have to ascend. >> > > Yes but that can be fun in itself. > > >> They really aren't that efficient in memory use. >> > > That really depends on the HLL and the compiler. Some languages such as > PICBasic Pro are not structured and the compiler has a very hard time > trying to reuse memory. But other HLLs are superb. > > >> And honestly, I tend to like keeping track of my variables, >> registers, and such. >> > > Consider this: the XCSB compiler generates code that it runs through an > assembler. After each pass through the assembler the generated executable > is profiled and execution paths for EVERY instruction are generated. > Depending on these execution paths RAM paging and CODE banking > instructions are inserted at optimal places in the code. That's a hell of > a lot of book keeping work for a human to do. > > >> 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. >> > > I know how you feel and I would not want to take this away from you but > writing programs in a HLL can be just as rewarding. Honestly being > clever and solving complicated problems doesn't mean you need to > have bloodshot eyes. > > >> 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. >> > > I really don't wish to "tell" you what to do. I am just concerned that you > feel all HLLs and compilers are so bad. > > >> 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. >> > > I cannot see how what you have written could possibly offend anyone. I > respect your right to use whichever tools you choose to and to enjoy your > work. > > Keep up the good work. > > Another critical use of assembler is during an interrupt. While HLLs all offer interrupt code, the extra instructions generated by the compiler make the interrupt run much longer. Since when you are in interrupt mode, you cannot run mainline code, such extra instructions can mean the difference between a clean performance and a sluggish, muddy mess. --Bob Axtell -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist