Andrew, On Tue, 25 Jan 2005 14:21:40 -0800, Andrew Warren wrote: >...< > Be careful, Olin. Your preprocessor and macro library are getting > dangerously close to becoming one of those high-level languages that > you so strongly abhor. What's the reason you don't like PIC C > compilers? Oh, yeah... They insulate the programmer from seeing and > understanding exactly what's going on at the low level. LOL! I have seen places where instead of using the built-in features of the language they are using, they develop a whole language of their own which is supposed to make things easier. This is fine for the people who developed their meta-language and so know it off by heart, but it's a complete pain for newcomers. I advised my firm to avoid like the plague a system that they were considering taking on, that did a lot of accounting for foreign-exchange outlets, because it was written in the meta-language that the "not invented here" crew had designed. The net result was that it was unmaintainable by anyone who was not trained first in the underlying language, and then in the functions that this group of clowns had made up. So instead of saying: PRINT "Hello World" you had to do something like: NewPage = 0 NewLine = 1 Font = 0 FontSize = 0 PrintLines = 1 TextLine(1) = "Hello World" CALL PRINTTEXT and I'm not exagerating, it really was that bad (they didn't even let you pass parameters to the module, you had to set them up on advance). They seemed to think it was quicker and easier to do this sort of thing, for some strange reason! Now I'm not saying Olin's preprocessor is like this - I haven't looked at it closely enough to comment - but there is a tendency to do the sort of thing which can (when taken to extremes) be counter-productive to almost anyone except the inventor. > Wait. Are you saying that CBLOCK isn't portable across processors > because I have to change one constant in my source file, but RES is > portable because SOMEONE ELSE changed one constant in a separate > linker file? Yes, but it's done once, already, and doesn't need to be changed, ever! And if you are using all the memory in a chip with lots of banking and SFRs scattered around the memory map, you need a number of CBLOCKs to cover the ground, and they'd all need to be rehashed for any change of processor. Which means you'd need to keep a number of different versions of the source code, each having to be maintained into the future, one for each target processor. I think Olin's point is that you can reuse the same program on a multitude of different processors by recompiling/linking, without having to even look into the source code. If you only ever use one processor type for each program (which using absolute mode encourages by making it awkward to do otherwise) then this is a non-issue, but with MChip coming out with new processors at the rate they do (the 18F452 is "mature" already? I haven't even started using it yet! :-) and with different memory-maps which seem to depend on the phase of the Moon when the designers made the decision (!), having the program source as processor-independant as possible is a Good Thing! >> the symbols defined with RES only refer to RAM locations. > Except in absolute mode, where the symbols defined with RES refer to > EVERYTHING BUT those RAM locations... But I know what you mean. I don't understand this - could you explain? > > Symbols defined with EQU and CBLOCK are just ordinary constant with no > > inherent connection to RAM locations. > > Correct... But I guess I don't see that the distinction is > particularly important. Then you are out of touch with newbies to programming, or old-hands at high level languages who are only just starting in assembler languages. To them, the distinction between data values, addresses, pointers and compile-time constants is confusing enough as it is - trying to say there is no difference is going to really confuse a lot of people who are trying to learn and understand. There may not be a difference in the way they are defined, but understanding differences in their use is vital and non-intuitive. >...< > c) What's the big deal, anyway? Symbol naming is done once per > program; once symbols are defined, they're USED the same way > whether they're EQUs, #DEFINEs, or RESes. If errors aren't found > by the assembler (most are), they'll be found by a one-time look > at the .LST file. Symbols defined once are fixed - any change to the environment, or indeed to the program, may make them need to be changed, and you are advocating doing this by hand. Minimising the work to do this (especially eliminating the need all together) makes maintaining and enhancing a program, or porting it to another environment, easier, quicker, and much less prone to introducing bugs. And it reduces the amount of regression testing needed (although not eliminating it, of course!). > d) Choosing the correct RES section-names is just as error-prone as > choosing the correct CBLOCK initial values, anyway. Only once - the first clean run proves it's OK with RES, but with CBLOCKs you have an ongoing possibility of bugs being introduced. >...< > The arguments posted to the list that compare your full-blown > relocatable-mode development environment to "baby" absolute mode > (that is, to absolute mode unassisted by macros, include files, or > directives with symbolic parameters) are missing the point. What > experienced PIC programmer, for instance, would write this? > > VAR1 EQU 0x07 ; NOTE: To port this from the C54 to the C57, > VAR2 EQU 0x08 ; you'll need to renumber starting from 8. > VAR3 EQU 0x09 ; Start at 0x0C for the F84, from 0x20 for... > ; etc. > > I don't know anyone who would, but I frequently see crap like that > offered up on the list as an example of what's wrong with absolute > mode. Do you regard helping people understand your code as a bad thing? If you're writing absolute, explaining what's going on would seem to be more important when it needs to be changed. Or do you expect everyone to have memorised the memory maps of every processor, so they don't need any help? >...< > The difference, as I was saying, is that I > don't see a strong distinction and you do. Which is fine, of > course... Vive la difference... But when I see adjectives like > "boneheaded" and "irresponsible" applied to the way I wrote all my > PIC code, it's hard for me to restrain myself from replying. Likewise when it appears that you don't "get it"... I suspect that you have written your PIC code yourself, with nobody having to follow up and change your programs (and vice-versa with you tweaking others' programs) and perhaps for dedicated projects where the choice of processor was fixed and unchanging. Otherwise I can't see why you don't understand the idea of reducing the maintenance load. I used to tell my programming teams: "Almost every program has much more time spent on it being read, than being written. If you save yourself ten seconds typing when you write it, but cost other people 30 seconds later trying to understand what you did, then you have done a bad job, and I will be down on you like ton of bricks, after which you will have to do it again, the right way. So do it right first time!". This was in an environment of writing and then supporting commercial systems which were subject to changes and development throughout their lives, for a multitude of reasons. Perhaps you come from an environment where "write-only" programs were the norm, but I don't think that's a good way to train newbies to work! Cheers, Howard Winter St.Albans, England -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist