Paul Burke <paul@scazon.com> wrote:
> Mark L Pappin wrote:

> >   unsigned char lives_in_RAM = 'a';
> >   const unsigned char lives_in_ROM = 'b';

> This really is one of the major problems of C. 

No.  If it's a problem, then it's one of the C compiler in question.
If you declare an object 'const', in C, a compiler for a target system
that has ROM space available has all the liberty needed to put it in
ROM.  If the tools don't do so, that's not the fault of the language,
but a quality issue with the tools, or possibly a usage error (not
turning on the relevant compiler/linker option).

C doesn't provide a mechanism for portable programs to force the
translator to put objects to be in non-writable storage.  But that's
not a problem, that's a designed-in feature of the language.  Such
programs would be gratuitously unportable.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Mark L Pappin wrote:
> "Michael N. Moran" <mike@mnmoran.org> writes:
>>>OK. Please explain to me how one *without going outside of
>>the C/C++ language standard* declare an "unsigned char" for
>>the AVR that lives in the AVR ROM space and another that
>>lives in the AVR RAM space?
> 
> 
>   unsigned char lives_in_RAM = 'a';
>   const unsigned char lives_in_ROM = 'b';
> 

This really is one of the major problems of C. The construct above 
doesn't work with, for example, the Raisonance 8051 compiler, where even 
if you declare a const, it still assumes it's in the internal RAM unless 
you precede it with "code".

This kind of thing makes porting code a bugger, even a debugger, and 
it's time the industry got together to work out a standard. While you're 
at it, define a portable way of allocating objects to specified locations.

Paul Burke

"Michael N. Moran" <mike@mnmoran.org> writes:

> Chris Hills wrote:
>> Michael N. Moran
>>> E.g. oth language standards assume a single address space.
>> really?
> 
> OK. Please explain to me how one *without going outside of
> the C/C++ language standard* declare an "unsigned char" for
> the AVR that lives in the AVR ROM space and another that
> lives in the AVR RAM space?

  unsigned char lives_in_RAM = 'a';
  const unsigned char lives_in_ROM = 'b';

works for all the HI-TECH C compilers I have installed at work, for
Harvard or von Neumann architectures.  As several people have
mentioned (but not in detail), they allocate constant objects to
addresses in ROM that are outside the range of valid addresses in RAM,
so can be distinguished at runtime.

mlp
(Disclosure of Interest: employed by, but not speaking for, HI-TECH;
just pointing out a mechanism that can be and is used.)

Sergio Masci wrote:

<snip>

> 
> Hi David,
> 
> This thread started out talking about how crap the PIC architecture is and 
> I have been trying to point out that it is not as crap as many people 
> would have "you" belive. Along the way the thread strayed into HLL (and 
> 'C') space and now we seem to be fully entrenched in what is valid 
> standards complient 'C'.
> 

The PIC (the old PIC16 at least - I don't know newer ones) architecture 
*is* crap.  What you have managed to do (and I highly commend for it) is 
write a compiler that makes this crap run well.  If you wrote a similar 
compiler for a half-decent architecture like the avr, or a decent one 
like the msp430, you'd get even better results.

> Regardless of whether or not it is possible to trace the use of a RAM and 
> CODE space pointer in a standards complient 'C', the fact still remains 
> that with minor extensions IT IS POSSIBLE to do so.
> 

I think we agree that extensions or changes to C for use in embedded 
systems are a necessary thing, and can often be a good thing even when 
strictly-speaking unnecessary.  But if you have made extensions (like 
adding "flash" or "near" keywords) or semantic changes (like changing 
the meaning of "const"), it is no longer standard C.  I stress that I 
don't see that as a bad thing (within reason).

> I am really concerned that people with a limitted understanding of what it 
> is possible to do with a HLL base their critisisms of the PIC on what is 
> effectively a very old language developed for a mini computer with less 
> processing power than a modern PDA.
> 
> It is possible and practical for a modern HLL to do things that 'C' 
> cannot. We should be looking forward to what we can do with software not 
> holding ourselves back because the current software is limitted.
> 

I fully agree here - C is a terrible language for small embedded systems 
(or big embedded systems, or non-embedded systems for that matter).  It 
should be possible to design an HLL that works far better in every way, 
be it for a PIC or any other micro.  However, pretty much any reasonable 
HLL will work better on better architectures - the PIC will still be 
poor in comparison to others.

> One of the reasons I chose to write a compiler other than a 'C' compiler 
> was to be able to freely take advantage of what can be done instead of 
> being tied to what others have been lead to expect.
> 

I'm slightly confused here - your compiler is *not* a C compiler?  I 
thought what you had written was a very smart C compiler.  If what you 
have is not a "C compiler" as such, but a "modified C" or a "C with some 
bits of C++" compiler (guessing from your overloaded function), then 
that's fair enough.  It's likely to be a good solution - just as long as 
you don't call it standard C.

mvh.,

David

>
> I agree as well, the PIC is quote good when taking into account that
> it is a mid 70's design, but the AVR is a 90's design, and when
> working with it, it soon is obvious that in terms of developer
> friendlyness it wins hands down.
> The only thing that makes the PIC halfway usable are the vast number
> of app notes and other support documents microchip provides.
> The harvard architecture is actually not such a problem when using the
> imagcraft C compiler. When declaring global variables "const", they
> are put in flash and the LPM instruction are automatically used to
> access these variables. I am not aware of an AVR compiler that
> supports "generic" pointers, hence when using pointers the programmer
> still needs to keep track of whether the data is in code or data
> space.
>

IAR Embedded workbench can support generic pointers.
-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may bot be shared by my employer Atmel Nordic AB

"Andreas Schwarz" <usenet@andreas-s.net> skrev i meddelandet
news:43515ad8$0$6777$9b4e6d93@newsread4.arcor-online.net...
> Ian Bell schrieb:
>> Andreas Schwarz wrote:
>>
>> LOL, that 2-3K makes a huge difference in products with 16K ROM or less
>> and
>> there are very many of those.
>
> Optimization (writing a specialized function instead of using one from the
> library is nothing but optimization) is done when necessary, and no
> sooner. If your program with printf & Co. is 14k large and you target a
> 16k microcontroller, replacing standard functions with specialized code
> will gain you absolutely nothing, but takes time, is error-prone, makes
> your code larger and hurts maintainability.


Currently implementing "optimized" printf for a 4kB ATmega48 controller.
Sure make a difference in price compared to the 8kB ATmega88...

-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may bot be shared by my employer Atmel Nordic AB

On 2005-10-20, Sergio Masci <sergio@NOSPAM.xcprod.com> wrote:
>
> On Thu, 20 Oct 2005, Ian Bell wrote:
>
><snip>
>
>> 
>> Ian
>> 
>
> I do not post just for your benefit. 

Most of us agree with Ian.  Trim posts is good.

> Many people actually prefer to be able read through a single
> post without having to jump around between posts to understand
> what is being refered to.

I'm sure sufficient context can be maintined without quoting
the entire thread.

> When I do post something just for you I shall be sure to
> remove as much useless clutter from it as possible.

Please do the same for me. :)

-- 
Grant Edwards                   grante             Yow!  This is PLEASANT!
                                  at               
                               visi.com

Sergio Masci wrote:
> I do not post just for your benefit.
> 

Well, I certainly don't feel like I gain any benefit from your posts, but
that is no excuse for bad manners.

Ian

On Thu, 20 Oct 2005 13:13:22 +0100, Sergio Masci
<sergio@NOSPAM.xcprod.com> wrote:

>
>On Thu, 20 Oct 2005, Ian Bell wrote:
>
><snip>
>
>> 
>> Ian
>> 
>
>I do not post just for your benefit. 
>
>Many people actually prefer to be able read through a single post without 
>having to jump around between posts to understand what is being refered 
>to.
>
>When I do post something just for you I shall be sure to remove as much 
>useless clutter from it as possible.

Sergio

Why don't you put all previous posts on your web site, so that the
0.1% of people unable to follow a normal usenet thread can access them
there? Or they can use some search tools.

One doesn't have to delete a post after reading it.

The rest of us prefer to have all unnecessary stuff removed from a
followup.

Tom