Searching \ for '[PIC]: 16C76/CCS vs. 18C252/Hi-Tech' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=16C
Search entire site for: '16C76/CCS vs. 18C252/Hi-Tech'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: 16C76/CCS vs. 18C252/Hi-Tech'
2000\11\15@174153 by embedded engineer

flavicon
face
After running out of ROM (and RAM) in the 16C76 I am trying the Hi-Tech
beta 18Cxxx compiler for a 18C252 target and am getting suprising
results.  With the 16C76 at near 100 percent I figure the ROM usage is
about 8k words or about 14k bytes at 14 bit words.  With the 18C252,
Hi-Tech reports "21194 bytes total Program ROM".

Of coarse I had to modify data types and write functions for those
provided by CCS.

I was expecting about the same ROM usage in bytes or maybe even a little
less with the 18C252.  I know this is kind of an apples and oranges
question but I am hoping someone here has similar experience.  Was I
expecting too much?   Will the non-beta version of Hi-Tech C produce
tighter code or is that just wishful thinking?  How could the 18C252
require so much more ROM for the same c code?

Regards,
David Koski

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\11\15@175440 by rchock, Steve

flavicon
face
Remember the 18CXXX series is 16 bits (2 bytes).
Not sure if this will help........

Steve

-----Original Message-----
From: embedded engineer [spam_OUTembeddedTakeThisOuTspamELUCIT.COM]
Sent: Wednesday, November 15, 2000 3:42 PM
To: .....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU
Subject: [PIC]: 16C76/CCS vs. 18C252/Hi-Tech


After running out of ROM (and RAM) in the 16C76 I am trying the Hi-Tech
beta 18Cxxx compiler for a 18C252 target and am getting suprising
results.  With the 16C76 at near 100 percent I figure the ROM usage is
about 8k words or about 14k bytes at 14 bit words.  With the 18C252,
Hi-Tech reports "21194 bytes total Program ROM".

Of coarse I had to modify data types and write functions for those
provided by CCS.

I was expecting about the same ROM usage in bytes or maybe even a little
less with the 18C252.  I know this is kind of an apples and oranges
question but I am hoping someone here has similar experience.  Was I
expecting too much?   Will the non-beta version of Hi-Tech C produce
tighter code or is that just wishful thinking?  How could the 18C252
require so much more ROM for the same c code?

Regards,
David Koski

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\11\15@180026 by embedded engineer

flavicon
face
Correct, the 18CXXX is 16 bits verses 14 bits for the 16C76.  Hence, per
bit, (or byte) the 18C252 seems to be taking *much* more ROM.

"Kosmerchock, Steve" wrote:
>
> Remember the 18CXXX series is 16 bits (2 bytes).
> Not sure if this will help........
>
> Steve
>
> {Original Message removed}

2000\11\15@182620 by Scott Dattalo

face
flavicon
face
On Wed, 15 Nov 2000, embedded engineer wrote:

> Correct, the 18CXXX is 16 bits verses 14 bits for the 16C76.  Hence, per
> bit, (or byte) the 18C252 seems to be taking *much* more ROM.

I'm sure Bob or Thomas will have more to say, but for the 18cxxx code I've
written, it's much more bit efficient. If the Hi-tech compiler is generating
16C76 type code but making the minor modifications necessary for the 18cxxx
family, then I'd expect the code to be about 16/14 times larger. But you're
seeing much more than this. So the next possibility is that you're inadvertantly
linking in an unnecessary library. Look at the memory map produced by the linker
(actually I'm assuming the HiTech compiler produces one) and see what's getting
placed into memory.

Scott

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\11\15@213845 by Clyde Stubbs

flavicon
face
On Wed, Nov 15, 2000 at 02:42:07PM -0800, embedded engineer wrote:
> results.  With the 16C76 at near 100 percent I figure the ROM usage is
> about 8k words or about 14k bytes at 14 bit words.  With the 18C252,
> Hi-Tech reports "21194 bytes total Program ROM".

Firstly, the 18C figure is in bytes, so that is halved for words. The
word size is unfortunately of no significance (14 vs. 16 bits) because
all it gets you is bigger memory addressing. So you're seeing about
10K words vs. 8K words. This is in the range that we've seen - the 18C
code tends to be a little larger (but the 18C has a much bigger
address space, so you're not restricted to only 8K as you are for
the 16C series chips).

The reason the code is a little larger is twofold; because the chip
can address more memory, it tends to need more instructions to
do it. And because the compiler is new, it has not had as much work
put into it to optimize the code as the 16C compiler has. So with time,
you could expect the code size to come down, but I would not expect
it to ever get, on average, any smaller than the 16C code. But a
reduction of 10-15% over what is being produced now is not out
of the question.

There is also one instruction (LFSR) that is not usable because
the current chips don't implement it correctly. This will hopefully
be fixed in the future, but probably not on the 18Cx52 devices.

Also, if you're using printf or its friends, the version of
printf used in the 18C library is more powerful (and thus
larger) than the 16C version. IF this is a problem, using
some other function or customizing printf would be beneficial.

Notwithstanding all the above, the bottom line is that you can get
much more code into an 18C chip because your code might grow by
20% but your available ROM grows by 100%.

Cheers, Clyde

--
Clyde Stubbs                     |            HI-TECH Software
Email: clydespamKILLspamhtsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger .....clydeKILLspamspam.....htsoft.com   | AUS: +61 7 3355 8333 +61 7 3355 8334
---------------------------------------------------------------------------
HI-TECH C: compiling the real world.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\11\16@072127 by mike

flavicon
face
On Wed, 15 Nov 2000 17:30:52 -0600, you wrote:

>On Wed, 15 Nov 2000, embedded engineer wrote:
>
>> Correct, the 18CXXX is 16 bits verses 14 bits for the 16C76.  Hence, per
>> bit, (or byte) the 18C252 seems to be taking *much* more ROM.
>
>I'm sure Bob or Thomas will have more to say, but for the 18cxxx code I've
>written, it's much more bit efficient. If the Hi-tech compiler is generating
>16C76 type code but making the minor modifications necessary for the 18cxxx
>family, then I'd expect the code to be about 16/14 times larger. Surely smaller, as it ought to be using fewer instructions.
>But you're
>seeing much more than this. So the next possibility is that you're inadvertantly
>linking in an unnecessary library. Look at the memory map produced by the linker
>(actually I'm assuming the HiTech compiler produces one) and see what's getting
>placed into memory.
>
>Scott
..or maybe HT haven;t optimised the 18xx libs yet ? Looking at the detail of the usage should reveal where the code is
going.
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2000\11\16@112235 by Douglas Wood

flavicon
face
Wait a minute! You can't compare the 12-, 14- and 16-bit PIC like that. You
can say that, for example, a 12-bit PIC program that uses 512 12-bit words
as being more efficient than a 14-bit PIC program that uses 512 14-bit
words. The binaries wouldn't run on the other processor because of opcode
encoding and other things. Additionally, the 18C family has features that
make it far more efficient than previous PIC families (like the access back
feature for example). The number of program words on a 18C should be less
and an equivalent 17C part, for example, because the access back feature
would require less back switching instructions.

Douglas Wood
Software Engineer

{Original Message removed}

2000\11\16@120417 by Scott Dattalo

face
flavicon
face
On Thu, 16 Nov 2000, Douglas Wood wrote:

> Wait a minute! You can't compare the 12-, 14- and 16-bit PIC like that. You

Uh what?

I suppose one can compare anything. Pundits do it all the time.

If you have a program with a whole lot of 16 bit addition, for example, the you
can say that it takes in general 5 instructions on the 12 and 14 bit cores, but
only 4 instructions on the 16bit core. In terms of bits: 60, 70, and 48 for the
12,14, and 16-bit cores. From this I can say that it takes fewer bits to perform
16-bit addition. If you're looking at the output of C-compiler (which is what
prompted this discussion), then you'd expect the number of "program memory bits"
for the 16-bit core in general to be less than that of the 14-bit core (for the
same program). That's all we're saying.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2000\11\16@121905 by Douglas Wood

flavicon
face
Who keeps track of program size in bits? That's not a very realistic
approach to determining program size. And remember, we're engineers, not
pundits; we're expected to know better than that.

Douglas Wood
Software Engineer

{Original Message removed}

2000\11\16@122943 by Olin Lathrop

flavicon
face
> The number of program words on a 18C should be less
> and an equivalent 17C part, for example, because the access back feature
> would require less back switching instructions.

I don't think it's that simple.  There are other instances where the 18C
instruction set would require more bits to get the same job done.  For
example, GOTOs contain the full 20 bit address, whereas 16C PICs only
contain an 11 bit address.  Another example is that the FSRs are now 2 bytes
long, which requires them both to be set properly before use.  If a compiler
makes heavy use of pointers, then this could result in increased code size.

The 18C instruction set is usually more convenient to the programmer, but
this is done by using more opcode bits in various places.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, @spam@olinKILLspamspamcognivis.com, http://www.cognivis.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2000\11\16@123825 by Scott Dattalo

face
flavicon
face
On Thu, 16 Nov 2000, Douglas Wood wrote:

> Who keeps track of program size in bits? That's not a very realistic
> approach to determining program size. And remember, we're engineers, not
> pundits; we're expected to know better than that.

I guess you didn't see the first post in this thread. I'll paraphrase:

(See the subject). The original poster wanted to know why the 18cxxx
implementation of the Hi-tech compiler seemed to produce a very large rom image
when compared to the same C-code compiled with the CCS compiler but directed
towards the 14-bit core. So he wasn't "keeping track" of program size in bits as
much as he was just curious why the supposedly more efficient 18cxxx instruction
set yielded a much larger rom image. It was simple as that.

Now who keeps track of program size in bits? Well not too many people,
true. However, there are people that do. For example, if you have an ASIC
implementation of some custom MCU and have a finite amount of flash to work
with, you certainly want to conserve your program size/bits. If you can make
minor tweaks to your mcu core that conserve enormous amounts of program memory,
you'll do it. People have done and still are. In fact, you can say Scenix has
even done it. They kept the 12-bit core and added a few instructions.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2000\11\16@165736 by Alan B. Pearce

face picon face
>(See the subject). The original poster wanted to know why the 18cxxx
>implementation of the Hi-tech compiler seemed to produce a very large rom image
>when compared to the same C-code compiled with the CCS compiler but directed

Surely for this purpose the measure is the number of instruction words a given
program takes. As the instruction word is not divisible into bytes like the x86
instruction set, then the full word has to be the measure, however long the word
is. If a program compiled for a 16 bit word instruction then takes less words
than the identical program compiled for a 14 bit word instruction, then the
statement can be made that the instruction set is probably more efficient on the
16 bit word. But when compiler A targeted at 14 bit and compiler B targeted at
16 bit instructions are being compared, even for the same source code, then the
argument is comparing apples and oranges. If both compilers come from the same
software house, with a reasonable chance that one compiler has built on the
experience of the other, or is an option within the compiler for the two
different targets, then there is a reasonable chance that you are comparing like
with like, and the major variant is the instruction word size.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body


2000\11\16@202640 by Harold M Hallikainen

picon face
On Wed, 15 Nov 2000 17:30:52 -0600 Scott Dattalo <TakeThisOuTscottEraseMEspamspam_OUTDATTALO.COM>
writes:
> On Wed, 15 Nov 2000, embedded engineer wrote:
>
> > Correct, the 18CXXX is 16 bits verses 14 bits for the 16C76.
> Hence, per
> > bit, (or byte) the 18C252 seems to be taking *much* more ROM.
>
> I'm sure Bob or Thomas will have more to say, but for the 18cxxx
> code I've
> written, it's much more bit efficient. If the Hi-tech compiler is
> generating
> 16C76 type code but making the minor modifications necessary for the
> 18cxxx
> family, then I'd expect the code to be about 16/14 times larger. But
> you're
> seeing much more than this.

       But in the previous PICs, each instruction took 1 address (14 bits),
while on the 18c series, each instruction takes AT LEAST two addresses
(16 bits). So, in terms of the number of addresses used, I'd expect the
18c to be at least double that of the 16c except where more efficient
instructions (such as hardware multiply) decrease the size of 18c code.

Harold



FCC Rules Online at http://hallikainen.com/FccRules
Lighting control for theatre and television at http://www.dovesystems.com

________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
dl.http://www.juno.com/get/tagj.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2000\11\17@035914 by Andy Jancura

picon face
Hi Clyde,

its really interresting discussion about HiTech's compiler. I think it
should be so hard to write an optimizing compiler for 18c. Because

1) you have experience with Pic C. 18c has instructions compatible with 16c.

2) you make compiler for 68HC05 and 68HC11, specialy HC11 has similar
opcodes to 18C.

The compiler/optimizer should then take the well optimized code from this
two CPU's and combine it together. For example 8-bit integer math and branch
optimizing from HC11, from Pic C indirect call to functions.


Andrej

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at
http://profiles.msn.com.

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestEraseMEspam.....mitvma.mit.edu


2000\11\17@043014 by Andy Jancura

picon face
>I don't think it's that simple.  There are other instances where the
>18C instruction set would require more bits to get the same job done.
>For example, GOTOs contain the full 20 bit address, whereas 16C PICs
>only contain an 11 bit address.

O.K., but GOTO doesn't need paging when jumping to bigger address and you
can use branch of -128/+127 words.

>Another example is that the FSRs are now 2 bytes long, which requires
>them both to be set properly before use.

Agree, but when you use small trick and optimize data structures, you
initialize all four pointers once at start and then just manipulate the
FSRxL. You can acess four independent pages of 256 bytes, plus you have
fifth by using BSR and 128 bytes in acess bank.

Andrej

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at
http://profiles.msn.com.

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspammitvma.mit.edu


2000\11\17@153445 by embedded engineer

flavicon
face
Clyde Stubbs wrote:
{Quote hidden}

My sense is that with given bits of ROM, (square microns, acres, etc.),
one can provide roughly the same functionality regardless of the the
word size (within reason).  Hence my suprise.  Certainly, there are
factors that work against the word size of 16 bits as you have stated,
but there are other factors that I would expect to work in *favor* of 16
bit word size.  For example bank switching.  Without having compared the
actual code generated, it turns out that the final results seem to
support my assertion.  (See below).

> There is also one instruction (LFSR) that is not usable because
> the current chips don't implement it correctly. This will hopefully
> be fixed in the future, but probably not on the 18Cx52 devices.
>
> Also, if you're using printf or its friends, the version of
> printf used in the 18C library is more powerful (and thus
> larger) than the 16C version. IF this is a problem, using
> some other function or customizing printf would be beneficial.

As it turns out, it was printf that was the culprit.  Since I was not
using any of its formatting I simply replaced it with my own print
string function and the code size went down to 15786 "bytes total
Program ROM".  Although I did say "final results" above, I haven't
actually tried executing the code, so your milage may vary. :)

David Koski

{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspamspammitvma.mit.edu


2000\11\19@191949 by Clyde Stubbs

flavicon
face
On Thu, Nov 16, 2000 at 09:58:25PM -0000, Alan B. Pearce wrote:
> different targets, then there is a reasonable chance that you are comparing like
> with like, and the major variant is the instruction word size.

Yes, but the 18C compiler reports in bytes, while the 16C compiler
reports in words, so you have to take that into account. It has
confused a couple of people to begin with.


--
Clyde Stubbs                     |            HI-TECH Software
Email: EraseMEclydespamspamspamBeGonehtsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger RemoveMEclydeKILLspamspamhtsoft.com   | AUS: +61 7 3355 8333 +61 7 3355 8334
---------------------------------------------------------------------------
HI-TECH C: compiling the real world.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\11\19@192357 by Clyde Stubbs

flavicon
face
On Fri, Nov 17, 2000 at 09:59:11AM +0100, Andy Jancura wrote:
> The compiler/optimizer should then take the well optimized code from this
> two CPU's and combine it together. For example 8-bit integer math and branch
> optimizing from HC11, from Pic C indirect call to functions.

Doesn't work like that. The 18C is different to the 16C, but it is
still a PIC. There are some shortcomings in its instruction set, it
differs from the 16C mainly in that ROM paging is no longer an
issue (but there is a cost in code size from that - calls take
more words often) and the banking is quite different, but still
an issue (just a different issue). The HC11 is much easier because
it has a flat 64K address space for both code and data. No banking
issues (though we do handle banking for program code).

Indirect function calls have proved to be particularly difficult
on the 18C, fortunately they are not something that gets used a
lot.

Cheers, Clyde

--
Clyde Stubbs                     |            HI-TECH Software
Email: clydeSTOPspamspamspam_OUThtsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger spamBeGoneclydeSTOPspamspamEraseMEhtsoft.com   | AUS: +61 7 3355 8333 +61 7 3355 8334
---------------------------------------------------------------------------
HI-TECH C: compiling the real world.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\11\19@213634 by Bob Ammerman

picon face
> Indirect function calls have proved to be particularly difficult
> on the 18C, fortunately they are not something that gets used a
> lot.

I should think an indirect function call would be TRIVIAL on an 18C and
rather difficult on other PIC processors:

given:

void f(void)
{
}

void (*g)(void);    // g is a pointer to a func

// Assign pointer to variable
g = f;

movlw    low(f)
movwf    _g
lovlw      high(f)
movwf    _g+1

// Call thru pointer:
(*g)()

   push
   movf     _g,w
   movwf  tosl
   movf     _g+1,w
   movwf  tosh
   return

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\11\19@221509 by Bob Ammerman

picon face
Corrections below. Sorry!

----- Original Message -----
From: Bob Ammerman <KILLspamRAMMERMANspamBeGonespamPRODIGY.NET>
To: <EraseMEPICLISTspamEraseMEMITVMA.MIT.EDU>
Sent: Sunday, November 19, 2000 9:29 PM
Subject: Re: [PIC]: 16C76/CCS vs. 18C252/Hi-Tech


{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\11\20@002729 by Scott Dattalo

face
flavicon
face
On Sun, 19 Nov 2000, Bob Ammerman wrote:

> > Indirect function calls have proved to be particularly difficult
> > on the 18C, fortunately they are not something that gets used a
> > lot.
>
> I should think an indirect function call would be TRIVIAL on an 18C and
> rather difficult on other PIC processors:

How hard is it on the C76?

{Quote hidden}

 movlw   low(f)
 movwf   _g
 lovlw   high(f)  ;sic.
 movwf   _g+1

So far so good.

{Quote hidden}

  movlw _g+1
  call  make_indirect_call     ;need to make a call so the return
                               ;will be matched. i.e. the function
                               ;being called indirectly returns here


make_indirect_call:             ;Now make an indirect jump to the function
  movwf   FSR
  movf    INDF,w
  movwf   PCLATH
  decf    FSR,f
  movf    INDF,w
  movwf   PCL


10 cycles (versus 7 (but should be 8 to clear tosu) to make the call.

Is there a faster way?

Scott

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\11\20@003145 by Sean H. Breheny

face picon face
Scott,

What is "lovlw"? I noticed you added "sic", so you must intend for it to
really be "lovlw", not "movlw"

Sean

At 11:31 PM 11/19/00 -0600, you wrote:

>   movlw   low(f)
>   movwf   _g
>   lovlw   high(f)  ;sic.
>   movwf   _g+1

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\11\20@004635 by Scott Dattalo

face
flavicon
face
On Mon, 20 Nov 2000, Sean H. Breheny wrote:

> Scott,
>
> What is "lovlw"? I noticed you added "sic", so you must intend for it to
> really be "lovlw", not "movlw"

It's almost midnight, and probably past midnight where Bob lives, and except for
our friends at the bottom the world and a couple of over-caffeinated students
there's no one reading the list. By the time the others get to this message,
their eyes will already be out of focus from the daily PICLIST deluge and
they'll dismiss Bob's tiny typo even if they do notice it. But I figured I'd
have a little fun with it anyway. Go to bed Sean!

Scott


{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\11\20@005256 by Bill Westfield

face picon face
   It's almost midnight, and probably past midnight where Bob lives,
   and except for our friends at the bottom the world and a couple
   of over-caffeinated students there's no one reading the list.

Don't forget all of use who would LIVE in night-mode, if we could.
Midnight is early.

BillW

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\11\20@033933 by Andy Jancura

picon face
Hi Scott and Bob,

{Quote hidden}

why this Bob???

small change in Scotts code and that's

    movf _g,W      ; need low byte in W

{Quote hidden}

on 18C:

make_indirect_call:

    clrf    PCLATHU       ; clear jump in 64Kb space
    movff   _g+1, PCLATH  ; set high byte
    movwf   PCL           ; set low byte from W and jump

So have 3 +1(movf W) instruction to do it.

>10 cycles (versus 7 (but should be 8 to clear tosu) to make the call.
>
>Is there a faster way?
>
>Scott



Andrej

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at
http://profiles.msn.com.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\11\20@042816 by Andy Jancura

picon face
> > The compiler/optimizer should then take the well optimized code from
> > this two CPU's and combine it together. For example 8-bit integer
> > math and branch optimizing from HC11, from Pic C indirect call to
> > functions.
>
>Doesn't work like that. The 18C is different to the 16C, but it is
>still a PIC. There are some shortcomings in its instruction set, it
>differs from the 16C mainly in that ROM paging is no longer an
>issue (but there is a cost in code size from that - calls take
>more words often)

Clyde, using call on 18C, two ways

1) RCALL -1024/+1023 ; 1 word
2) CALL  20bit       : 2 word

When I take optimizer from 16C, then I programm only small address test.
When need 20 bits, then generate 2words call (paging on 16C), when not, then
generate just 1 word. The same for GOTO and BRA.

>and the banking is quite different, but still an issue (just a different
>issue).

Only ram management is different. Your Pic C18 compiler can use MOVFF and
one FSR to overcome this. And how I wrote early, just set FSRH = 0, and use
FSRL and you are back to Pic C.

>The HC11 is much easier because it has a flat 64K address space for
>both code and data. No banking issues (though we do handle banking for
>program code).

The difference between that two MCU, HC11 has zero page of 256 bytes, 18C
has access bank of 128 bytes ram. Both have flat program area. Using
routines from HC11 shouldn't be a problem.

>Indirect function calls have proved to be particularly difficult
>on the 18C, fortunately they are not something that gets used a
>lot.

I use it, code is much more smaller.


Kinds regards,

Andrej

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at
http://profiles.msn.com.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\11\20@062013 by Alan B. Pearce

face picon face
>Yes, but the 18C compiler reports in bytes, while the 16C compiler
>reports in words, so you have to take that into account. It has
>confused a couple of people to begin with.

So surely it is up to the compiler writer to remove the confusion by reporting
in the same units each time? :) (I do appreciate the occupation of the
originator of the quoted piece).

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\11\20@082054 by Andrew Kunz

flavicon
face
>So surely it is up to the compiler writer to remove the confusion by reporting
>in the same units each time? :) (I do appreciate the occupation of the
>originator of the quoted piece).

No!  The compiler writer's job is to remain consistent with the manufacturer's
nomenclature.  Microchip changed to bytes from words on the recommendation of
(we were told) their outside compiler consultant (presumably IAR, "The
Dongle-Ware Company" TM).

Andy

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\11\20@084437 by Scott Dattalo

face
flavicon
face
On Mon, 20 Nov 2000, Andy Jancura wrote:

{Quote hidden}

Good solution! But in cycles, it's 8. Also, it should be a macro or at least
kept in mind that it'll only call (*g)().

But, you could simplify it for macro-izing:

ICALL    MACRO  _g

   clrf   PCLATHU
   movff  _g+1,PCLATH
   movf   _g,w          ;avoid movff to PCL on the 18cxxx
   movwf  PCL

       ENDM


And then invoke it:

   ...

   rcall  iCall_g

   ...


        ORG   somewhere_else
iCall_g:
    ICALL  _g


Or at the cost of one branch, you could inline the macro with your code.

Scott

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\11\20@095623 by Bob Ammerman

picon face
Ok guys: you got me good.

btw: the best way I can figure to handle function pointers on 16C devices is
to have the compiler/linker build a goto table of all functions whose
address is ever taken. Then a pointer to a function simply becomes an index
into that table.

Something like this:

void f1()
{
}

void f2()
{
}

void (*g)(); // pointer to func

Table built by compiler:

; on entry W is function 'pointer' (really function number)

; (of course we have to deal with page boundary issues here)

call_func_indirect:
      addwf    PCL,F
      goto       f1
      goto       f2

g = f1;

   clrf    g

g=f2;

   movlw    1    ; function number for F2
   movwf    g

(*g)();    // call the function

   movf    g,W
   call      call_func_indirect

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\11\20@104516 by Bob Ammerman

picon face
----- Original Message -----
From: Andy Jancura <@spam@andy_jancura@spam@spamspam_OUTHOTMAIL.COM>
To: <spamBeGonePICLISTspamKILLspamMITVMA.MIT.EDU>
Sent: Monday, November 20, 2000 4:40 AM
Subject: Re: [PIC]: 16C76/CCS vs. 18C252/Hi-Tech


> Hi Scott and Bob,
>
> >On Sun, 19 Nov 2000, Bob Ammerman wrote:
> >
> > > > Indirect function calls have proved to be particularly difficult
> > > > on the 18C, fortunately they are not something that gets used a
> > > > lot.
> > >
> > > I should think an indirect function call would be TRIVIAL on an 18C
and
{Quote hidden}

function
{Quote hidden}

Just call me an idiot. Working at crazy hours is my only excuse!

For 18c:

   call    call_g_indirect


call_g_indirect:
   movff    _g+1,PCLATH
   movf     _g,W
   movwf  PCL

For any 18c that currently exists it is probably reasonable to assume that
PCLATU is zero and stays that way. A clrf PCLATU could be added to handle
the future processors. I think that if I were developing an 18C compiler I
would probably have a #pragma or command line switch to choose between a
64KB or 2MB code model. In the 64KB case I'd just set PCLATU to zero and
leave it alone. This also applies to manipulating TOSU/TOSH/TOSL and
TBLPTRU/TBLPTRH/TBLPTRL.

For 16c:

   call    call_g_indirect

call_g_indirect:
   movf     _g+1,W
   movwf  PCLATH
   movf     _g,W
   movwf  PCL

On both processors a generic solution could be developed that used FSR to
point to the code pointer:

For 18c:
   movlw    low(_g+1)        ; address of MSBits of G
   movwf    FSR0L
   movlw    high(_g+1)
   movwf    FSR0H
;   LFSR    0,_g+1            ; sure wish this worked!
   call         call_indirect


call_indirect:
   movff      POSTDEC0,PCLATH
   movf       INDF0,W
   movwf    PCL

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\11\20@112949 by Andy Jancura

picon face
{Quote hidden}

Bob, on 18C this doesn't work, with GOTO's. The call_func_indirect need to
compute fn_number*2 at first. But this will work with BRA (1word).


Andrej

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at
http://profiles.msn.com.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\11\20@125523 by Bob Ammerman

picon face
----- Original Message -----
From: Andy Jancura <.....andy_jancuraspam_OUTspamHOTMAIL.COM>
To: <TakeThisOuTPICLIST.....spamTakeThisOuTMITVMA.MIT.EDU>
Sent: Monday, November 20, 2000 12:30 PM
Subject: Re: [PIC]: 16C76/CCS vs. 18C252/Hi-Tech


> >
> >Ok guys: you got me good.
> >
> >btw: the best way I can figure to handle function pointers on 16C devices
> >is
> >to have the compiler/linker build a goto table of all functions whose
> >address is ever taken. Then a pointer to a function simply becomes an
index
{Quote hidden}

Actually, on the 18C you need fn_number*2 for BRA and fn_number*4 for GOTO
because the 18C uses byte addressed in PCL!

I'd just have the function pointer actually be fn_number*4 and be done with
it. Of course, we are then limited to 64 functions max that can have their
addresses taken.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\11\21@025152 by Andy Jancura

picon face
>Actually, on the 18C you need fn_number*2 for BRA and fn_number*4 for
>GOTO because the 18C uses byte addressed in PCL!
>
>I'd just have the function pointer actually be fn_number*4 and be done
>with it. Of course, we are then limited to 64 functions max that can
>have their addresses taken.
>
>Bob Ammerman


You have right, bytes vs. words again.

Andrej


_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservKILLspamspamspammitvma.mit.edu with SET PICList DIGEST in the body


2000\11\21@080505 by Scott Dattalo

face
flavicon
face
On Tue, 21 Nov 2000, Andy Jancura wrote:

> >Actually, on the 18C you need fn_number*2 for BRA and fn_number*4 for
> >GOTO because the 18C uses byte addressed in PCL!
> >
> >I'd just have the function pointer actually be fn_number*4 and be done
> >with it. Of course, we are then limited to 64 functions max that can
> >have their addresses taken.
> >
> >Bob Ammerman
>
>
> You have right, bytes vs. words again.

Are you sure? It's true that the 18C allows addressing to the byte level when
reading and writing program memory using the TBL instructions. However, as I
understand it (and I could be wrong), the program counter doesn't use the LSB of
the address and when it is advanced it's always advanced by two address counts.
Furthermore, the contents of PCL are address bits A8:A1 and not A7:A0 like the
16Cxx devices. If you look at the way a branch instruction is encoded for
example, you'll notice that the relative jump is specified in terms of words and
not in bytes.

If this is the case, you'll have upto 256 branch vectors or 128 goto vectors.

But in either case, a hardcoded lookup table is not the way the compiler will
handle arbitrary function pointers. If you explicityly created an array of
function pointers (hey C++ vtables !) and use an index to call one, then the
look up table would be easier for the compiler to generate.

Hmm. C++ for a PIC. Now wouldn't that be something!

[Walter, what has happened to EC++?]

Scott

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservspamRemoveMEmitvma.mit.edu with SET PICList DIGEST in the body


2000\11\21@082649 by Bob Ammerman

picon face
----- Original Message -----
From: Scott Dattalo <RemoveMEscottspamspamBeGoneDATTALO.COM>
To: <spamBeGonePICLIST@spam@spamspam_OUTMITVMA.MIT.EDU>
Sent: Tuesday, November 21, 2000 8:09 AM
Subject: Re: [PIC]: 16C76/CCS vs. 18C252/Hi-Tech


{Quote hidden}

when
> reading and writing program memory using the TBL instructions. However, as
I
> understand it (and I could be wrong), the program counter doesn't use the
LSB of
> the address and when it is advanced it's always advanced by two address
counts.
> Furthermore, the contents of PCL are address bits A8:A1 and not A7:A0 like
the
> 16Cxx devices. If you look at the way a branch instruction is encoded for
> example, you'll notice that the relative jump is specified in terms of
words and
> not in bytes.

PCL contains address bits A7:A0.  The low bit is always zero. I think this
was a design error in the 18C architecture. I would have defined PCL to
contain A8:A1, PCLATH would then be A16:A9, PCLATU would hold the remaining
bits. Note that this gives you twice as much code for one PCLATH value and
twice the reach for a ADDWF PCL,F. As it is the 18C can only handle 128
instructions with the latter!

The problem with this scheme is that existing code that uses LOW() and
HIGH() to play with code addresses would break horribly. My guess is that
mChip did it this way to provide for maximum portability of code while
moving to byte addressable code memory (for TBLPTRish stuff).

Related to all this, I've often wondered whether TOSL and the stack have a
functional low-order bit. I've never checked this, but the test would be
relatively simple:

   push
   bsf    TOSL,0
   btfss  TOSL,0
   goto nozerobitintosl
   push
   pop
   btfss TOSL,0
   goto nozerobitonstack
   bcf    TOSL,0
   btfsc TOSL,0
   goto nozerobitintosl
   push
   pop
   btfsc TOSL,0
   goto nozerobitonstack
   pop

   ..tosl and stack support bit 0..

nozerobitontosl
   pop
   ..report error..

nozerobitonstack
   pop
   ..report error..

If TOSL does have a functional zero bit, then what does this do:

   push
   movlw    high(target)
   movwf    TOSH
   movlw    low(target)
   movwf    TOSL
   bsf          TOSL,0
   return

target:

My guess is PCL has no zero bit at all and this code will do nothing
strange. If that guess is correct, then we could use TOSL,0 as a 'stack
frame' bit variable in any function. It would automatically be preserved as
we call other functions or interrupts occur! Pretty cool!

Who wants to check this out? I'll gladly share credit for the idea with
anyone who researches/verifies it.

> But in either case, a hardcoded lookup table is not the way the compiler
will
> handle arbitrary function pointers. If you explicityly created an array of
> function pointers (hey C++ vtables !) and use an index to call one, then
the
> look up table would be easier for the compiler to generate.

This would make a lot of sense for an array of const function pointers
statically allocated and initialized.

I still like the idea of reducing a function pointer to a single byte, tho.
However the limitation to 64 or 128 or 256 'addressable' functions would
probably burn somebody, somewhere. (Remember, nobody ever said a pointer
(especially to a function) had to be a simple address. In some
architectures, functions are identified by 'descriptor number', which is
very close to this scheme).

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservspamspammitvma.mit.edu with SET PICList DIGEST in the body


2000\11\21@105704 by Walter Banks

picon face
>
> [Walter, what has happened to EC++?]
>
> Scott

Most of the technical parts are done. There were
several test implementations done mostly in Japan
including one for a 4 bitter just to be sure. The test
implementations were mostly proof of concept and
not designed to be production compilers. The
current EC++ spec's are on the WEB.

Many of the additions in ISO 9899 the international
C standard adopted by ANSI in April are designed to
build a path between C and C++.  New data type
support and "//" comments for example. The ISO
member countries agreed that the embedded
C standards when adopted would be compatible with
C++.

Walter Banks

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservEraseMEspammitvma.mit.edu with SET PICList DIGEST in the body


2000\11\22@192358 by Clyde Stubbs

flavicon
face
On Sun, Nov 19, 2000 at 09:29:27PM -0500, Bob Ammerman wrote:
> I should think an indirect function call would be TRIVIAL on an 18C and
> rather difficult on other PIC processors:

The problem arises because you want to have stuff in W, i.e. a parameter,
but you can't use movff to write to pcl, so your
solution ends up being the only way, but you still have to push a
return address beforehand, and load the parameter into W just
before the return, so it ends up messy and uses two stack levels
instead of one.

On the 16C devices you just write pclath then pcl, though W still
has to be taken care of, on the 17C it's trivial since you can
write PCL with movfp, without affecting W.

If you use movff to write to PCL, it works on the emulator, but
on the simulator the PC is incremented *after* it is written. The manual
does say not to do it.

Cheers, Clyde

--
Clyde Stubbs                     |            HI-TECH Software
Email: RemoveMEclydeEraseMEspamspam_OUThtsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger @spam@clydeRemoveMEspamEraseMEhtsoft.com   | AUS: +61 7 3355 8333 +61 7 3355 8334
---------------------------------------------------------------------------
HI-TECH C: compiling the real world.

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspam@spam@mitvma.mit.edu


2000\11\22@192558 by Clyde Stubbs

flavicon
face
On Mon, Nov 20, 2000 at 09:50:14AM -0500, Bob Ammerman wrote:
>
> btw: the best way I can figure to handle function pointers on 16C devices is
> to have the compiler/linker build a goto table of all functions whose
> address is ever taken. Then a pointer to a function simply becomes an index
> into that table.

That's actually something like what we do on the 16C. And it is exactly what
is done for return addresses on the 12C, to avoid having to use the stack.

Clyde

--
Clyde Stubbs                     |            HI-TECH Software
Email: @spam@clydespam_OUTspam.....htsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger spamBeGoneclydeEraseMEspamhtsoft.com   | AUS: +61 7 3355 8333 +61 7 3355 8334
---------------------------------------------------------------------------
HI-TECH C: compiling the real world.

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamBeGonespammitvma.mit.edu


2000\11\22@194250 by Clyde Stubbs

flavicon
face
On Mon, Nov 20, 2000 at 11:20:11AM -0000, Alan B. Pearce wrote:
> So surely it is up to the compiler writer to remove the confusion by reporting
> in the same units each time? :) (I do appreciate the occupation of the

Yes, each compiler is consistent, always reports in the same units. But
the 16C memory is word addressed, the 18C is byte addressed. IT's an
actual hardware difference. The compiler reflects that.


--
Clyde Stubbs                     |            HI-TECH Software
Email: RemoveMEclyde@spam@spamspamBeGonehtsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger .....clyde@spam@spamEraseMEhtsoft.com   | AUS: +61 7 3355 8333 +61 7 3355 8334
---------------------------------------------------------------------------
HI-TECH C: compiling the real world.

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestRemoveMEspammitvma.mit.edu


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