Searching \ for '17C5X (was thanks... 0402)' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/index.htm?key=17c5x+was+thanks
Search entire site for: '17C5X (was thanks... 0402)'.

Truncated match.
PICList Thread
'17C5X (was thanks... 0402)'
1997\05\22@012159 by Andres Djordjalian

flavicon
face
>> 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_OUTadjordjTakeThisOuTspamaleph.fi.uba.ar

1997\05\22@015944 by John Payson

flavicon
face
{Quote hidden}

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}

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}

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.

1997\05\25@090505 by Mike Smith

flavicon
face
> From: Andres Djordjalian <.....adjordjKILLspamspam@spam@ALEPH.FI.UBA.AR>
> To: PICLISTspamKILLspamMITVMA.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_ozKILLspamspam.....relaymail.net>

1997\05\25@122809 by John Payson

flavicon
face
{Quote hidden}

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.]

1997\05\25@211556 by Mike Smith

flavicon
face
> From: John Payson <EraseMEsupercatspam_OUTspamTakeThisOuTMCS.COM>
> To: PICLISTspamspam_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_ozKILLspamspamrelaymail.net>

1997\05\26@075416 by Andy Kunz

flavicon
face
>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.

The same problem that Intel and Microsoft have.  Three cheers for FLAT MEMORY!

Andy

==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\05\26@083632 by Walter Banks

picon face
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

1997\05\26@214504 by Mike Smith

flavicon
face
{Quote hidden}

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_ozspamBeGonespamrelaymail.net>

1997\05\27@012733 by Walter Banks

picon face
Mike Smith wrote:
>

> That was one of my points.  the 17Cxx is the upper end
> the PIC family.  A higher cost is more acceptable here.
> Would you be interested in doing benchmarks of your product for
> differing array size memcpy's?

Sure it would be interesting to look at the differences.

> > 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?

In small embedded systems the biggest factor is the method used for
context switching. Given a choice I would go for an extra index
register.

Walter Banks
http://www.bytecraft.com

More... (looser matching)
- Last day of these posts
- In 1997 , 1998 only
- Today
- New search...