Searching \ for '[PIC] Starting with C' 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/languages.htm?key=c
Search entire site for: 'Starting with C'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Starting with C'
2008\07\22@003324 by threewheeler7

picon face

i have worked very little with the c language, and not at all with it for the
pic. it just was not practical last time i was going to use it, but now it
is and i want in on it. i want some input on a good compiler and a good
place to start learning C for the pic.
--
View this message in context: www.nabble.com/Starting-with-C-tp18582188p18582188.html
Sent from the PIC - [PIC] mailing list archive at Nabble.com.

2008\07\22@004801 by Vitaliy

flavicon
face
threewheeler7 wrote:
> i have worked very little with the c language, and not at all with it for
> the
> pic. it just was not practical last time i was going to use it, but now it
> is and i want in on it. i want some input on a good compiler and a good
> place to start learning C for the pic.

First, I would suggest finding a good book on C. I prefer textbook-style
books, my favorite is:

"A First Book of ANSI C: Fundamentals of C Programming" by Gary J. Bronson
and Stephen J. Menconi

Amazon has it listed for $0.01. It's old, but the C language hasn't changed
much since then, and I find myself referring to it from time to time.

Microchip's C18 and C30 compilers are very good, and more than adequate for
what you want.

Vitaliy

2008\07\22@141559 by nfml

picon face

Hi,

I do all my pic programming in C language. To compile C code I recommend CCS
compiler.
The hard topics on C programming are pointers... in the PIC I don't advice
their use because most PIC's have limited RAM.
So a basic knowledge of C is sufficient for PIC C programming.
Here are some useful links that I use for learning and improving C
programming:

http://www2.its.strath.ac.uk/courses/c/

http://www.acm.uiuc.edu/webmonkeys/book/c_guide/index.html

http://www.cs.cf.ac.uk/Dave/C/






threewheeler7 wrote:
>
> i have worked very little with the c language, and not at all with it for
> the pic. it just was not practical last time i was going to use it, but
> now it is and i want in on it. i want some input on a good compiler and a
> good place to start learning C for the pic.
>

--
View this message in context: www.nabble.com/Starting-with-C-tp18582188p18595539.html
Sent from the PIC - [PIC] mailing list archive at Nabble.com.

2008\07\22@182330 by Tomás Ó hÉilidhe

picon face
nfml wrote:
> I do all my pic programming in C language. To compile C code I recommend CCS
> compiler.


I've been using the PIC C compiler and find it fantastic.


>  
> The hard topics on C programming are pointers... in the PIC I don't advice
> their use because most PIC's have limited RAM.
>  


Let's pretend I agree with you that you shouldn't use pointers on a PIC,
well here's my question:
   If you find a problem that can be solved using pointers, what
alternative method would you use?

And don't tell me array indexing, because object[index] is equal to
*(object+index), which involves a pointer. If you don't believe me then
try writing index[object] instead of object[index].

And why should limited RAM affect your choice of using pointers? What's
a pointer on a PIC, 8 bits or 16 bits, something like that? It's hardly
gigantic.


{Quote hidden}

Be very weary of C tutorials on the internet. I've never found one that
didn't contain at least one error.

2008\07\22@191801 by Tamas Rudnai

face picon face
> And why should limited RAM affect your choice of using pointers? What's
> a pointer on a PIC, 8 bits or 16 bits, something like that? It's hardly
> gigantic.

One pointer is not a big deal in terms of memory usage. But if you use it
for everything then it is. If you have 24 bytes RAM in a 10F202 then you
would think it over twice or twenty times to use 16 different pointers or do
something else, right? ;-) Also it is quite problematic how a pointer can be
implemented on mid-range PICs for both RAM and ROM, so it also involved with
speed and program memory usage as well.

> Be very weary of C tutorials on the internet. I've never found one that
> didn't contain at least one error.

We desperately need an error free one, so when will you start working on it?
;-)

Tamas




On Tue, Jul 22, 2008 at 11:23 PM, Tomás Ó hÉilidhe <spam_OUTtoeTakeThisOuTspamlavabit.com> wrote:

{Quote hidden}

>

2008\07\22@200059 by Tomás Ó hÉilidhe

picon face
Tamas Rudnai wrote:
> One pointer is not a big deal in terms of memory usage. But if you use it
> for everything then it is. If you have 24 bytes RAM in a 10F202 then you
> would think it over twice or twenty times to use 16 different pointers or do
> something else, right? ;-) Also it is quite problematic how a pointer can be
> implemented on mid-range PICs for both RAM and ROM, so it also involved with
> speed and program memory usage as well.
>  


But what I'm trying to say is that you won't find a better way of doing
it. Pointers have a purpose and they're great at what they do.

I'll draw a very crude analogy:
   If you find a problem for which a torque wrench would be a good
solution then I don't think you'll find anything better than torque
wrench for the job. If pointers are suitable for a job, then they tend
to be the best solution.

Just as how a double is used for storing a floating-point number, and an
int is used for storing an integer, I see pointers as just being used to
store a memory address. If you're doing something like using a loop to
iterate through memory, then surely a pointer is the way to go. I'd
shrivel up and die if I didn't have pointers... which is why I claim
that the Java programming language is for little girls.


>> Be very weary of C tutorials on the internet. I've never found one that
>> didn't contain at least one error.
>>    
>
> We desperately need an error free one, so when will you start working on it?


Actually some years back I was foolish enough to write a beginner's C
tutorial for extremely poor pay. I was 16 and RentACoder sounded cool,
give me a break. And I'm short-sighted enough already, I don't need to
spend time working on a book! I used to have brilliant vision about 3
years ago but I can't read car registration plates from across the road
anymore >:( My opthalmist says it's as a result of eye strain. Hopefully
when I move over to Thailand it'll improve and maybe even come back to
normal. Thankfully though my eyes are fine other than that, supposedly I
even have low pressure in my eyes which is a good thing :-D

2008\07\22@210507 by cdb

flavicon
face


:: But what I'm trying to say is that you won't find a better way of
:: doing
:: it. Pointers have a purpose and they're great at what they do.

The main problem (pic limitations aside) is that the concept is often
taught poorly, a case of brilliant minds not being able to talk to the
'little people'

In the case of Pic's, I think pointers are much easier to understand,
if simple demonstration code is written, and then the 'newbie' can
trace what is happening in the ASM code.

It gets more difficult, when the great pointer users of their time,
start pointing to pointers, and pointing to functions. Again though,
have a small code snippet that someone can trawl through the resultant
assembly, and an explanation of why it is better to do it that way,
would help the beginner, I believe.

I reccomend the little book (quite inexpensive, if NOT purchased
through Farnell) by Nigel Gardner of Bluebird Electronics - PIC C. It
only deals with simple code, but as a primer it is quite good I think.
There is also a free download C programming guide from FORED, which
starts off fine, but does get a little confusing towards the end.

Colin
--
cdb, .....colinKILLspamspam@spam@btech-online.co.uk on 23/07/2008

Web presence: http://www.btech-online.co.uk  

Hosted by:  http://www.1and1.co.uk/?k_id=7988359







2008\07\22@213915 by Tomás Ó hÉilidhe

picon face


cdb wrote:
> The main problem (pic limitations aside) is that the concept is often
> taught poorly, a case of brilliant minds not being able to talk to the
> 'little people'
>  


You can't attack a brilliant tool because of the way in which a
*particular* institution teaches it, even if a hell of a lot of
institutions teach it poorly. I'm sure somebody could make an absolute
dog's dinner of explaining how a torque wrench is used, but that doesn't
make a torque wrench any less brilliant of a tool.

Pointers can be a little tricky at first... but then again so is
learning to walk. Once you get the hang of pointers they become second
nature.

My first introduction to pointers was in the book "C++ for Dummies", and
I thought the explanation was great. I really got a feel for them though
when I started to use them, got practise. Sometimes I opened up Excel to
draw a sort of diagram of memory in order to understand what was happening.


> It gets more difficult, when the great pointer users of their time,
> start pointing to pointers, and pointing to functions.


There are great uses for things like pointers to pointers, and also for
function pointers. They might seem daunting at first, like a baby trying
to understand spoken language, but you get there.

#include <stdio.h>

void SayYellow(void) { printf("yellow"); }
void SayBlue(void) { printf("blue"); }
void SayGreen(void) { printf("green"); }

void (*const array_of_func_pointers[3])(void) = { SayYellow, SayBlue,
SayGreen };

int main(void)
{
   unsigned i;

   printf("Please pick an option:\n\n"
          "0. The colour beginning with Y\n"
          "1. The colour beginning with B\n"
          "2. The colour beginning with G\n\n"
          "Make your choice: ");

   scanf("%u", &i);

   array_of_func_pointers[i]();   /* Take the array of function pointers,
                                                    use an index to get
a function pointer on its own,
                                                    then use
parentheses to invoke a function call with no arguments */

   return 0;
}

2008\07\22@220130 by nfml

picon face



Tomás Ó hÉilidhe-2 wrote:
{Quote hidden}

If you malloc or calloc a variable using pointers is exactly the same as
arrays.
you can even access pointers value like arrays: object[index]...
So what is the main difference?

In arrays you can not change the size, pointers you may.
I´ve been programming pic 16F7877A in C and I'm making an interface in C++
for windows to use a PIC for signal generation and signal acquisition.
Basically I'm building a signal generator and an oscilloscope all in one for
students learning. (main purpose: very cheap) Its true I can not live
without pointers but it is also true that they are the cause of most bugs.

the original topic was a question for BASIC C programming on a PIC. Pointers
take a long learning time, and in the begging (newbie) you are constantly
trying to access(read or write) memory that it is not yours resulting in one
segmentation fault after another.

I think your (you and most pic mailing list users) will to show great
knowledge sometimes confuses the person who posted the question. Pointers
are definitely the best tool for programming and you can do everything with
them... but they are advanced programming. First learn to walk and only then
I may try to run... as we commonly say in Portugal: "try  explaining it to
me as if I was a 5 year old child..."




--
View this message in context: www.nabble.com/Starting-with-C-tp18582188p18602479.html
Sent from the PIC - [PIC] mailing list archive at Nabble.com.

2008\07\22@221351 by Spehro Pefhany

picon face
At 06:23 PM 7/22/2008, you wrote:
{Quote hidden}

Indeed. One should be very *wary* as well. ;-)

>Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
speffspamKILLspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com



2008\07\23@005410 by Vitaliy

flavicon
face
Tomás Ó hÉilidhe wrote:
> nfml wrote:
>> I do all my pic programming in C language. To compile C code I recommend
>> CCS
>> compiler.
>
> I've been using the PIC C compiler and find it fantastic.

Microchip's compilers sometimes produce some silly-looking, inefficient
assembly (search the archives to learn more), and their MPLAB IDE has even
sillier bugs, but I concur that the C18/C30 compilers are more than adequate
for hobby programming, and even production code.

Vitaliy

2008\07\23@005411 by Vitaliy

flavicon
face
nfml wrote:
> The hard topics on C programming are pointers...

This statement seems to be "common knowledge", although I sometimes doubt
its validity. While I admit that it took me a while to become comfortable
using pointers, in retrospect they aren't that scary. A friend once said
that for a long time he could not believe how simple the pointers really
are, because they are considered such an advanced programming concept.

I think initially, most people have difficulty understanding what is the
point of using pointers. All it takes is a little bit of explanation, the
book I referenced previously does a great job of explaining what pointers
are and how they're useful.

> in the PIC I don't advice
> their use because most PIC's have limited RAM.

As Tomas has already pointed out, amount of available RAM is irrelevant --  
you just need enough bits to store one memory address. In some cases,
pointers actually conserve RAM because the pointer is smaller than the
variable it is pointing to.

Vitaliy

2008\07\23@042512 by Alan B. Pearce

face picon face
>> The main problem (pic limitations aside) is that the concept is often
>> taught poorly, a case of brilliant minds not being able to talk to the
>> 'little people'
>
>You can't attack a brilliant tool because of the way in which a
>*particular* institution teaches it,

I don't believe he did, and I see nothing in what you quoted that says he
did. If anything he is putting the same point as you.

2008\07\23@042856 by Alan B. Pearce

face picon face
>>Be very weary of C tutorials on the internet. I've never found one that
>>didn't contain at least one error.
>
>Indeed. One should be very *wary* as well. ;-)

Well I would be very wary of anyone claiming that ...
>I've been using the PIC C compiler and find it fantastic.

when I thought these were generally regarded as not ANSI compliant.

2008\07\23@060334 by Xiaofan Chen

face picon face
On Wed, Jul 23, 2008 at 4:28 PM, Alan B. Pearce <.....A.B.PearceKILLspamspam.....rl.ac.uk> wrote:
> Well I would be very wary of anyone claiming that ...
>>I've been using the PIC C compiler and find it fantastic.
>
> when I thought these were generally regarded as not ANSI compliant.
>

I am not an C expert. John Temples should be able to answer the
question with authority.

Anyway, I believe HiTech PICC/PICC18 are quite compliant to ANSI
standard (C89) with some exceptions and the exceptions are well
documented. Microchip C18 is mostly ANSI C89 compliant with
some exception and the exceptions are again well documented.

An comparison of PICC18 and C18 from John Temples:
http://www.xargs.com/pic/picc18-vs-c18.html

Microchip C30 and C32 are both based on GCC and they should be
complaint to C89.

Xiaofan

2008\07\23@072637 by Alan B. Pearce

face picon face
>>>I've been using the PIC C compiler and find it fantastic.
>>
>> when I thought these were generally regarded as not ANSI compliant.
>>
>
>I am not an C expert. John Temples should be able to answer the
>question with authority.
>
>Anyway, I believe HiTech PICC/PICC18 are quite compliant to ANSI
>standard (C89) with some exceptions and the exceptions are well
>documented. Microchip C18 is mostly ANSI C89 compliant with
>some exception and the exceptions are again well documented.

<VBG> I can see that my dry humour has perhaps passed you, as a non-English
person, by. I was rather attempting to poke fun at the OP, who has recently
been 'correcting' (I use that word advisedly) some things people have been
saying on this list about C compilers that produce code for embedded micros,
and the ANSI compatibility of said compilers. Yet here that same person is
saying that they are 'fantastic' despite the items that are not ANSI
compliant.

But I do take your point that most such compilers are 'mostly' compliant.

2008\07\23@081606 by Walter Banks

picon face


Xiaofan Chen wrote:

> Microchip C30 and C32 are both based on GCC and they should be
> complaint to C89.

GCC has not gone to any particular effort to be compliant with the
IEC/ISO standards.

Walter..


2008\07\23@092639 by Tomás Ó hÉilidhe

picon face


Walter Banks wrote:
> GCC has not gone to any particular effort to be compliant with the
> IEC/ISO standards.
>  

gcc is 100% compliant. Here's how I myself use it:

gcc main.c -D NDEBUG -ansi -pedantic -Wall -O3 -s -o main.exe

* Defines NDEBUG
* Makes sure the code is ANSI-compliant
* Enables all warnings
* Sets the highest optimisation level
* Strips redundant crap from the executable

2008\07\23@101327 by Jan-Erik Soderholm

face picon face
Tomás Ó hÉilidhe wrote:

> gcc is 100% compliant. Here's how I myself use it:
>
> gcc main.c -D NDEBUG -ansi -pedantic -Wall -O3 -s -o main.exe

Realy ?
To build PIC code ???

2008\07\23@101431 by Walter Banks

picon face


Tomás Ó hÉilidhe wrote:

{Quote hidden}

Not to put too sharp a point on this, "Which conformance test suite
has been run on GCC which version of GCC and where are the results?"

My experience has been that FSF has gone out of their way to
not be part of the standardization process for C and that includes
conformance testing.


Regards,

--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com
EraseMEwalterspam_OUTspamTakeThisOuTbytecraft.com Canada




2008\07\23@102319 by Tomás Ó hÉilidhe

picon face


Jan-Erik Soderholm wrote:
>> gcc is 100% compliant. Here's how I myself use it:
>>
>> gcc main.c -D NDEBUG -ansi -pedantic -Wall -O3 -s -o main.exe
>>    
>
> Realy ?
> To build PIC code ???


Yes, Jan-Erik, to build PIC code. Every day. Even on Saturdays.
Sometimes on Sunday, depending if it's sunny out.

2008\07\23@103843 by Walter Banks

picon face


"Alan B. Pearce" wrote:

{Quote hidden}

Many (including ours) are compliant where ever is practical. This leads
to many things that are compromises.

For us this means that int size defaults to 8 bits but 16 bits are available
for compatibility. There are open issues on floating point support for most
embedded C compilers.

I worked on a project at ISO on C standards for embedded systems
to deal with the specific issues of C on non hosted processors including
the PIC famillies. This document (IEC/ISO 18037)  deals with common
embedded system extensions and unified solutions.

In general terms it covers
 Multiple address spaces found in most Harvard architecture processors
    (Microchip PICs)

 User defined address spaces. (Data in a I2C memory for example)
   User defined address space can handle a number of hard issues
   including I/O ports that have asymmetrical behaviour (reads and writes
   reference separate things) EEProm reads are the same as ROM writes
   require software function support.

 Fixed point math data types fract and accum As our compilers get
    updated we are releasing them with fixed point transcendental function
    library.

 Full low level access to the processor registers
    if( CC.C == 1) ... for example
   Even stranger q =  r + o + CC.C;

This last point finally put to rest many of the issues between what is
possible in C vs what is possible in asm. Anything that can be written
in asm can be written in C in the same or less space.



Regards,

--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com
walterspamspam_OUTbytecraft.com





2008\07\23@112044 by Joe Bento

face
flavicon
face
Wow.  If you use gcc to compile PIC code and generate a hex file, you
stand to make millions!

Joe


Tomás Ó hÉilidhe wrote:
{Quote hidden}

2008\07\23@112301 by Andre Abelian

flavicon
face
I asked same question long time ago when I was good at asm only and
I got totally confused because of there are some asm experts on this
list
That can do fantastic job with asm and they never agree to use some
thing
Else other then asm. I started using Hi-tech then CCS C I never went
back to asm and I kind of forgot about it.

1. download or buy c book and get basic understanding
2. download http://www.fored.co.uk/html/learn_c_with_fed.htm
  It has examples
3. the rest is experience. You can't learn fast. First you are going to
hate C then after you learned you are going to hate asm forever.

I personally use CCS C. Excellent support. By the way all compilers have
bugs so do not waist your time look for no bug compiler there is no such
a thing. My last project I ended up with about 8500 line of code worked
fine.
I never needed to worry about banks or flags.
 

Andre    




{Original Message removed}

2008\07\23@114530 by Timothy Weber

face picon face
No, no.  See his command line - clearly he's running an EXE on a PIC
instead.

Joe Bento wrote:
{Quote hidden}

--
Timothy J. Weber
http://timothyweber.org

2008\07\23@121339 by sergio masci

flavicon
face
part 1 1242 bytes content-type:TEXT/PLAIN; charset=UTF-8 (decoded quoted-printable)



On Tue, 22 Jul 2008, Tomás Ó hÉilidhe wrote:

> Let's pretend I agree with you that you shouldn't use pointers on a PIC, > well here's my question:
>     If you find a problem that can be solved using pointers, what > alternative method would you use?
> > And don't tell me array indexing, because object[index] is equal to > *(object+index), which involves a pointer. If you don't believe me then > try writing index[object] instead of object[index].

really? so a compiler would treat the following as equivalent?

int        j;
float        arr[10];

arr[j] = j;

j[arr] = j

> > And why should limited RAM affect your choice of using pointers? What's > a pointer on a PIC, 8 bits or 16 bits, something like that? It's hardly > gigantic.

Actually it's not the fact that the pointer only occupies 16 bits that's the problem, it's the number of instructions needed to compute a pointer and leave it in the FSR / IRP that is the problem. Use pointers indescriminately on a PIC and watch your code space vanish and execution speed plumit.

Yes you do need to use pointers because that's how you pass arrays as arguments to functions.

Regards
Sergio Masci

part 2 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2008\07\23@140528 by =?UTF-8?B?VG9tw6FzIMOTIGjDiWlsaWRoZQ==?= n/a

picon face


sergio masci wrote:
> really? so a compiler would treat the following as equivalent?
>
> int        j;
> float        arr[10];
>
> arr[j] = j;
>
> j[arr] = j
>  


Put the following through your compiler:

int main(void)
{
   int arr[6];

   arr[2] = 788;

   2[arr] = 788;
}

2008\07\23@150420 by Tamas Rudnai

face picon face
Hang on a minute!

> Put the following through your compiler:
>
> int main(void)
> {
>   int arr[6];
>   arr[2] = 788;
>   2[arr] = 788;
> }

Without checking any PIC compilers I am telling you that you _could_ compile
this without any pointers involved. Why? Because in midrange and 18F there
is no real software stack and someone may can cheat with the local variables
and use overlayed data area instead of stack, then as the address of 'arr'
is well know at compilation time it can easily calculate the address of
arr[2] so there is no need to involve any pointer aritmetics here - with
PICs it does make difference in both code size and execution speed as well.
It may or may not being used by C compilers for PIC, maybe only with
sophisticated optimalization switched on (you may ask people here who are
developing C compilers for PIC if it could be done - like Matt from Hi-Tech
or Walter frm ByteCraft or even Wouter I think relevant on this subject with
his JAL compiler and I am pretty sure Olin has a good experteese on modular
development in assembly level plus knowledge on compiler technology). I did
not say anyone actually doing this, I only say it _can_be_done_.

Tamas




On Wed, Jul 23, 2008 at 7:05 PM, Tomás Ó hÉilidhe <@spam@toeKILLspamspamlavabit.com> wrote:

{Quote hidden}

>

2008\07\23@154311 by Michael Rigby-Jones

picon face
>
> > Put the following through your compiler:
> >
> > int main(void)
> > {
> >   int arr[6];
> >   arr[2] = 788;
> >   2[arr] = 788;
> > }

> {Original Message removed}

2008\07\23@154741 by sergio masci

flavicon
face
part 1 655 bytes content-type:TEXT/PLAIN; charset=UTF-8 (decoded quoted-printable)



On Wed, 23 Jul 2008, Tomás Ó hÉilidhe wrote:

{Quote hidden}

Yep, you're right it works. Even the example I gave above works :-(
I'm shocked that the compiler didn't give an error.

Regards
Sergio Masci

part 2 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2008\07\23@155354 by Michael Rigby-Jones

picon face


> -----Original Message-----
> From: KILLspampiclist-bouncesKILLspamspammit.edu [RemoveMEpiclist-bouncesTakeThisOuTspammit.edu] On Behalf
> Of Tomás Ó hÉilidhe
> Sent: 22 July 2008 23:23
> To: Microcontroller discussion list - Public.
> Subject: Re: [PIC] Starting with C
>
>
> And don't tell me array indexing, because object[index] is equal to
> *(object+index), which involves a pointer. If you don't believe me then
> try writing index[object] instead of object[index].

object[index] is NOT equivalent to *(object+index) unless you happen to be only using objects that are the same size as the data width of the target.

index[object] instead of object[index] is likewise doomed to failure unless sizeof(index) == sizeof(object[0])


Off the top of my head *(object + ( index * sizeof(object[0]))) would seem to be equivalent to an array index.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2008\07\23@162147 by Tomás Ó hÉilidhe

picon face


Michael Rigby-Jones wrote:
> object[index] is NOT equivalent to *(object+index) unless you happen to be only using objects that are the same size as the data width of the target.
>  


It is indeed equivalent, in exactly the same way as "5 + 2" is
equivalent to "2 + 5".

When you write arr[5], it's exactly the same as writing *(arr + 5).
Therefore there's no reason why you shouldn't be able to write *(5 +
arr), which is why you can write 5[arr] instead of arr[5].


> index[object] instead of object[index] is likewise doomed to failure unless sizeof(index) == sizeof(object[0])
>
>
> Off the top of my head *(object + ( index * sizeof(object[0]))) would seem to be equivalent to an array index.


You're forgetting something about pointer arithmetic in C:  When you do
arithmetic with a pointer, the arithmetic is based on the size of the
type. For instance:

   int *p = &whatever;

   p += 4;  /* This advances the pointer by four times the size of an
int */


   double *p = &something_other_variable;

   p += 4;  /* This advances the pointer by four times the size of a
double */

So, to summarise, arr[5] is equal to 5[arr] in every conceivable
context, with every kind of type.

2008\07\23@162516 by William \Chops\ Westfield

face picon face
This deep discussion on ansi compliance, and weird corners of C, and  
even of pointers, is really quite a disservice to the original  
poster, who is asking about STARTING to use C.

I would say, get an arduino and its IDE (which is an AVR, but never  
mind), or it's big-system brother "Processing" and start by using the  
SUBSET of C that they document for their users...  Look at the  
examples, and what others have done with it.  Translate them to PIC,  
if you want, using one of the "free sample" C compilers...

BillW

2008\07\23@163108 by William \Chops\ Westfield

face picon face

>> If you use gcc to compile PIC code and generate a hex file, you
>> stand to make millions!

Don't be so ... quick to react.  Aren't the DSPIC, PIC24, and PIC32  
compilers from Microchip all "gcc" ?

BillW

2008\07\23@170527 by =?UTF-8?B?VG9tw6FzIMOTIGjDiWlsaWRoZQ==?= n/a

picon face


sergio masci wrote:
> Yep, you're right it works. Even the example I gave above works :-(
> I'm shocked that the compiler didn't give an error.


On the other hand, it is nice to be assured that:

   arr[5]

is treated *exactly* as if you'd written:

   *(arr + 5)

I believe someone has exploited this feature in their code before... emm
let me think if I can remember what he did... maybe something like:

#define printer 1
#define mouse 2
#define screen 3

int is_connected[3];

printer[is_connected] = 1;
mouse[is_connected] = 2;
screen[is_connected] = 3;

2008\07\23@172131 by Gerhard Fiedler

picon face
Michael Rigby-Jones wrote:

>> And don't tell me array indexing, because object[index] is equal to
>> *(object+index), which involves a pointer. If you don't believe me then
>> try writing index[object] instead of object[index].
>
> object[index] is NOT equivalent to *(object+index) unless you happen to
> be only using objects that are the same size as the data width of the
> target.
>
> index[object] instead of object[index] is likewise doomed to failure
> unless sizeof(index) == sizeof(object[0])
>
> Off the top of my head *(object + ( index * sizeof(object[0]))) would
> seem to be equivalent to an array index.

Ouch... :)

>From C89:
--------------------------------------------------
3.3.6 Additive operators
[...]
When an expression that has integral type is added to or subtracted from a
pointer, the integral value is first multiplied by the size of the object
pointed to.  The result has the type of the pointer operand.  If the
pointer operand points to a member of an array object, and the array object
is large enough, the result points to a member of the same array object,
appropriately offset from the original member.  Thus if P points to a
member of an array object, the expression P+1 points to the next member of
the array object.
--------------------------------------------------

Basically: object[index] is (mostly) equivalent to *(object+index). And
multiplying the index with sizeof(member) probably won't result in what you
want.

Gerhard

2008\07\23@172841 by Gerhard Fiedler

picon face
Vitaliy wrote:

>> in the PIC I don't advice their use because most PIC's have limited RAM.
>
> As Tomas has already pointed out, amount of available RAM is irrelevant
> -- you just need enough bits to store one memory address. In some cases,
> pointers actually conserve RAM because the pointer is smaller than the
> variable it is pointing to.

But there is a difference. When you look at something like Java (on a PC),
pretty much everything is a pointer (under the hood), and accessing a value
through a handful of redirections is not too rare. Coding like this (as a
rather extreme case) is not really that helpful on the smaller PICs.
Sometimes pointers help conserve RAM, but they are not very code efficient
in their implementation due to the assembly limitations.

Gerhard

2008\07\23@174250 by Tomás Ó hÉilidhe

picon face


Gerhard Fiedler wrote:
> But there is a difference. When you look at something like Java (on a PC),
> pretty much everything is a pointer (under the hood), and accessing a value
> through a handful of redirections is not too rare. Coding like this (as a
> rather extreme case) is not really that helpful on the smaller PICs.
> Sometimes pointers help conserve RAM, but they are not very code efficient
> in their implementation due to the assembly limitations.


I only two languages I use are C and C++.

Java's for little girls.

2008\07\23@190454 by Xiaofan Chen

face picon face
On Wed, Jul 23, 2008 at 11:16 PM, Joe Bento <spamBeGonejosephspamBeGonespamkirtland.com> wrote:
> Wow.  If you use gcc to compile PIC code and generate a hex file, you
> stand to make millions!

Not all PICs are equal. If you counter dsPIC/PIC24 and PIC32 as PICs,
then C30 and C32 are based on GCC compiler and you can generate hex
from gcc. Microchip does earn millions. But not many users of
C30 and C32. ;-)

And I remember once Scott Dattalo (who ported sdcc to PIC18)
mentioned he would started with gcc and not sdcc if he wanted
to do it again. He thought it is possible to port gcc to PIC18.
But now the open source efforts for PIC compiler is mainly
on sdcc so it does not make too much sense to start with
gcc again.

Xiaofan

2008\07\23@203231 by Dr Skip

picon face
> Java's for little girls.
>

I imagine C-man, built like Arnold, yelling "C is for the girlie-men!" in a
think Austrian or German accent...  ;)

2008\07\23@205727 by Apptech

face
flavicon
face
> I only two languages I use are C and C++.
>
> Java's for little girls.

You'd probably have a quie   ter life if you left off the
last line and similar. Ignoring any sexist overtones, the
logical flame path is that when they grow up they migrate to
eg C or C++ and that assembler is the only real language if
you are serious.

Of course [tm] real men, or really really big girls,
generate machine code in their head and toggle it in using
the console switches. Which is approximately how the real
but legendary Seymour Cray is reputed to have entered the
basic boot strap loader on an original CDC machine. His
evening hobby was pick and shovel excavation of an
underground tunnel from his basement to a not too nearby
park. Gave him exercise and thinking time I imagine.

Note that the elves and the tunnel comment below are
probably a little closer to reality than just plain whimsy.
Background mental processes can work marvels when one is
focused on some other task. If the task requires low mental
effort it may perhaps assist the process.


       Russell

_________________


       http://en.wikipedia.org/wiki/Seymour_Cray

Beyond the design of computers Cray led a "streamlined
life". He avoided publicity and there are a number of
unusual tales about his life away from work. He enjoyed
skiing, wind surfing, tennis and other sports. Another
favorite pastime was digging a tunnel under his home; he
once attributed the secret of his success to elves. "While
I'm digging in the tunnel, the elves will often come to me
with solutions to my problem."[6] German avant-garde
industrial band Einstürzende Neubauten cite Cray and his
tunnel as partial inspiration for their song Schacht von
Babel.

2008\07\23@210532 by Apptech

face
flavicon
face
> Which is approximately how the real but legendary Seymour
> Cray is reputed to have entered the basic boot strap
> loader on an original CDC machine. His evening hobby was
> pick and shovel excavation of an underground tunnel from
> his basement to a not too nearby park. Gave him exercise
> and thinking time I imagine.

AND:


"When asked what kind of CAD tools he used for the Cray-1,
Cray said that he liked #3 pencils with quadrille pads. Cray
recommended using the backs of the pages so that the lines
were not so dominant. When he was told that Apple Computer
had just bought a Cray to help design the next Apple
Macintosh, Cray commented that he had just bought a
Macintosh to design the next Cray.[5]"


       R

2008\07\23@212302 by Timothy J. Weber

face picon face
Apptech wrote:
> Of course [tm] real men, or really really big girls,
> generate machine code in their head and toggle it in using
> the console switches.

http://xkcd.com/378/
--
Timothy J. Weber
http://timothyweber.org

2008\07\24@002110 by Bob Blick

face
flavicon
face
Language wars are nothing anyone wants to see. Please don't start them.
I'd like to end this one right now, but short of putting a lot of people
on the moderated list, I'd like you to police yourselves and JUST STAY
QUIET.

Do not reply to this message.

Thank you.

-Bob


Toma's O' hE'ilidhe wrote:

> I only two languages I use are C and C++.
>
> Java's for little girls.
>

2008\07\24@032305 by William \Chops\ Westfield

face picon face

On Jul 23, 2008, at 6:22 PM, Timothy J. Weber wrote:

>> Of course [tm] real men, or really really big girls,
>> generate machine code in their head and toggle it in using
>> the console switches.

But God writes in LISP code...

www.songworm.com/lyrics/songworm-parody/EternalFlame.html
You can play streaming audio, or download an MP3, here:
  http://www.prometheus-music.com/roundworm.html
should you be so inclined.  Worth it, IMO.  Great song!

BillW

2008\07\25@185503 by sergio masci

flavicon
face


On Wed, 23 Jul 2008, Tamas Rudnai wrote:

{Quote hidden}

Ok, no one else has responded to this so I'll jump in.

What you say is correct, in this case 'arr' could be considered a constant
and 2 certainly is a constant so yes you could compute the address of
arr[2] at compile time and reference that direectly at run time. The
problem with C is that the underlying stack based model, combined with the
way pointers are passed around, the way source files are compiled into
seperate modules with minimal information common to each module through
header files, the way functions need to be re-enterent and have a
parameter passing protocol to deal with all kinds of problems - well all
this makes it very hard to do.

What you are advocating is the use of a static compile time stack instead
of a dynamic runtime stack.

> It may or may not being used by C compilers for PIC, maybe only with
> sophisticated optimalization switched on (you may ask people here who are
> developing C compilers for PIC if it could be done - like Matt from Hi-Tech
> or Walter frm ByteCraft or even Wouter I think relevant on this subject with
> his JAL compiler and I am pretty sure Olin has a good experteese on modular
> development in assembly level plus knowledge on compiler technology). I did
> not say anyone actually doing this, I only say it _can_be_done_.

The XCSB compiler uses a static stack and generates highly efficient
runtime executables. It has a lot in common with C but XCSB is not C.

It does track the use of pointers and arrays across function calls and can
optimise some pointer arithmetic to direct memory accesses. It can also
greatly reduce function call overheads by noticing when arguments to a
function dont change from call to call and in many cases embed the
argument directly into the function body. It does lots of other clever
things as well. All this means that there are restrictions on the language
that make it much more MCU friendly than C.

I could have made the grammer of XCSB resemble that of C and simply called
it C with restrictions, but hey I figured, why not try and address some of
things that lead to bad coding practice while I'm at it.


Regards
Sergio Masci

2008\07\26@095116 by Gerhard Fiedler

picon face
sergio masci wrote:

> On Wed, 23 Jul 2008, Tamas Rudnai wrote:
>>> int main(void)
>>> {
>>>   int arr[6];
>>>   arr[2] = 788;
>>>   2[arr] = 788;
>>> }

>> Without checking any PIC compilers I am telling you that you _could_ compile
>> this without any pointers involved. [...]

> What you say is correct, in this case 'arr' could be considered a
> constant ...

It /is/ a constant in C.

> and 2 certainly is a constant so yes you could compute the address of
> arr[2] at compile time and reference that direectly at run time.

I'm pretty sure most decent compilers optimize it to that.

> The problem with C is that the underlying stack based model, combined
> with the way pointers are passed around, the way source files are
> compiled into seperate modules with minimal information common to each
> module through header files, the way functions need to be re-enterent
> and have a parameter passing protocol to deal with all kinds of problems
> - well all this makes it very hard to do.

In general, yes. But in this case, arr is not passed around, it is a local
entity so no need to publish information about it to other compilation
units, main() doesn't have to be re-entrant... so in this case, as in many
others, these problems don't apply.

> What you are advocating is the use of a static compile time stack instead
> of a dynamic runtime stack.

I don't know how many compilers for smaller PICs use it, but for example
Hi-Tech's PICC uses a compiled stack. Main limitations are with re-entrancy
(not provided) and function pointers (some limitations), not with data
pointers.

Gerhard

2008\07\26@165605 by sergio masci

flavicon
face


On Sat, 26 Jul 2008, Gerhard Fiedler wrote:

{Quote hidden}

Only for the scope of the function call.

>
> > and 2 certainly is a constant so yes you could compute the address of
> > arr[2] at compile time and reference that direectly at run time.
>
> I'm pretty sure most decent compilers optimize it to that.

No adding the stack frame pointer?

{Quote hidden}

yes you can assume that about "main" because it is a very special case.
But focusing on "main" doesn't get you very far in terms of overall
optimisation.

>
> > What you are advocating is the use of a static compile time stack instead
> > of a dynamic runtime stack.
>
> I don't know how many compilers for smaller PICs use it, but for example
> Hi-Tech's PICC uses a compiled stack.

Really, I didn't know that. Is this documented anywhere?

> Main limitations are with re-entrancy
> (not provided) and function pointers (some limitations),

So do they have any special mechanism to do multitasking?

> not with data
> pointers.

Does this mean that a data pointer can handle both RAM and CODE space data
at the same time?

Regards
Sergio Masci

2008\07\26@183042 by Gerhard Fiedler

picon face
sergio masci wrote:

{Quote hidden}

arr itself is a constant (the base address of the array is an "rvalue" in C
speak) and can't be changed.

 int arr[6];
 arr = 0x1234; // Not legal C.

(FWIW, in this case, the scope of arr is main().)

>>> and 2 certainly is a constant so yes you could compute the address of
>>> arr[2] at compile time and reference that direectly at run time.
>>
>> I'm pretty sure most decent compilers optimize it to that.
>
> No adding the stack frame pointer?

Not sure what you mean exactly, but AFAIK, for most purposes C is defined
in terms of "observable effects", which in this case means that the whole
content of main() could be optimized away -- there's no guarantee that
arr[2] ever gets set to anything, because it doesn't create any observable
effect. Does a falling tree make a noise if nobody's there to hear it? :)

>>> What you are advocating is the use of a static compile time stack
>>> instead of a dynamic runtime stack.
>>
>> I don't know how many compilers for smaller PICs use it, but for example
>> Hi-Tech's PICC uses a compiled stack.
>
> Really, I didn't know that. Is this documented anywhere?

You find some information in their manual (for example, they describe the
call graph which contains information about the call tree and the
associated compiled stack), in the example code that installs with their
compiler (IIRC there is some code that shows how to interface to local
variables from assembler, which means accessing the compiled stack), in
their forums and probably on the net.

>> Main limitations are with re-entrancy (not provided) and function
>> pointers (some limitations),
>
> So do they have any special mechanism to do multitasking?

What do you mean with multitasking? Interrupts? You get a warning if you
call the same function from mainline code and interrupt code. You can
disable this warning if you know that this is ok. AFAIK the newer line of
"Pro" compilers is smart enough to create a separate copy of the function
if there is a conflict, and call one copy from the mainline and the other
from the interrupt.

>> not with data pointers.
>
> Does this mean that a data pointer can handle both RAM and CODE space
> data at the same time?

Yes. How exactly that works depends on the PIC family and the type of
compiler (standard or pro). But basically you have the 8 bit RAM-only
pointers and the 16 bit RAM and code pointers. AFAIK the pro compilers know
which pointer type to use (because they scan the whole program, and with
this do away with the limitations standard C has due to the separate
compilation units); with the standard compilers you have to specify which
one you want a pointer to be.

Gerhard

2008\07\27@064406 by sergio masci

flavicon
face


On Sat, 26 Jul 2008, Gerhard Fiedler wrote:

{Quote hidden}

You may not be able to assign a value to "arr" from within C but that
doesn't mean the address of "arr" is a constant at run time. The address
of "arr" is set on entry to the function and may change from one
invokation to another. Almost every compiler I have used (and that's
a few now :) treats a local as an offset from the run time stack frame
pointer.

Yes these compilers do optimise "arr[2]" to something like:

p = stack_frame_pointer + (#arr + 2)

where "#arr + 2" is computed at compile time but "stack_frame_pointer" is
a dynamic variable the value of which is only known at run time.

This is one reason why the PIC is seen as so C unfriendly, because (until
MChip made changes to the way FSR could be used) the PIC did not an
index+offset addressing mode, only an indirect mode. The index+offset
addressing mode lets you do away with the "stack_frame_pointer+"
operation.

{Quote hidden}

Come on you can't base a function optimisation argument on what happens in
"main"

{Quote hidden}

Thanks, I'll have a look.

{Quote hidden}

XCSB has been doing this for years :-)

By multitasking what I meant was running the code as seperate interacting
tasks. This is easy when you use a dynamic stack but much much harder when
you use a static stack.

{Quote hidden}

XCSB is much stricter about the address space the pointer is pointing to
but it also supports function overloading so it is easy to have two
function with the same name where one is optimised for RAM access and the
other is optimised for CODE access. And if the idea of maintaining two
versions of the same function disturbs you, then you can encapsulate the
common parts in inline functions :-)

Regards
Sergio Masci

2008\07\27@084215 by Tomás Ó hÉilidhe

picon face


sergio masci wrote:
> This is one reason why the PIC is seen as so C unfriendly, because (until
> MChip made changes to the way FSR could be used) the PIC did not an
> index+offset addressing mode, only an indirect mode. The index+offset
> addressing mode lets you do away with the "stack_frame_pointer+"
> operation.


Is it not a very small minority of machines that have a "index+offset"
address mode? Let's say you want to set every element of an array to 77,
well it's a commonly held belief that the following code is faster:

   char unsigned *p = arr;

   char unsigned const *const pover = arr + (sizeof(arr) / sizeof(*arr));

   do *p++ = 77;
   while (pover != p);

And here's the alternative:

   char unsigned i = 0;

   do arr[i++] = 77;
   while (  (sizeof(arr) / sizeof(*arr)     !=     i  );

2008\07\27@114610 by sergio masci

flavicon
face
part 1 2516 bytes content-type:TEXT/PLAIN; charset=UTF-8 (decoded quoted-printable)



On Sun, 27 Jul 2008, Tomás Ó hÉilidhe wrote:

> > > sergio masci wrote:
> > This is one reason why the PIC is seen as so C unfriendly, because (until > > MChip made changes to the way FSR could be used) the PIC did not an > > index+offset addressing mode, only an indirect mode. The index+offset > > addressing mode lets you do away with the "stack_frame_pointer+" > > operation.
> > > Is it not a very small minority of machines that have a "index+offset" > address mode?

No, I'd say it is the other way around.

Off the top of my head:
*** index+offset (or base+index etc)
6502
6800
68hc11
6301
6812
6301
6809
68000
tms9900
msp430
TLCS900
C39
32032
x86
TMS7000
ARM
z80
Z8
Z800
z8000
z80k
NSC800

*** indirect only
8080
PIC
T414
8051


> Let's say you want to set every element of an array to 77, > well it's a commonly held belief that the following code is faster:
> >     char unsigned *p = arr;
> >     char unsigned const *const pover = arr + (sizeof(arr) / sizeof(*arr));
> >     do *p++ = 77;
>     while (pover != p);
> > And here's the alternative:
> >     char unsigned i = 0;
> >     do arr[i++] = 77;
>     while (  (sizeof(arr) / sizeof(*arr)     !=     i  );

which is similar to

    char unsigned i = (sizeof(arr) / sizeof(*arr);
     do arr[--i] = 77;
    while (  i != 0 );

which optimises very well (on a CPU that has index+offset addressing) if you want to do something a little less trivial such as:

   do i--;
      arr[i] = arr[i+1];
   while ( i != 0 );

or even

   do i--;
      arr1[i] = arr2[i];
   while ( i != 0 );


Also consider that the condition
   ((sizeof(arr) / sizeof(*arr) != i)
in many cases needs to be a multi precision comparison on a PIC whereas in a lot of cases an index could be less than 256 (in the above example the comparison actually reduces down to a simple "test if zero")

Anyway before someone jumps on me for mixing the meaning of index+offset from my previous post (where the offset was a small constant e.g. the offset of the array relative to the stack frame, and the index was actually the value of the stack frame) to this new meaning (where offset is actually the address of the array and index is the value of the control variable), let me point out that I just trying to answer a different question as I understand it :-)

Regards
Sergio Masci

part 2 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2008\07\27@171413 by Joseph Bento

face
flavicon
face
Allow me to bring this topic back to a newbie question...

Though I am a career electronics technician, I am just starting out in  
programming.  I have several books in attempt to learn C, including:  
"The C Programming Language" by Kernighan and Ritchie, "Teach Yourself  
C in 21 Days" by Jones and Aitken, and "Beginner's Guide to Embedded C  
Programming" by Chuck Hellebuyck.  In addition, I have a copy of Bert  
van Dam's excellent book, though it teaches the JAL language. (I must  
say I've already followed several of the projects in this book, and  
have played "what if" and properly altered the programs to output to  
different pins, etc.)

Most of the books seem to assume the reader has no prior programming  
knowledge. (That's me.)  With exception of the Embedded C book, they  
teach the basics of the C language, and the programming examples  
obviously output to the screen to see the results. The Embedded book  
utilizes a PicKit2 and the low pin count board for the projects.

I have purchased an online PIC C course that includes twelve lessons  
in PIC C, utilizing the free version of the MikroC compiler.  This  
lesson plan is by John Main at http://www.best-microcontroller-projects.com
.  Is anyone familiar with this course?

Since I don't have any close friends to help guide me along, I'll ask  
here for opinions at how I should proceed.  My major interest is not  
in developing computer applications, but rather to enhance my  
electronics hobby enjoyment.  In time, I would hope to gain the  
knowledge to develop projects such as a PIC based digital clock -  
either LED or Nixie, an electronic keyer for my ham station, digital  
thermometer, etc.

I think I might answer my own question by saying C and Embedded C are  
inseparable, and understanding C is necessary to properly understand  
Embedded C?

While I understand it requires years of skill and knowledge to become  
proficient, one must start sometime as an absolute beginner.  I  
believe I may have the proper tools to begin, I just need to know how  
to start.


Joe
 

2008\07\27@173931 by peter green

flavicon
face

> Most of the books seem to assume the reader has no prior programming  
> knowledge. (That's me.)  With exception of the Embedded C book, they  
> teach the basics of the C language, and the programming examples  
> obviously output to the screen to see the results. The Embedded book  
> utilizes a PicKit2 and the low pin count board for the projects.
> I think I might answer my own question by saying C and Embedded C are  
> inseparable, and understanding C is necessary to properly understand  
> Embedded C?
>  
Yes and no, some of the hardest parts of C such as working with strings
(since the language has no languace level support for them) and to a
lesser extent pointers in general aren't used that much in small
embedded applications.

I would say as a complete newbie you need to start by learning the basic
language structure, types operators etc. IMO a PC is a much better
environment to be doing that on than some quirky embedded system where
getting your results out is somewhat arkward. Once you grasp the basics
of the language (I would skip the chapters on pointers and strings for
now, you can always come back to them later) then you can move on to
applying it in the embedded environment.


2008\07\28@084607 by Gerhard Fiedler

picon face
sergio masci wrote:

{Quote hidden}

Yes, of course (in a typical stack-based C implementation). But a local arr
ceases to exist after the end of the block, and during its lifetime its
address is constant. The next invocation of the function is a new life, so
to speak. I'm not sure where you want to go with this... arr, as declared
here, is defined as being constant, by the C standard.

If you want its address to be constant across invocations of the function
it is declared in, you just need to declare it static, but I'm sure you
know that. So if this is what you want, this is what you need to do. This
also means that even in a stack-based C implementation arr won't be on the
stack anymore. (Typically... :)


>> Not sure what you mean exactly, but AFAIK, for most purposes C is
>> defined in terms of "observable effects", which in this case means that
>> the whole content of main() could be optimized away -- there's no
>> guarantee that arr[2] ever gets set to anything, because it doesn't
>> create any observable effect. Does a falling tree make a noise if
>> nobody's there to hear it? :)
>
> Come on you can't base a function optimisation argument on what happens
> in "main"

FWIW, my preceding comment is valid for any function like the above
(whether main() or further down in the call tree), with a local variable
that is only set, never read and isn't declared volatile.


> XCSB has been doing this for years :-)

Always happy to provide opportunity for XCSB plugs :)

Gerhard

2008\07\28@095303 by Tamas Rudnai

face picon face
> If you want its address to be constant across invocations of the function
> it is declared in, you just need to declare it static, but I'm sure you
> know that. So if this is what you want, this is what you need to do. This
> also means that even in a stack-based C implementation arr won't be on the
> stack anymore. (Typically... :)

That's true, however, a 'function lifetime' and a 'static' data has other
consumptions, which is the data stored in a 'static' variable should not be
overwritten at any time from outside of the function, therefore there will
be a dedicated RAM allocation to it.

The main problem is that C was never intended to have a non-reentrant
function / subroutine scheme, therefore all locals normally implemented as
stack based to be safe use. As Sergio mentioned many CPU has an indexed
indirect addressing mode so it is no problem in majority of cases, however,
PIC has got nothing like that. That's why all indirect addressing is
painful, whenever it is a stack variable, a pointer or an array in RAM or
ROM. That's why it is important to implement a very good opimalization to
every PIC C compiler that can determine:

1. Whenever a function is reentrant (by either using explicit pragma
declarations or implicit code analysis)
2. Whenever the variable / array can be statically addressed using overlayed
data area
3. Which functions or data can be overlapped - for this the program flow has
to be determined in a statical analysis way
(Note the statical anaysis can be very difficult if function pointers are in
use - aka computed goto)
4. Whenever a function can be expanded to spaghetti code to eliminate the
complication of using indirect addressing - therefore even if finction is
duplicated the overall code size and/or runtime speed can be reduced.

Tamas



On Mon, Jul 28, 2008 at 1:45 PM, Gerhard Fiedler <TakeThisOuTlistsEraseMEspamspam_OUTconnectionbrazil.com
{Quote hidden}

> -

2008\07\28@101157 by sergio masci

flavicon
face


On Mon, 28 Jul 2008, Gerhard Fiedler wrote:

{Quote hidden}

Where do I want to go with this?

What I really want to do is get across to the average C user that although
"arr" may seem to be a constant it is actually (usually) a runtime
variable and has overheads associated with its use.

Comments about how easily access to an indexed array element can be
optimised to a direct access with (implied) no runtime overhead are very
misleading (I'm not pointing at anyone in particular here).

> > Come on you can't base a function optimisation argument on what happens
> > in "main"
>
> FWIW, my preceding comment is valid for any function like the above
> (whether main() or further down in the call tree), with a local variable
> that is only set, never read and isn't declared volatile.

Yes but it is VERY easy to optimise some things in "main" because it is
known to be the first function called at runtime. Trying to do similar
optimisations for other functions requires a lot of work on the part of
the compiler.


Regards
Sergio

2008\07\31@170031 by Kevin

picon face
On Sun, 27 Jul 2008, Joseph Bento wrote:

Joe, I am a hobbyist and started with PICS in Assembler and
moved to CCS C @ ccsinfo.com. Which ever compiler you pick
will start a religious war :)
However, just build something. I have built everything I
wanted to whether I knew how to or not. Check the internet
ask questions and just experiment. The basics of C are easy
enough to get started and produce something that works.
Experimenting is half the fun. Just go for it and enjoy.

Regards,
Kevin

{Quote hidden}


'[PIC] Starting with C'
2008\08\18@171541 by Dario Greggio
face picon face
sergio masci wrote:

> Yep, you're right it works. Even the example I gave above works :-(
> I'm shocked that the compiler didn't give an error.

I was *very* surprised too when I tried it... no longer than 2 years ago!


--
Ciao, Dario

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