> From: John Payson <supercat@MCS.COM>
> To: PICLIST@MITVMA.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
<mikesmith_oz@relaymail.net>