On Mon, 30 Oct 2006 08:30:22 +0000, Chris Hills wrote:

>>
>>With the trend of semiconductor manufacturers releasing cheap 32-bit arm
>>microcontrollers with increasing sizes of flash and SRAM, efficiency in
>>the compiler is becoming less and less of an issue.
> 
> This is not correct.
> 

Maybe not for the type of work you get involved with, but it is for me. I
can get a Atmel arm, 64K flash and 16K sram, from farnell in 100 off for
�3.25. The price point and amounts of Flash/SRAM mean I don't care how
efficient the compiler is. OK - an efficient compiler means I can download
the compiled software quicker.

>>Again, with 32-bit processors at traditional 8-bit prices, compiling and
>>testing on a PC, rather than a simulator, becomes possible. Then you get
>>the advantages of using a PC.
> 
> What advantages?

Well, a PC has lots of disk space for storing test data. Also tests run
quicker. It's also easier change the tests you are performing - no need
to download a newly compiled test or set of tests to a target. And you
don't need to use a terminal + send data over serial links to look at your
results. Just compiling code, running it, and instantaneously getting the
results is kind of good.

Regards,

Paul.

Robert Adsett wrote:
> Stefan Reuther wrote:
> > That would have been a little harder if they'd used other platform
> > specifics such as *(char far*)0x00400017, asm { ... }, <dos.h> etc.,
> > even if that'd have saved a cycle here and there.
>
> Well,  once you include any I/O other than stdio you are definitely in
> for a porting job.  Even that wasn't portable across DOS compilers.  Of
> course stdio isn't going to be a lot of good on a lot of embedded

Well that was bad phrasing.  I meant I/O wasn't portable across DOS
compilers.  I've run into three similar schemes and seen reference to a
fourth.  AFAIK, stdio was portable.

Robert

Stefan Reuther wrote:
> Agreed. I didn't have the pleasure(?) to code for a 8051 yet, but as
> long as it's just the memory allocation directives, you can probably
> easily #define them away if needed. I just pumped a 15 year old DOS C
> source through a C++ compiler, the only thing I had to change was to add
> a '#define far' (their excuse for not having to use Huge memory model
> which generates less efficient code), and convert the K&R function
> headings to prototypes.

Well huge model does generate less efficient code but as I remember the
only advantage it offered over large was that it could address across a
64K boundary in a single unit.  If you had no single allocation larger
than 64K there was no reason to use huge.  Most of the pointer
modifiers I ever saw on x86 code were mis-guided optimizations.  The
code would have been clearer and just as fast and small if the authours
had just picked the right model to begin with and left off the
modifiers.

Of course this wasn't helped by the fact that there was no agreed
definition for all the various memory models.  Microsoft, Borland and
Watcom all had different definitions.

> That would have been a little harder if they'd used other platform
> specifics such as *(char far*)0x00400017, asm { ... }, <dos.h> etc.,
> even if that'd have saved a cycle here and there.

Well,  once you include any I/O other than stdio you are definitely in
for a porting job.  Even that wasn't portable across DOS compilers.  Of
course stdio isn't going to be a lot of good on a lot of embedded
targets.

Robert

Chris Hills wrote:
> In article <ei26ue.1g4.1@stefan.msgid.phost.de>, Stefan Reuther
>> Chris Hills wrote:
>>> For example on 8051 most (80%) of the code adheres to the Keil C51 (and
>>> there are far more 51's out there than anything else)
>>
>> But probably it is much easier to find a compiler for a non-8051 CPU
>> that adheres to ISO C90 than to find one that adheres to Keil C51's
>> language.
> 
> Yes but  writing in pure C90 etc is not going to be a very efficient
> 8051 program by a long way.

Agreed. I didn't have the pleasure(?) to code for a 8051 yet, but as
long as it's just the memory allocation directives, you can probably
easily #define them away if needed. I just pumped a 15 year old DOS C
source through a C++ compiler, the only thing I had to change was to add
a '#define far' (their excuse for not having to use Huge memory model
which generates less efficient code), and convert the K&R function
headings to prototypes.

That would have been a little harder if they'd used other platform
specifics such as *(char far*)0x00400017, asm { ... }, <dos.h> etc.,
even if that'd have saved a cycle here and there.

>> I routinely compile parts of my embedded code for Win32 - to have
>> automated test suites, for example. Whereas my embedded device is
>> allowed to require half an hour to decode a 100 MB MP3 file, having my
>> PC run the same decoder in a couple of seconds surely helps to validate
>> it. Hence, I try to make most parts of my code understandable to PC
>> compilers, and ISO C90 (and C++98, in my case) is some sort of a least
>> common denominator.
> 
> This is OK if the target has the same size ie 8/16/32 bit as the PC. If
> not it is a bit pointless.

8-bit bytes are nice, but 16/32/64 bit word size shouldn't matter thanks
<stdint.h>.

> You should write the code for the target and
> test in the simulator for the target.

My simulator does a mere 10000 cycles/second, and doesn't simulate the
interesting peripherals, so I've decided to ignore it.

One of my modules is a CD file system implementation. Testing that on
the target means burning 150 CDs with different file systems, ISO 9660
violations, etc on them, and spending half a day juggling discs in and
out. Testing that on the PC means swapping a simple fopen/fread/fclose
in place of the ReadBlock routine, and have an automated test driver run
all these tests in a matter of seconds from a directory with .isos in
them. The only real drawback I had to make to make this possible is to
avoid '#pragma pack' and friends, and manually assemble the multi-byte
values.

Of course one must make sure that the test has some resemblance to what
actually happens on the target. For that, I trust my debugging skills :)


  Stefan

In article <pan.2006.10.29.16.42.26.853168@tiscali.co.uk>, Paul Taylor 
<paul_ng_pls_rem@tiscali.co.uk> writes
>On Sun, 29 Oct 2006 12:32:21 +0000, Chris Hills wrote:
>
>>
>> Yes but  writing in pure C90 etc is not going to be a very efficient
>> 8051 program by a long way.
>>
>
>With the trend of semiconductor manufacturers releasing cheap 32-bit arm
>microcontrollers with increasing sizes of flash and SRAM, efficiency in
>the compiler is becoming less and less of an issue.

This is not correct.

>I wonder how long it will be before compiler efficiency is a moot point
>for a vast percentage of embedded applications?

It is actually becoming more important.

>> This is OK if the target has the same size ie 8/16/32 bit as the PC. If
>> not it is a bit pointless. You should write the code for the target and
>> test in the simulator for the target.
>
>Again, with 32-bit processors at traditional 8-bit prices, compiling and
>testing on a PC, rather than a simulator, becomes possible. Then you get
>the advantages of using a PC.

What advantages?

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

On Sun, 29 Oct 2006 12:32:21 +0000, Chris Hills wrote:

> 
> Yes but  writing in pure C90 etc is not going to be a very efficient 
> 8051 program by a long way.
> 

With the trend of semiconductor manufacturers releasing cheap 32-bit arm
microcontrollers with increasing sizes of flash and SRAM, efficiency in
the compiler is becoming less and less of an issue.

I wonder how long it will be before compiler efficiency is a moot point
for a vast percentage of embedded applications?

> This is OK if the target has the same size ie 8/16/32 bit as the PC. If
> not it is a bit pointless. You should write the code for the target and
> test in the simulator for the target.

Again, with 32-bit processors at traditional 8-bit prices, compiling and
testing on a PC, rather than a simulator, becomes possible. Then you get
the advantages of using a PC.

Chris Hills <chris@phaedsys.org> writes:
> CBFalconer <cbfalconer@yahoo.com> writes
[snip]
> >or earlier C standards generally known
> >as C89, C90, C95.
> 
> SO your definition is "any of the documents that are or were ISO or US C 
> standards going back over the last 25 years and/or any of the CD's TC's 
> etc etc that are also produced by WG14  even if they are mutually 
> exclusive.
> 
> That is one hell of a mess..... You are FAR better to adhere to what the 
> compiler does. Yes you should try and group the extensions separately 
> but in embedded
> 
> >Surely you were aware of this.
> 
> As a longstanding member of the ISO C panel I know what the C standard 
> is and just as importantly what it is not.
> 
> "Close enough" is OK for horse shoes and hand grenades NOT for 
> programming. Things change in C from year to year.

Something's wrong with the standardization process if
things are changing "year to year".  The whole idea of
standardization is to provide a stable and well-defined
basis for production of standard-conforming products,
preferably over an extended period of time.

> Chris Hills wrote:
> > Stefan Reuther <stefan.news@arcor.de> writes
> 
> >I routinely compile parts of my embedded code for Win32 - to have
> >automated test suites, for example. Whereas my embedded device is
> >allowed to require half an hour to decode a 100 MB MP3 file, having my
> >PC run the same decoder in a couple of seconds surely helps to validate
> >it. Hence, I try to make most parts of my code understandable to PC
> >compilers, and ISO C90 (and C++98, in my case) is some sort of a least
> >common denominator.
> 
> This is OK if the target has the same size ie 8/16/32 bit as the PC.

Are you referring to the hardware size(s) or the implicit
sizes of int, char, et al?

> If not it is a bit pointless. You should write the code for the
> target and test in the simulator for the target.

It certainly is not pointless to test programming with a
host having a different word size than the target.  If
the C compilers produce the same functionality for both
the host and the target, it makes no difference where
the testing is done (other than speed of execution).
Using a simulator to perform testing is almost a last
resort unless one wants to proceed at glacial speeds or
has something that can't be tested any other way.

Chris Hills wrote:
> In article <1162076665.038472.168090@e64g2000cwd.googlegroups.com>,
> Robert Adsett <sub2@aeolusdevelopment.com> writes
> >
> >Chris Hills wrote:
> >> In article <1161784387.593457.189290@h48g2000cwc.googlegroups.com>,
> >> Robert Adsett <sub2@aeolusdevelopment.com> writes
> >> >
> >> >techie.embedded@gmail.com wrote:
> >> >> hello members.
> >> >>
> >> >> thanks for the last... The ARM Application Notes, i guess should serve
> >> >> my purpose.
> >> >>
> >> >> Just another question. Does the syntax of code change when programming
> >> >> in a IAR enviorment to a Keil Environment????
> >> >
> >> >If you are foolhardy enough to use compiler extensions, yes.
> >> >
> >> >If you are disciplined enough to stick to standard C, no.
> >>
> >>
> >> Please explain what you mean by standard C
> >
> >ANSI/ISO.
>
> Any of the version since 1989? The last poster included "all versions"
> and the committee drafts etc...  Even where they are mutually exclusive.

I did restrict myself a bit later :)

> >It probably makes sense to stick to C89 for true portability
> >between compilers at the moment.
>
> You probably mean ISO C90,  C89 is a local US standard.
>
> In any event most are at C95/6  + "some bits" of C99
>
> >Consider it shorthand for avoiding compiler specific extension,
> >pragmas, inline assembler, interrupt keywords etc..., etc...
>
> However......  Depending on what you are programming and what if any
> portability is required often you are better sticking with a compiler
> implementation than the C standard.

Remember the original question was (paraphrased) "Will the syntax from
one compiler for ARM compiler on another compiler for ARM?"

However, even disregarding that context, and dealing with the
circumstance where you are dealing with a product where you never
expect to change processors or compilers you are best served by
sticking mainly with the standard C subset.  Not only does that improve
the code portability, more importantly it improves the programmers and
associated tools portability.

I've not yet seen a case where I'd consider inline assembler, interrupt
keywords and pragmas 'better' that using assembler or rethinking the
problem.  I have run into compilers that give you no choice in the
matter, since they offer no assembler (and sometimes no linker).
Especially in the latter case though they had a legion of other
problems as well.  I've not had to use an 8051 derivative yet so I'll
leave open the possibility that there are architectural features that
forbid the use of a standard C compiler on it.  OTOH with the current
price trend of the ARM family maybe we'll see the 8051 family begin to
restrict itself to it's current base.

> In real world SW engineering portability is NOT a priority for the vast
> majority of systems An embedded system is part of something else. No one
> (bar developers) buys an "embedded system" they buy a clock, camera,
> car, microwave oven etc.

So?  The OP was clearly contemplating switching between compilers.
They weren't talking about buying a microwave oven but a compiler that
would help them (learn to) develop.  And considering they were talking
ARM probably a larger system than a clock.

> As such the cost of the embedded system in the product has to be
> minimised. That is the smallest tightest code using the smallest MCU
> they can get away with the least memory and power consumption.

Cost also includes cost of development.  That's minimized by using the
common standardized language definition and the associated tools that
support it.

> By the time they are looking at changing MCU it is because marketing
> want the device to do a lot more in different ways (often with a new or
> different MMI)  which usually requires a of the majority of the code
> will be new anyway.
>
> However C code should always be written in a modular style and it does
> make sense to try an encapsulate areas where you talk to the hardware or
> use some extensions. Other extensions you will have no choice about.

I did allude to that in the piece you elided.  Yes you sometimes have
to use non-C extensions but you can usually partition them and even
then you are often as far or further ahead to avoid them in favour of
other alternatives.  In some cases you may not have an alternative but
you do cut yourself off from other compilers and tools.

> For example on the 8051  placing variables in to Data, BDATa, XData etc
>
> Embedded SW Engineering is about pragmatically using the right tools for
> the job. Not being religious.

And here I thought I was stating a rather simple fact about the
portability of code between compilers on a single processor ;)

> Incidentally using pure ISO C would mean not using Linux...... It
> requires GCC extensions to compile it. However I don't see anyone
> complaining that Linux is not portable.

I don't know, can you compile it with Visual C++ or Borland C++?
Really that arguments a bit of a non-sequiter given the original
question.

Robert

In article <45449DF9.8432E1A6@yahoo.com>, CBFalconer 
<cbfalconer@yahoo.com> writes
>Chris Hills wrote:
>> <cbfalconer@yahoo.com> writes
>> >Chris Hills wrote:
>>>
>... snip ...
>>>>
>>>> Please explain what you mean by standard C
>>>
>>> A C system that adheres to the ISO C standard as described in:
>>>
>>>  <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf>
>>
>> That document is NOT "Standard C"   It is a Committee Draft.
>>
>> If you tell me it is "close enough" then so is ANY compiler
>> implementation. You can't have it both ways.
>>
>>> or n869.txt (same location)
>>
>> Niether is that the C standard...
>>
>>> or earlier C standards generally known as C89, C90, C95.
>>
>> SO your definition is "any of the documents that are or were ISO or
>> US C standards going back over the last 25 years and/or any of the
>> CD's TC's etc etc that are also produced by WG14  even if they are
>> mutually exclusive. ... snip ...
>
>Yup.  That will do adequately for 99% of the problems.

As will any compiler C with extensions.

>>> Surely you were aware of this.
>>
>> As a longstanding member of the ISO C panel I know what the C
>> standard is and just as importantly what it is not.
>
>Which is why I said 'surely' above.  However you seem to recommend
>abandoning all standards and portability.

Not at all. We need standards. However for the vast majority of embedded 
systems portability is NOT a requirement.

Your glib comment of using "standard C" is sadly meaningless in reality.

>  Somehow I don't think
>you are well received in the 'ISO C panel'.

So now you know the mind of  WG14 and or the NB panels......  I don't 
suppose you have ANY justification or support  for your last statement?


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

In article <ei26ue.1g4.1@stefan.msgid.phost.de>, Stefan Reuther 
<stefan.news@arcor.de> writes
>Chris Hills wrote:
>> However......  Depending on what you are programming and what if any
>> portability is required often you are better sticking with a compiler
>> implementation than the C standard.
>>
>> For example on 8051 most (80%) of the code adheres to the Keil C51 (and
>> there are far more 51's out there than anything else)
>
>But probably it is much easier to find a compiler for a non-8051 CPU
>that adheres to ISO C90 than to find one that adheres to Keil C51's
>language.

Yes but  writing in pure C90 etc is not going to be a very efficient 
8051 program by a long way.

>I routinely compile parts of my embedded code for Win32 - to have
>automated test suites, for example. Whereas my embedded device is
>allowed to require half an hour to decode a 100 MB MP3 file, having my
>PC run the same decoder in a couple of seconds surely helps to validate
>it. Hence, I try to make most parts of my code understandable to PC
>compilers, and ISO C90 (and C++98, in my case) is some sort of a least
>common denominator.

This is OK if the target has the same size ie 8/16/32 bit as the PC. If 
not it is a bit pointless. You should write the code for the target and 
test in the simulator for the target.

>> However C code should always be written in a modular style and it does
>> make sense to try an encapsulate areas where you talk to the hardware or
>> use some extensions. Other extensions you will have no choice about.
>
>Exactly.
>  Stefan

I don't think our positions are too far apart.

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