I changed this back to [PIC] tag since it does seem to be relevant to PICs in useful ways. phil B wrote: > This is a somewhat false economy. When the program > remains small, it works well but when the program > spills into a second bank or page or what ever, the > cost of inter bank/page/whatever accesses is fairly > high in program size, execution speed and especially > complexity. I don't know what you call "fairly high" of course, but I don't think banking/paging add that much to my 14 bit core programs over 2K words and that use multiple banks. Let's start with banking. Most of the 14 bit banked PICs have global memory in the last 16 locations of each bank. I find that reserving these mostly for temporary scratch values that get banged around a lot, and using banked memory for persistent state works well. My REG0 - REG12 "general registers" are in this memory, and can therefore always be accesses without regard to the bank setting. That, together with good modularization and semi-automation of bank setting with macros (see DBANKIF and related macros in STD.INS.ASPIC at http://www.embedinc.com) make banking quite manageable in my opinion. The cost in program size is genarlly not that great. I can't offer any figures other than a general feeling right now. An interesting test would be to take a nearly full 8K 16F project and count the number of BSF/BCF instructions to RP0/RP1 in the HEX file. I haven't done this and I'm not sure when I'll get around to it, but it would be interesting to have a quantitative value. I can supply a HEX file for a pretty crammed 16F876 project if anyone else wants to try this. I'm guessing the overhead is around 5%, and would be real surprised if it exceeded 10%, but of course this is just speculation. Execution speed would be pretty much related to the increase in program size as a first pass estimate. It is probably a little less because the speed critical accesses in loops and the like are likely to be optimized to unbanked memory or with the bank setting outside the loop. As for complexity, I totally disagree that it is "fairly high". This can be managed "fairly painlessly" in my opinion with good programming discipline and facilities like the DBANKIF macro. As for paging, I think this is even less of an issue. Just comparing a banked to an unbanked call can lead to the impression of enormous overhead (up to 5 instructions versus 1). However, proper modular design puts this overhead at the boundaries between subsystems where the links are fewer and the speed dependence is often not as great. 2K words is a large chunk of logic you can stay within without dealing with paging. As for complexity, I don't see the argument at all. With macros like GCALL and GJUMP, the complexity presented to the programmer is virtually none. Writing GCALL instead of MCALL (see STD.INS.ASPIC again) is not complex by any common definition. About the only complexity is remembering to do it, but the tools will find local calls that should be global calls as undefined symbols or missing externals. > I sure do fuss with rp0 and rp1 a LOT, You really shouldn't be fussing with it directly at all. See DBANKIF. > I bet an incredible about of effort > is spent on this issue, especially tracking down > elusive bugs. Banking bugs are frankly quite rare in my code, and I don't remember a paging issue in years. Yes, it is possible to write undisciplined code where banking is a constant and error-prone issue. So don't do that. It's not fair to indict an architecture because it's easy to write bad code. You should look at how easy it is to write good code with proper tools and discipline. > This false > economy gets relearned every few years in the computer > industry since the introduction of the first > commercial computer. This kind of attitude pisses me off. Someone sitting on the sidelines sees something that appears stupid and immediately declares it stupid without further investigation. If multiple experts have repeatedly and independently come up with similar answers, then just maybe they know something the casual observer doesn't. This doesn't guarantee it isn't in fact stupid, but one should not conclude that without examination of all the tradeoffs and constraints that applied. In this case you are only berating the negative aspects of address segmentation without examining its advantages. Everything is a tradeoff, which is a corollary to there is no free lunch. > The manufacturer usually > stresses upward compatibility and thus doesn't bite > the bullet in making the architecture tuned for larger > programs. Again you are making an implicity assumption that changing the architecture is inherently better without examining the tradeoffs. In Microchip's case they do have multiple architectures, so I'm not sure what you are complaining about. You can make your own tradeoff with size, cost, speed, segmentation of memory, and a whole host of other parameters. > Intel got smart and junked > the 286, introducing the flat and linear 80386. Actually the 386 is an extension of the same architecture. Segments were expanded from 16 bit addresses to 32 bit addresses, making them infinitely big for the usage at the time. In a few years when 48 or 64 bit architectures are common, are you going to complain that Intel didn't "bite the bullet" and go to 64 bit segments in the mid 1980s when the 386 came out? > In the end, > memory size was not at all a limiting cost so all that > effort turned out to be wasted. The key phrase is "in the end". Back when the 8086 came out a few Kbytes cost more than the processor. When the 80386 came out a few Mbytes cost more than the processor. Now we're up to 1 Gbyte about the same as the processor. It shouldn't be surprising that a 100,000:1 change in the processor to memory cost ratio would lead to different architectures. How much extra would you pay for a processor now that can address memory you won't be able to get or afford for another 10 years? ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist