In article <zi$2UOEQgk9GFA$e@phaedsys.demon.co.uk>, Chris Hills says...
> In message <MPG.215e07c1bc89aeb09897c2@free.teranews.com>, Robert Adsett 
> <sub2@aeolusdevelopment.com> writes
> >In article <tiZx0HKMcn8GFAFU@phaedsys.demon.co.uk>, Chris Hills says...
> >> In message <m3lkb1y0t2.fsf@shadow.org.uk>, Rich Walker
> >> <rw@shadowrobot.com> writes
> >> >Chris Hills <chris@phaedsys.org> writes:
> >> >
> >> >>
> >> >> You will not get a fully  ISO C compliant compiler for the PIC. It's
> >> >>architecture will not permit
> >> >> it.  You need to write C for the PIC not portable C is you want to
> >> >>get any sort of efficiency out of
> >> >> it.
> >> >
> >> >Just out of interest, which bits of ISO C can't the PIC do?
> >>
> >> Which ISO C?
> >>
> >> This is not a trick question.
> >
> >OK Chris, now you have me curious.  Your question implies that the
> >standards differ in their requirements of the processor and that the PIC
> >can meet at least some in one version but not another. Otherwise the
> >question would be moot.
> 
> This is true. You will have to compare the PIC compiler specs, along 
> with C99 and C90 to be specific.
> 
> C90 requires
> 15 levels of nesting ,
> 31  arguments in functions calls,
>   32K bytes in an object  (I assume all PICS have more than 32K of code 
> memory? )
> 
> 127  members in a single union or structure.
> 
> etc etc
> 
> C99 different minimum constraints  all or which are equal or greater 
> than C90 mot larger

But none of those would appear to me to allow the the creation of a 
compiler for the PIC that would meet the constraint if using one version 
of the ISO standard but dissallow it for a different version.  ISTM that 
all of these constraints fail regardless of version.
 
> >
> >So what are the differences that would place different requirements on
> >the underlying processor that change whether or not the PIC can meet
> >them?
> 
> The standards have changed over the years.  The PIC compilers tend to 
> adhere to C90  some to C95  not AFAIK to C99
> 
> There are many things due to the small physical constraints to the 
> device you cant fit into a PIC
> 
> As has been mentioned re-entrancy is one, teh C99  long long is probably 
> another, a lot of the maths would, I think be impossible to do.

Well long long is a new addition but I don't see why it would be 
impossible to implement on a PIC.  It might even be useful for some 
people.  

Re-entrancy doesn't introduce different requirements from version to 
version does it though?  I don't see that it qualifies as an answer.


> Also I thin the PIC has extensions that are not part of the C standard.

True, but that's the case for extensions for all other processors as 
well.  Nothing to do with what differences there are in the various 
versions of the standard that would enable a PIC to meet a constraint in 
one version but not another though and that is the question I asked.

Robert

-- 
Posted via a free Usenet account from http://www.teranews.com

Walter Banks wrote:
> 
... snip ...
> 
> The last point to comment on is PIC12 (or PIC10 series) that
> have both limited stack and no interrupt support. (There are
> other processors with a similar characteristics like the RS08).
> We started adding execution threads, execution that is triggered
> by some logical sequence. This approach flattens the structure
> of an application and statistically reduces subroutine return
> stack and off page references.

What I have done in the past is to run most of the time with
interrups disabled.  There is a master routine, which enables
interrupts, then disables, allowing any interrupts to occur in that
hole (which may be repeated).  This means that the main code knows
no interrupts will disturb it, and the full stack depth can be
used.  It also means that interrupt routines have to be short and
leave flags for other routines to process.  Proper execution also
requires that the execution time of the main loop be well known,
and limited.

A useful characteristic to annotate the source with is the maximum
running time for a routine.

-- 
 Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>



-- 
Posted via a free Usenet account from http://www.teranews.com

Walter Banks wrote:
> 
> David Brown wrote:
> 
>> I've programmed PIC14 and PIC16 (and even a PIC12 once) in assembly -
>> never in C.  I guess it's a matter of personal taste, but I found PIC
>> assembly particularly unpleasant compared to the dozen or so other
>> assemblies I have used regularly.  With a great deal of macros handling
>> bank switching (amongst other things), along with aliases for things
>> like the "btfsc" instruction (which roll off the tongue *so* easily), it
>> was usable.
> 
> David,
> 
>   My bias is well known in this area. One of the real advantages of
> a C compiler especially with PIC's is the compiler only has to get it
> right once :)
> 
> To follow up on a couple of your points. Memory management
> support can be a real pain both for compilers and asm programs.
> The compiler can track the current state of the RAM and ROM
> memory management and that helps. Some very interesting things
> start to happen when an application gets to almost filling the
> available ROM. As the ROM fills up the probability of an off
> page jump or call becomes higher and the application subsequently
> slows down.
> 
> The RAM memory management on a PIC is actually better than
> most. Some RAM has multiple forms of  alaising that can be used
> by the compiler to reduce the amount required generated code
> to support it. The ROM memory management on the other hand
> requires preloading the memory management in eager anticipation
> that a conditional branch will branch and is followed by more
> code that is needed to restore ROM memory management in the
> case the condition fails. Some of these sequences have significant
> overhead.
> 

I found bank switching (for RAM and ROM) to be a pain - the PIC made 
most sense for really small programs which did not need any bank 
switching.  But with some clever macros, I managed to get automatic 
setting of the bank select bits fairly optimal (erring on the side of 
caution).  I still had to manually choose which function and which data 
goes in which bank, however - it's that kind of thing that your C 
compiler can do better than an assembly programmer in most cases 
(assuming the assembly program is going to be maintainable over time!).

> The last point to comment on is PIC12 (or PIC10 series) that
> have both limited stack and no interrupt support. (There are other
> processors with a similar characteristics like the RS08). We
> started adding execution threads, execution that is triggered by
> some logical sequence. This approach flattens the structure of
> an application and statistically reduces subroutine return stack
> and off page references.
> 

I used to have macros for easy use of goto's instead of call/return 
pairs, as a way of saving stack space (and time and code space) for 
functions that were only ever called from one place (if the function is 
called from two places, I got a linker error).  Again, a good compiler 
will go one step further and inline such functions, but it was possible 
to get by with macros and assembly.


I also once wrote a small program for an AVR Tiny which has a 3 level 
hardware stack and no RAM - the 32 8-bit registers was all the memory it 
had (along with some eeprom).  I used avr-gcc - with a little care, such 
as specifying registers for global variables and avoiding any library 
code, it all worked out fine (including interrupt functions).

mvh.,

David


> Regards
> 
> 
> Walter Banks
> Byte Craft Limited
> Tel. (519) 888-6911
> Fax (519) 746 6751
> http://www.bytecraft.com
> walter@bytecraft.com
> 

David Brown wrote:

> I've programmed PIC14 and PIC16 (and even a PIC12 once) in assembly -
> never in C.  I guess it's a matter of personal taste, but I found PIC
> assembly particularly unpleasant compared to the dozen or so other
> assemblies I have used regularly.  With a great deal of macros handling
> bank switching (amongst other things), along with aliases for things
> like the "btfsc" instruction (which roll off the tongue *so* easily), it
> was usable.

David,

  My bias is well known in this area. One of the real advantages of
a C compiler especially with PIC's is the compiler only has to get it
right once :)

To follow up on a couple of your points. Memory management
support can be a real pain both for compilers and asm programs.
The compiler can track the current state of the RAM and ROM
memory management and that helps. Some very interesting things
start to happen when an application gets to almost filling the
available ROM. As the ROM fills up the probability of an off
page jump or call becomes higher and the application subsequently
slows down.

The RAM memory management on a PIC is actually better than
most. Some RAM has multiple forms of  alaising that can be used
by the compiler to reduce the amount required generated code
to support it. The ROM memory management on the other hand
requires preloading the memory management in eager anticipation
that a conditional branch will branch and is followed by more
code that is needed to restore ROM memory management in the
case the condition fails. Some of these sequences have significant
overhead.

The last point to comment on is PIC12 (or PIC10 series) that
have both limited stack and no interrupt support. (There are other
processors with a similar characteristics like the RS08). We
started adding execution threads, execution that is triggered by
some logical sequence. This approach flattens the structure of
an application and statistically reduces subroutine return stack
and off page references.

Regards


Walter Banks
Byte Craft Limited
Tel. (519) 888-6911
Fax (519) 746 6751
http://www.bytecraft.com
walter@bytecraft.com

FreeRTOS.org wrote:
>>> It looses out on 16 bit systems
>> The 16-bit market is very small - there is the msp430 (for which the gcc 
>> port is perfectly good, but based on a rather old version of gcc and 
>> therefore missing many recent improvements), some Freescale devices (I 
>> don't know if there is a gcc port there), and various devices from the far 
>> east (again, I don't know about gcc there).
> 
> I'm repeating myself here just for the record - but the PIC24 and dsPIC 
> (16bit devices) have a good GCC port.
> 

Sorry, I didn't think about these (I always think of "PIC" as PIC12, 
PIC14 and PIC16 - possibly PIC18.  I never had occasion to look at the 
newer, bigger PIC's more closely).

> 
>> No - some commercial compilers have some techniques that gcc does not use, 
>> and some of these techniques may have been in use for years.  There is a 
>> big difference here - there is no doubt that for example Byte Craft use 
>> optimisation and compilation techniques that are well beyond what gcc can 
>> do at the moment.  But that does not imply that gcc is equivalent to a 5 
>> or 10 year old embedded compiler!
> 
> <snip>
> 
> This has been discussed add infinitum.
> 
> 
>>> Also GCC has it's own standard, not ISO C.
> 
> 
> What makes a standard?  What a committee publishes but nobody uses, or what 
> a large user base use, comply with, and expect to see?
> 
> It is always amusing watching language 'gurus' cut their teeth in the 
> embedded word, fall flat on their faces, then blame the compiler for not 
> implementing the 'standard'.  They know which page of which standard a 
> particular construct is described, but have no idea how to create an 
> embedded system.  Which is the most useful skill?
> 
> [expecting to be flamed]
> 

That's an important point.  The C standards are a helpful reference, but 
since almost *no* compiler seems to implement all of any given standard, 
and none of the standards are sufficient for embedded programming, they 
are only an indication of language support.  For example, if the 
compiler is approximately C99 compliant, you know you can mix 
declarations and statements in a function (if you thought that was a 
good idea...).  And if you know you are sticking to gcc, it is safe to 
use gcc extensions (some of which can be very useful).  The standards 
make life easier, but by no means easy, for writing cross-target code.

CBFalconer wrote:
> David Brown wrote:
> ... snip ...
>> I was quoting the OP, not stating my own opinion.  I am well aware
>> that the PIC is a "real" processor.  It is a horrible cpu
>> architecture to work with (at least on the PIC16 and PIC14 which I
>> have used), is severely limited, C-unfriendly, and has some of the
>> least intuitive and most unpronounceable assembly opcodes I've
>> come across, and I certainly don't like the cpu - but it's still a
>> "real" processor, and is still useful for real work.
> 
> While it may be horrible for C, it is quite natural and useful for
> assembly language.  Which, considering the size of applications
> that can be handled, is the appropriate language for these chips. 
> But don't expect to use a clone of other popular chips assembly
> language.  This is about PIC14 and PIC16.
> 

I've programmed PIC14 and PIC16 (and even a PIC12 once) in assembly - 
never in C.  I guess it's a matter of personal taste, but I found PIC 
assembly particularly unpleasant compared to the dozen or so other 
assemblies I have used regularly.  With a great deal of macros handling 
bank switching (amongst other things), along with aliases for things 
like the "btfsc" instruction (which roll off the tongue *so* easily), it 
was usable.

The PICs have plenty of nice features - their cpu is not one of them.

mvh.,

David

Chris Hills wrote:
> In message <46f383bf$0$27835$8404b019@news.wineasy.se>, David Brown 
> <david@westcontrol.removethisbit.com> writes
>> Chris Hills wrote:
>>> In message <46f36a48$0$27840$8404b019@news.wineasy.se>, David Brown 
>>> <david@westcontrol.removethisbit.com> writes
>>>> The original suggestion was to "use GCC with a real processor like 
>>>> and  (sic) AVR, MSP, or ARM7".
>>>  These MCU are no more or less real than PIC.
>>>
>>
>> I was quoting the OP, not stating my own opinion.  I am well aware 
>> that the PIC is a "real" processor.  It is a horrible cpu architecture 
>> to work with (at least on the PIC16 and PIC14 which I have used), is 
>> severely limited, C-unfriendly, and has some of the least intuitive 
>> and most unpronounceable assembly opcodes I've come across, and I 
>> certainly don't like the cpu - but it's still a "real" processor, and 
>> is still useful for real work.
> 
> Can't disagree there.  However the problems with the architecture mean 
> you really have to look at the compiler manual not K&R to program it 
> efficiently.
> 
> Personally I still love the 68K
> 

The 68k has always been my favourite too (as ColdFire these days).

Chris Hills wrote:
> In message <MPG.215e07c1bc89aeb09897c2@free.teranews.com>, Robert Adsett 
> <sub2@aeolusdevelopment.com> writes
>> In article <tiZx0HKMcn8GFAFU@phaedsys.demon.co.uk>, Chris Hills says...
>>> In message <m3lkb1y0t2.fsf@shadow.org.uk>, Rich Walker
>>> <rw@shadowrobot.com> writes
>>> >Chris Hills <chris@phaedsys.org> writes:
>>> >
>>> >>
>>> >> You will not get a fully  ISO C compliant compiler for the PIC. It's
>>> >>architecture will not permit
>>> >> it.  You need to write C for the PIC not portable C is you want to
>>> >>get any sort of efficiency out of
>>> >> it.
>>> >
>>> >Just out of interest, which bits of ISO C can't the PIC do?
>>>
>>> Which ISO C?
>>>
>>> This is not a trick question.
>>
>> OK Chris, now you have me curious.  Your question implies that the
>> standards differ in their requirements of the processor and that the PIC
>> can meet at least some in one version but not another. Otherwise the
>> question would be moot.
> 
> This is true. You will have to compare the PIC compiler specs, along 
> with C99 and C90 to be specific.
> 
> C90 requires
> 15 levels of nesting ,
> 31  arguments in functions calls,
>  32K bytes in an object  (I assume all PICS have more than 32K of code 
> memory? )
> 
> 127  members in a single union or structure.
> 
> etc etc
> 
> C99 different minimum constraints  all or which are equal or greater 
> than C90 mot larger
> 
> 
>>
>> So what are the differences that would place different requirements on
>> the underlying processor that change whether or not the PIC can meet
>> them?
> 
> The standards have changed over the years.  The PIC compilers tend to 
> adhere to C90  some to C95  not AFAIK to C99
> 
> There are many things due to the small physical constraints to the 
> device you cant fit into a PIC
> 
> As has been mentioned re-entrancy is one, teh C99  long long is probably 
> another, a lot of the maths would, I think be impossible to do.
> 

As has been mentioned by Walter Banks, it is perfectly possible to write 
re-entrant functions on the PIC (and other such limited micros).  It is 
not possible, in general, to write small and fast re-entrant functions - 
but small and fast code is not a requirement of the standards.  Thus a 
good compiler for such micros can cope with re-entrant code when it has 
to, but will generate non-reentrant code when possible.

Similarly, there is no good reason why long longs should not be 
supported on the PIC.  They are obviously inefficient to implement, but 
so what?  You write your compiler to be as efficient as possible on the 
architecture in question, for code constructs that match the target.  If 
someone really wants 64-bit integers on the PIC, then they probably have 
good reasons, and probably understand the cost - so you give them 
working code.  About the only place I (were I a compiler writer) would 
break with the standards is for floating point - the standards require 
floating point calculations to be promoted to 64-bit doubles, which is 
not a good idea on a small micro.  I'd be inclined, therefore, to either 
make doubles 32-bit normally (with a flag for 64-bit support), or to 
cheat and avoid promoting floats unless necessary (again, controlled by 
flags).

Of course, there is nothing that the compiler can do to implement the C 
standards' requirements regarding minimum sizes if the microcontroller's 
memory is too small.

> Also I thin the PIC has extensions that are not part of the C standard.
> 
> 
> 

On 2007-09-23, Chris Hills <chris@phaedsys.org> wrote:
> C90 requires
>   32K bytes in an object 

Not unless you consider the PIC to be a hosted environment.

> (I assume all PICS have more than 32K of code memory? )

No, some have 256 words.  The term "PIC" isn't really meaningful given
the broad range of PIC cores, including 16-bit parts with lots of RAM
and code space and a real stack.  But when people say "PIC" they are
usually referring to the 14-bit cores, which have a maximum of 8K
words of code space and 512 bytes of data memory.

-- 
John W. Temples, III

In message <MPG.215e07c1bc89aeb09897c2@free.teranews.com>, Robert Adsett 
<sub2@aeolusdevelopment.com> writes
>In article <tiZx0HKMcn8GFAFU@phaedsys.demon.co.uk>, Chris Hills says...
>> In message <m3lkb1y0t2.fsf@shadow.org.uk>, Rich Walker
>> <rw@shadowrobot.com> writes
>> >Chris Hills <chris@phaedsys.org> writes:
>> >
>> >>
>> >> You will not get a fully  ISO C compliant compiler for the PIC. It's
>> >>architecture will not permit
>> >> it.  You need to write C for the PIC not portable C is you want to
>> >>get any sort of efficiency out of
>> >> it.
>> >
>> >Just out of interest, which bits of ISO C can't the PIC do?
>>
>> Which ISO C?
>>
>> This is not a trick question.
>
>OK Chris, now you have me curious.  Your question implies that the
>standards differ in their requirements of the processor and that the PIC
>can meet at least some in one version but not another. Otherwise the
>question would be moot.

This is true. You will have to compare the PIC compiler specs, along 
with C99 and C90 to be specific.

C90 requires
15 levels of nesting ,
31  arguments in functions calls,
  32K bytes in an object  (I assume all PICS have more than 32K of code 
memory? )

127  members in a single union or structure.

etc etc

C99 different minimum constraints  all or which are equal or greater 
than C90 mot larger


>
>So what are the differences that would place different requirements on
>the underlying processor that change whether or not the PIC can meet
>them?

The standards have changed over the years.  The PIC compilers tend to 
adhere to C90  some to C95  not AFAIK to C99

There are many things due to the small physical constraints to the 
device you cant fit into a PIC

As has been mentioned re-entrancy is one, teh C99  long long is probably 
another, a lot of the maths would, I think be impossible to do.

Also I thin the PIC has extensions that are not part of the C standard.



-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/