Olin Lathrop wrote (I'm combining comments from multiple posts): > This is exactly what I do in my PIC development environment at > http://www.embedinc.com/pic. Each module generally has an LBANK > constant that defines which bank is used for local state within that > module. LBANK is used to derive LBANKADR, which is an address within > that bank. LBANKADR is passed to the DEFRAM macro to define RAM in the > selected bank, and is also passed to the DBANKIF macro in the run time > code to set the bank appropriately for access to the local state. > There are a few more details .... 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. > With CBLOCK, details about the particular processor, like where RAM > starts, appears in the source code. When using RES, these details > appear in pre-written linker files unique to each PIC. To rebuild for > a different PIC, you use a different linker file but don't have to go > and change the starting address of variables anywhere in the code. 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? > I created the /FLAG directive in my preprocessor. You write one line > of code .... and it automatically allocates the next bit in registers > names GFL0 - GFLn and defines several symbols: > > flag_happy - String substition for use with BCF/BSF as above > flag_happy_regn - 0-N number of the GFLn variable containing flag > flag_happy_reg - Address of the GFLn variable containing flag > flag_happy_bit - 0-7 bit number within GFLn variable Of course, you could do the same thing with a set of macros using #DEFINE and EQU. > 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. > 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. Sure, RES (used correctly, and with the appropriate .name section identifiers) keeps an inattentive or inexperienced programmer from accidentally locating his variables on top of SFRs or at locations that don't exist... But: a) CBLOCK and EQU, used with section identifiers no more complicated than the .name parameters, can do the same thing. b) If we're allowed to use a preprocessor, you could easily write one that did all the fancy things your current one does, but didn't use a single RES statement and even -- gasp! -- produced absolute-mode source as its output... Without constraining the user in any of the ways that you believe directly writing absolute-mode code does. 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. d) Choosing the correct RES section-names is just as error-prone as choosing the correct CBLOCK initial values, anyway. > Encouraging people to use absolute mode, or even just making it appear > OK is doing them a serious disservice. Note that I'm NOT making an argument in favor of absolute mode over relocatable mode. Absolute-mode code paid for my house and some fast cars in a previous life, so I guess I have a certain fondness for it, but I honestly don't care whether anyone else uses it. Besides, I have only minor issues with using relocatable mode; my feelings about it are CERTAINLY less strong than yours about using absolute mode. My point in all of this is simply that there's NOT MUCH DIFFERENCE between using absolute mode and using relocatable mode. With a preprocessor similar to yours (or just a good set of hard-to-write-but-easy-to-use macros, and programming conventions no more strict than those imposed by relocatable mode), absolute mode can be more-or-less equivalent to relocatable. 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. Oh, well. As I've said before, the fundamental difference between us ISN'T that I'm an evangelist for absolute mode while you believe relocatable mode is the One True Way. Rather, it's that I just don't see much of a distinction between the two modes, while you have no clue what the hell you're talking about, you pinhead. Err, that was just a test to see if you managed to grind all the way through this long post. 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. -Andy === Andrew Warren - aiw@cypress.com === Principal Design Engineer === Cypress Semiconductor Corporation === (but open to offers) === === Opinions expressed above do not === necessarily represent those of === Cypress Semiconductor Corporation -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist