Post by thread:17C5X (was thanks... 0402)

>> To avoid the off-topic, have you seen the new 17C5X family member? >> 16K-word ROM, 33MHZ, "Elec. products" says it'll be priced at 13.98 for >> thousands, prod. starting on June. Oops, I should have said $13.28. John Payson wrote: >[1] A reasonable-sized area which is common to all memory banks. >[2] Seperate bank-select bits for direct and indirect access. >Maybe I'm being too negative since I haven't even seen the parts yet, but >bank switching with such huge blocks is really a pain and I think there's >no good reason for it. IMHO, Microchip should have placed the banked-vs- >unbanked boundary at $80; having the page chunks be 128 bytes would be no >less convenient than having them be 224 bytes as they are now, but then >the common area would be large enough to keep most programs' scalar >variables. I think it may be more convenient to have bigger pages, as it is done now. If your program needs more than one page of RAM you can divide it so as to keep the code of different pages connected as scarcely as possible. Smaller pages would mean more divisions and more bank switching. I understand you're saying that the pages are too big to even think of this, but on the other hand I guess about 100 bytes may not be enough, and if your using this chip instead of a cheaper one you might have lots of code. My point is that I don't find bank-switching that problematic and I'd consider the trade-offs. But I agree with you on the separate bank bits, I wonder if there's a reason (maybe at the circuit-level) for not doing it that way. Peter F. Klammer wrote: > MICROCHIP, ARE YOU LISTENING!!? > ``The salient features of Extended Indirect Mode are: > 1. Full upward compatibility with existing PIC17C4X binary code. > 2. Single-cycle access to contiguous linearly-addressable RAM via > indirect addressing. > 3. Single-cycle any-bank-to-any-bank RAM copy (MOV INDR0,INDR1). > 4. A bank-selectable 224-byte RAM context (1Ch through FFh in any bank).'' But the implementation of this seems (to me, just an observer) far from trivial at the circuit-level. You would need a new bus for the FSRs' higher bits, the FSRs would need added circuitry apart from doubling their size, and you would have to add a new MUX before the register address latch. If I was microchip I think I'd rather use my resources to do diverse faster and cheaper micros with more memory and peripherals, instead of doing all this work just to save some programmers' work and perhaps make a certain kind of code run a little faster. After all, isn't that the way they're products are positioned? The simplicity of the scheme (from a hardware point of view) might be one of various things that allow the high speed and low price we expect from a PIC. > If you want to do any kind of > inter-bank processing, with some data in RAM bank 0 and some in RAM bank > 1, guess how many bytes of program variables you can have for your > sophisticated algorithm? JUST SIX BYTES (less the one to save BSR, less > any other interrupt saves, etc.). I don't use 17CXX yet but I'm sure you can use banked registers too! Can't you do something like: MOVPF BSR,unbanked MOVLB ISRbank .... use all the registers you need MOVLB anotherBank or MOVPF W,BSR .... access another bank MOVLB ISRbank .... go on, close a loop, etc ? Regards, Andres Djordjalian spam_OUTadjordjTakeThisOuTaleph.fi.uba.ar

{Quote hidden}> >[1] A reasonable-sized area which is common to all memory banks. > >[2] Seperate bank-select bits for direct and indirect access. > >Maybe I'm being too negative since I haven't even seen the parts yet, but > >bank switching with such huge blocks is really a pain and I think there's > >no good reason for it. IMHO, Microchip should have placed the banked-vs- > >unbanked boundary at $80; having the page chunks be 128 bytes would be no > >less convenient than having them be 224 bytes as they are now, but then > >the common area would be large enough to keep most programs' scalar > >variables. > > I think it may be more convenient to have bigger pages, as it is > done now. If your program needs more than one page of RAM you can divide > it so as to keep the code of different pages connected as scarcely as > possible. Smaller pages would mean more divisions and more bank > switching. I understand you're saying that the pages are too big to even > think of this, but on the other hand I guess about 100 bytes may not be > enough, and if your using this chip instead of a cheaper one you > might have lots of code. My point is that I don't find bank-switching that > problematic and I'd consider the trade-offs. But I agree with you on the > separate bank bits, I wonder if there's a reason (maybe at the > circuit-level) for not doing it that way. While there are certainly exceptions to any rule, most programs that need a lot of RAM need it for arrays or other such constructs. Given that any array access has some associated setup work anyhow, having to deal with array banks isn't a big deal. For simple variables, however, it's nice to simply *ignore* bank-switching and related concepts. If 96 bytes' worth of registers are non-banked, then the vast majority of applications--even those which use up hundreds of bytes worth of arrays--will be able to handle all their non-array needs without bank-switching. Further, even for programs that do need large arrays [bigger than 128 bytes] the overhead of selecting the appropriate 128-byte page is really not severe. In fact, with arrays that span pages it's probably easier to deal with 128-byte pages (power of two) than 224-byte pages (not a power of two). For example, suppose ArrayH:ArrayL is a two-byte pointer to a logical address within banked memory. Then to access the value at ArrayH:ArrayL: [16Cxx'ish code] rlf ArrayL,w rlf ArrayH,w movwf Bank movfp ArrayL,FSR0 bsf FSR0,7 ... now accesses to FSR will go to the proper spot. Note that ArrayH:ArrayL can point anywhere in banked memory, and that the pair may be operated upon as a 16-bit pointer into contiguous memory space. To increment the pointer in FSR, use infsnz FSR0 incf Bank bsf FSR0,7 While I suppose that there may be some cases where an array is between 128 and 224 bytes in size where the larger pages would be helpful, I don't think I personally have encountered such situations but I know I've encountered the reverse. {Quote hidden}> > MICROCHIP, ARE YOU LISTENING!!? > > ``The salient features of Extended Indirect Mode are: > > 1. Full upward compatibility with existing PIC17C4X binary code. > > 2. Single-cycle access to contiguous linearly-addressable RAM via > > indirect addressing. > > 3. Single-cycle any-bank-to-any-bank RAM copy (MOV INDR0,INDR1). > > 4. A bank-selectable 224-byte RAM context (1Ch through FFh in any bank).'' > > But the implementation of this seems (to me, just an observer) far from > trivial at the circuit-level. You would need a new bus for the FSRs' > higher bits, the FSRs would need added circuitry apart from doubling their > size, and you would have to add a new MUX before the register address > latch. I agree that a "nice" implementation (like a BANKFSR register) would probably have added a little silicon; IMHO the benefits from being able to truly bank the IND's would probably be worth it. Certainly, though, while we can debate about the exact best size for the banked/unbanked split I hope you will agree with me that there oughta be more than SIX unbanked registers? > If I was microchip I think I'd rather use my resources to do diverse > faster and cheaper micros with more memory and peripherals, instead of > doing all this work just to save some programmers' work and perhaps make a > certain kind of code run a little faster. After all, isn't that the way > they're products are positioned? The simplicity of the scheme (from a > hardware point of view) might be one of various things that allow the high > speed and low price we expect from a PIC. Your point is certainly important. There's a diference, I think, between design decisions which trade complexity for programming convenience, and those which improve programmer convenience without much cost whatsoever. I think placing the bank split in a better place would have fallen in the latter category. My choice of 128 was intended both as a compromise between large bank/small blank options, and also one which would allow reasonably convenient accessing across pages. {Quote hidden}> > If you want to do any kind of > > inter-bank processing, with some data in RAM bank 0 and some in RAM bank > > 1, guess how many bytes of program variables you can have for your > > sophisticated algorithm? JUST SIX BYTES (less the one to save BSR, less > > any other interrupt saves, etc.). > > I don't use 17CXX yet but I'm sure you can use banked registers too! Can't > you do something like: > > MOVPF BSR,unbanked > MOVLB ISRbank > .... use all the registers you need > MOVLB anotherBank or MOVPF W,BSR > .... access another bank > MOVLB ISRbank > .... go on, close a loop, etc ? Certainly this is possible, which is why I said the 17Cxx give five general-purpose unbanked registers (you have to give up one to hold the BSR before you can put something useful into it). On the other hand, this is of course spending two cycles per interrupt which would in many applications not have to be spent if the unbanked region were larger. Personally, I rather liked the 16CXX memory map (with seperate IRP and RP0/RP1 bits) as well as the reasonably decent bank-shared region on the 16C924 [16 bytes]. It's too bad Microchip couldn't have kept these advantages on the 17Cxx.

> From: Andres Djordjalian <.....adjordjKILLspam@spam@ALEPH.FI.UBA.AR> > To: PICLISTKILLspamMITVMA.MIT.EDU > Subject: 17C5X (was thanks... 0402) > Date: Thursday, 22 May 1997 11:45 > Peter F. Klammer wrote: > > > MICROCHIP, ARE YOU LISTENING!!? > > ``The salient features of Extended Indirect Mode are: > > 1. Full upward compatibility with existing PIC17C4X binary code. > > 2. Single-cycle access to contiguous linearly-addressable RAM via > > indirect addressing. > > 3. Single-cycle any-bank-to-any-bank RAM copy (MOV INDR0,INDR1). > > 4. A bank-selectable 224-byte RAM context (1Ch through FFh in any bank).'' > > But the implementation of this seems (to me, just an observer) far from > trivial at the circuit-level. You would need a new bus for the FSRs' > higher bits, the FSRs would need added circuitry apart from doubling their > size, and you would have to add a new MUX before the register address > latch. It *is* an upper-end processor, and yet doesn't approach the number of transistors Pentiums have. (thank ghu!) A little more complexity in the FSR circuitry would be A Good Thing. > > If I was microchip I think I'd rather use my resources to do diverse > faster and cheaper micros with more memory and peripherals, instead of > doing all this work just to save some programmers' work and perhaps make a > certain kind of code run a little faster. After all, isn't that the way > they're products are positioned? The simplicity of the scheme (from a > hardware point of view) might be one of various things that allow the high > speed and low price we expect from a PIC. > This is the kind of thinking that made segmented addressing so popular with ppl programming the 80x86 - NOT!!! The FSR is the logical way to use pointers in C, and having to bank-switch pointers plays hell with efficiency. Anyone remember the HUGE pointer type in PC type C? How inefficient it was? consider this dumb code fragment. #define BYTE unsigned char #ifdef BLOAT #define MAXARRAY 400 #else #define MAXARRAY 40 #endif main() { BYTE source_array[MAXARRAY]; BYTE dest_array[MAXARRAY]; BYTE *source_ptr, *dest_ptr; BYTE idx; source_ptr = source_array; dest_ptr = dest_array; for(idx = 0; idx < MAXARRAY; idx++) *source_ptr++ = *dest_ptr++; } Doesn't do much, but think about the extra code the compiler emits to generate bankswitching when BLOAT is defined... - and how many times you would use pointers in C - and the slowdown... MikeS <.....mikesmith_ozKILLspam.....relaymail.net>

{Quote hidden}> This is the kind of thinking that made segmented addressing so popular with > ppl programming the 80x86 - NOT!!! The FSR is the logical way to use > pointers in C, and having to bank-switch pointers plays hell with > efficiency. Anyone remember the HUGE pointer type in PC type C? How > inefficient it was? > > consider this dumb code fragment. > > #define BYTE unsigned char > > #ifdef BLOAT > #define MAXARRAY 400 > #else > #define MAXARRAY 40 > #endif > > main() > { BYTE source_array[MAXARRAY]; > BYTE dest_array[MAXARRAY]; > BYTE *source_ptr, *dest_ptr; > BYTE idx; > source_ptr = source_array; > dest_ptr = dest_array; > for(idx = 0; idx < MAXARRAY; idx++) > *source_ptr++ = *dest_ptr++; > } > > Doesn't do much, but think about the extra code the compiler emits to > generate bankswitching when BLOAT is defined... - and how many times you > would use pointers in C - and the slowdown... For the particular code fragement given, a smart compiler would generate decent code since it would know when the page boundaries were going to occur; consequently, it could just do something like... ; Part 1: neither side has crossed a page boundary yet movlw DoublePostIncrement movwf STATUS movlw NumBytesPart1div2 movwf Counter movlw StartAddr1 movwf FSR0 movlw StartAddr2 movwf FSR1 Loop1: movlr FirstBank movfp IND0,Temp0 movfp IND0,Temp1 movlw SecondBank movfp Temp0,IND1 movfp Temp1,IND1 decfsz Counter goto Loop1 ; Part 2: The first side has just crossed a page boundary movlw 32 movwf FSR0 movlw NumBytesPart2div2 movwf Counter Loop2: movlr FirstBank movfp IND0,Temp0 movfp IND0,Temp1 movlw SecondBank movfp Temp0,IND1 movfp Temp1,IND1 decfsz Counter goto Loop1 ... Which manages to be only about three times as slow as it oughta be (9 cycles per 2 bytes [4.5 per], instead of 7 cycles for 4 bytes [1.75 per])... Of course, if the compiler DIDN'T KNOW where the page crossings were going to be (e.g. /* Huge declarations imply pointers that may cross page boundaries */ void mymemcpy(huge char *ptr1, huge char *ptr2, unsigned char numbytes) { while (numbytes--) *ptr1++ = *ptr2++; } or other such code) then it couldn't do any optimizations like the above and would be stuck doing [assuming those #*($# 224-byte pages] ; Note: This code fragment assumes that three bytes of unbanked space are ; available [temp0, temp1, and temp2] _mymemcpy: movlw 0 ; These three instructions can probably iorwf numbytes ; be replaced with 1, but my 17Cxx book btfsc Z ; isn't handy. return movwf temp2 movfp ptr2,FSR0 movfp ptr2+1,temp0 movfp ptr1,FSR1 movfp ptr1+1,temp1 movlw NoAutoInc movwf STATUS loop: movpf temp0,BSR movpf IND0,WREG movpf temp1,BSR movpf WREG,IND1 infsnz FSR0 goto F0oops F0okay: infsnz FSR1 goto F1oops F1okay: decfsz numbytes goto loop return F0oops: bsf FSR0,5 ; Advance it to 32 movlw 16 addwf temp0 goto F0okay F1oops: bsf FSR1,5 ; Advance it to 32 movlw 16 addwf temp1 goto F1okay ELEVEN CYCLES PER BYTE--**BEST** CASE! If there weren't room for Temp0..Temp2 in unbanked memory, the count would go up to FOURTEEN! Even with only one memory pointer the 16C6x can do as well: MyMemCpy: movf NumBytes,w btfsc Z return movf Source,w movwf FSR subwf Dest,w movwf TempDS sublw 1 movwf TempSD Loop: movf IND,w movwf TempW movf TempSD,w addwf FSR movf TempW,w movwf IND movf TempDS,w addwf FSR decfsz NumBytes goto Loop [okay, I'll admit the above isn't a perfect comparison since the 16C6x version doesn't deal with pointers crossing pages. If I didn't have to worry about incrementing pointers through page boundaries that would improve the 17Cxx code to seven cycles per byte. But the 17Cxx is supposed to be much better than the 16Cxx; its performance on this type of thing is IMHO quite deficient.]

> From: John Payson <EraseMEsupercatspam_OUTTakeThisOuTMCS.COM> > To: PICLISTspam_OUTMITVMA.MIT.EDU > Subject: Re: 17C5X (was thanks... 0402) > Date: Sunday, 25 May 1997 21:04 <snip> > > For the particular code fragement given, a smart compiler would generate > decent code since it would know when the page boundaries were going to > occur; consequently, it could just do something like... Is this a real compiler, or a hypothetical one? I can't throw mine (CCS's) at this code, because it doesn't yet support 17xx's. I've noticed that my code body size does change significantly going from an array of 32 to one of 96, when targetting a 16c74. I'd like to hear of other ppls experiences... <snip> > Which manages to be only about three times as slow as it oughta be (9 > cycles per 2 bytes [4.5 per], instead of 7 cycles for 4 bytes [1.75 > per])... Still bad, IMO > > Of course, if the compiler DIDN'T KNOW where the page crossings were going > to be (e.g. > > /* Huge declarations imply pointers that may cross page boundaries */ > void mymemcpy(huge char *ptr1, huge char *ptr2, unsigned char numbytes) <snip> > ELEVEN CYCLES PER BYTE--**BEST** CASE! If there weren't room for > Temp0..Temp2 in unbanked memory, the count would go up to FOURTEEN! > Even with only one memory pointer the 16C6x can do as well: Worse <snip> > > [okay, I'll admit the above isn't a perfect comparison since the 16C6x > version doesn't deal with pointers crossing pages. If I didn't have to > worry about incrementing pointers through page boundaries that would > improve the 17Cxx code to seven cycles per byte. But the 17Cxx is > supposed to be much better than the 16Cxx; its performance on this type of > thing is IMHO quite deficient.] I think you're agreeing with me, somewhat. Microchip are hamstringing themselves with all of this backward compatibility stuff. They would do better dropping it (Shock!) and coming out with one that eliminates bank-switching, uses a contiguous flat area of RAM, and allows a really efficient compiler to work. While they're at it, how about a conventionally accessible stack pointer, another useful thing for compilers. MikeS <@spam@mikesmith_ozKILLspamrelaymail.net>

Mike Smith wrote: > > I think you're agreeing with me, somewhat. Microchip are hamstringing > themselves with all of this backward compatibility stuff. They would > do better dropping it (Shock!) and coming out with one that > eliminates bank-switching, uses a contiguous flat area of RAM, and > allows a really efficient compiler to work. While they're at it, > how about a conventionally accessible stack pointer, another useful > thing for compilers. I have been part of both commercial instruction set design and and compiler development projects. Every processor has goals and implementation is a balancing act between many objectives. Not to put down the Mike's comments but there is a down side (the up side is obvious) to your suggestions as well. A flat RAM address space implies a bigger RAM address space and to maintain a single instruction size that implies a wider instruction word. This is something Microchip has already done twice with the PIC processors. The larger silicon area costs more porportional to the square of the die size. We have found the value of stack frames in embedded systems to be limited. One of our studies has shown that even a well implemented stack frame only rarily improves performance over a well implimented code generator. RAM usage will be essentially identical. Here again instruction set size becomes a factor, this time it is opcode space. Walter Banks http://www.bytercraft.com

{Quote hidden}> From: Walter Banks <KILLspamwalterKILLspamBYTECRAFT.COM> > To: RemoveMEPICLISTTakeThisOuTMITVMA.MIT.EDU > Subject: Re: 17C5X (was thanks... 0402) > Date: Monday, 26 May 1997 22:00 > > Mike Smith wrote: > > > > I think you're agreeing with me, somewhat. Microchip are hamstringing > > themselves with all of this backward compatibility stuff. They would > > do better dropping it (Shock!) and coming out with one that > > eliminates bank-switching, uses a contiguous flat area of RAM, and > > allows a really efficient compiler to work. While they're at it, > > how about a conventionally accessible stack pointer, another useful > > thing for compilers. > > I have been part of both commercial instruction set design and > and compiler development projects. Every processor has goals and > implementation is a balancing act between many objectives. Not to > put down the Mike's comments but there is a down side (the up side > is obvious) to your suggestions as well. A flat RAM address space > implies a bigger RAM address space and to maintain a single instruction > size that implies a wider instruction word. This is > something Microchip has already done twice with the PIC processors. > The larger silicon area costs more porportional to the square of > the die size. That was one of my points. the 17Cxx is the upper end (at the moment) of the PIC family. A higher cost is more acceptable here. (IMO) Given that your email address indicates you work for or possibly own (?) ByteCraft, a compiler for the PIC, would you be interested in doing benchmarks of your product for differing array size memcpy's? > > We have found the value of stack frames in embedded systems > to be limited. One of our studies has shown that even a well > implemented stack frame only rarily improves performance over > a well implimented code generator. RAM usage will be essentially > identical. Here again instruction set size becomes a factor, this > time it is opcode space. Even if you were implementing a RT multitasking embedded system? MikeS <spamBeGonemikesmith_ozspamBeGonerelaymail.net>