In message 
<0...@56g2000hsm.googlegroups.com>, 
Tomás Ó hÉilidhe <t...@lavabit.com> writes
>On May 11, 1:43 pm, Chris H <ch...@phaedsys.org> wrote:
>
>> >I've been programming in C as a hobby for about 6 years. As I program
>> >out of hobby, I have the freedom to program however I want. I took an
>> >interest in portable programming from early on.
>>
>> Portable across how many platforms?
>
>
>Every platform for which there is a C compiler which abides by the C
>Standard.
> In order to do this, I have to:
>1) Not invoke behaviour which is deemed to be "undefined" by the
>Standard. (e.g. the overflow of signed integer types, the subtraction
>of pointers that point to different objects)
>2) Not rely on implementation-defined behaviour (e.g. integer
>promotion, the assumption of no padding in structs, assuming a
>function pointer will fit in a void*).

They your code will not run on all C compilers and is likely to be 
hopelessly inefficient.

>> You said:- I'd advocate using types like "uint_fast8_t" instead of
>> "unsigned int"; that way you'll get good performance out of all kinds of
>> machine, whether they be 8-Bit, 16-Bit or 5-billion-Bit.
>>
>> Only if types like uint_fast8_t are implemented.
>They're declared as typdef's in stdint.h.
>
>C89 doesn't include stdint.h, but C99 does. There's many compliant C89
>compilers, but very few compilers that are fully-compliant to C99. I
>think all compilers nowadays have a stdint.h though.

Then you are wrong.

>> >it. You'd be suprised how easy it is to stay fully-portable once you
>> >know the restrictions and freedoms of the C Standard.
>>
>> Which standard? No, it's not a trick question.
>
>The C89 standard.

The ANSI standard?  Not the ISO C95?

> Nowadays, even if compiler doesn't market itself as
>a C99 compiler, it will still tend to implement some of the more
>beneficial features of the C99 standard, such as:

"It will tend" you have made many assumptions.


>C89 is still the dominant standard though.

Not since 1990.....


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On May 11, 3:23=A0pm, Paul Carpenter <p...@pcserviceselectronics.co.uk>
wrote:

> Quite a lot of the posters on here have been programming in various
> forms of C and more platforms, with or without operating systems on the
> target than you will have seen, for longer than you have been ALIVE!


Ever seen an exponential curve? The gaining of expertise is an
exponential curve, whether it be driving a car, playing the guitar,
programming in C.

While it's safe to assume that someone who has been programming for
one month is better than someone who has been programming for one
week, it is _not_ safe to assume that someone who has been programming
for 20 years is better than someone who has been programming for 6
years. Why? Because you're so far along that exponential curve that
time has become negligible and it's more a case of personal potential
and aptitiude.

Just as an example, I've been playing the guitar for 11 years now but
I've seen people who've been playing for 3 years that are better than
me. Ever since I'd been playing for about two years or so, the gains
I've made have become less and less. In fact I'd even hazard a guess
that I played better guitar 9 years ago because I practised a hell of
a lot more.


> Many understand the issues of portability and what CAN and what
> CANNOT be portable in an application.


I know C, I know it very well. I know what's portable and I know
what's portable. I have 6 years experience of programming in C, but
leaving that aside, forgetting that I've any experience, I still would
only have to read the C Standard to see whether a particular action
results in well-defined behaviour, implementation-defined behaviour,
or undefined behaviour. That is ALL there is to it, simple as.


> > Hans-Bernhard:
> > > I consider it much more likely you just didn't look closely enough to =
see
> > > the portability problems in your code.
>
> > If there's a portability problem in a piece of code, I'll know about
> > it. You'd be suprised how easy it is to stay fully-portable once you
> > know the restrictions and freedoms of the C Standard. Here are some of
> > the more "wild" freedoms that you have to keep an eye out for:
>
> Define 'portable', that is NOT a trick question.


Well in terms of programming in abidance to the C89 standard, I would
say portability is:

    "The code will function exactly as intended on every conceivable
implementation of the C89 standard."


> > You could always post a piece of non-portable code and see if I can
> > cop what's wrong with it, that's if really want me to look like a
> > fool. Portable programming is quite easy once you give it attention;
> > I've written quite a few fully-portable programs. The Connect4 game I
> > wrote for my microcontroller will work perfectly on a PC.
>
> So your PC and the microcontroller have the same operating system and
> I/O interfaces then.
>
> Only PART of your code is portable, the WHOLE application is not!


Obviously if you're using an entirely different interface (e.g. a
computer monitor and keyboard instead of LED's and push buttons), then
you're going to have either:
1) A simulator on the PC that will pretend you're using pins
2) A different source file for the PC and the microcontroller when it
comes to input and output.

In my Connect4 program for example, the IO constitutes a small part of
the program. The actual logic of the game is fully-portable: You can
run it on everything from a micrcontroller to PC.

On May 11, 4:15=A0pm, Hans-Bernhard Br=F6ker <HBBroe...@t-online.de>
wrote:

> > Strangely enough, limits.h doesn't tell you how many value-
> > representational bits there are in the various types (except for
> > "char").
>
> That's not strange at all. =A0There's no point in knowing that, so there's=

> no need for <limits.h> to contain that knowledge.


I've used that information several times, as have other C programmers,
hence the need for the IMAX_BITS macro which provides us with a
compile time constant that can even be used for the length of an
array, e.g.:

char array[16];    /* Hardcoded 16 for the amount of bits in an int */

char array[IMAX_BITS( (unsigned)-1 )];   /* Magically get the figure
for us */

Just as an aside, what IMAX_BITS actually does is it takes a number
where there's an uninterrupted sequence of one's, .e.g:

    00000000111111111111111111111111

and then tells you how many one's there are set in it. By giving it
"(unsigned)-1", you're passing it the maximum value for an unsigned
int.

In message <MPG.22911196206ca647989682@172.16.0.1>, Paul Carpenter 
<p...@pcserviceselectronics.co.uk> writes
>In article <85a33b38-07b5-4503-80a8-
>b...@c58g2000hsc.googlegroups.com>, t...@lavabit.com says...
>>
>> Tim:
>> > Chances are good that you're pontificating to someone who's been earning
>> > money at this game since before you were an orgasm.
>> >
>> > So is your experience vast, or your statement half-vast
>>
>>
>> I've been programming in C as a hobby for about 6 years. As I program
>> out of hobby, I have the freedom to program however I want. I took an
>> interest in portable programming from early on.
>
>Quite a lot of the posters on here have been programming in various
>forms of C and more platforms, with or without operating systems on the
>target than you will have seen, for longer than you have been ALIVE!
>
>Many understand the issues of portability and what CAN and what
>CANNOT be portable in an application.

Never mind the portability. What about efficiency?  Code that will run 
well on a 32bit system is not likely to run well on an 8 bit system. You 
would have to re-write it to work well with the smaller system.

The poster is being very over simplistic I think.  Also pure ISO C will 
not be completely portable across 8-32 bit systems (efficiently if at 
all) without a lot of thought

Some systems eg 8 bit will use char rather than int for everything that 
can fit in a char.  16-31 bit systems default to char.

Whilst it is true that C is portable  it is  effectively a high level 
assembler.

I can supply commercial C source code for many things    (RTOS, Stacks 
file systems etc) whilst the API's are all  constant much of the source 
is dependant on the target MCU and the compiler used.   The underlying 
HW is different, the size and number of registers is different so the 
way  things are done is different.

It is not as simple as only using the well defined parts of C. Anyone 
who things that is all you need to do does not really grasp the problem.

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On May 11, 4:46=A0pm, Chris H <ch...@phaedsys.org> wrote:

> >Every platform for which there is a C compiler which abides by the C
> >Standard.
> > In order to do this, I have to:
> >1) Not invoke behaviour which is deemed to be "undefined" by the
> >Standard. (e.g. the overflow of signed integer types, the subtraction
> >of pointers that point to different objects)
> >2) Not rely on implementation-defined behaviour (e.g. integer
> >promotion, the assumption of no padding in structs, assuming a
> >function pointer will fit in a void*).
>
> They your code will not run on all C compilers and is likely to be
> hopelessly inefficient.


Elaborate on that. I know you're wrong, but I'd still like to see what
you think you're right.


> >C89 doesn't include stdint.h, but C99 does. There's many compliant C89
> >compilers, but very few compilers that are fully-compliant to C99. I
> >think all compilers nowadays have a stdint.h though.
>
> Then you are wrong.


Give me an example of a compiler that doesn't have an stdint.h. I know
PIC C doesn't, but that's the only one I'm aware of.

For every one you mention that doesn't have stdint.h, I can give you
several examples of the contrary.


> >> >it. You'd be suprised how easy it is to stay fully-portable once you
> >> >know the restrictions and freedoms of the C Standard.
>
> >> Which standard? No, it's not a trick question.
>
> >The C89 standard.
>
> The ANSI standard? =A0Not the ISO C95?


Not the 1989 standard, also known as the 1990 standard. That's
actually no difference between them other than editorial stuff, e.g.
re-ordering of the index at the start.


> > Nowadays, even if compiler doesn't market itself as
> >a C99 compiler, it will still tend to implement some of the more
> >beneficial features of the C99 standard, such as:
>
> "It will tend" you have made many assumptions.


You blindly assume that I exploit these C99 features when writing C89
code. I don't.


> >C89 is still the dominant standard though.
>
> Not since 1990.....


Nope, still 1989.

On May 11, 4:56=A0pm, Chris H <ch...@phaedsys.org> wrote:

> Never mind the portability. What about efficiency? =A0Code that will run
> well on a 32bit system is not likely to run well on an 8 bit system. You
> would have to re-write it to work well with the smaller system.


Again with the blind, sweeping statements. I find it incredibly easy
to accomodate both microcontrollers and PC's when writing fully-
portable code.


> The poster is being very over simplistic I think. =A0Also pure ISO C will
> not be completely portable across 8-32 bit systems (efficiently if at
> all) without a lot of thought.


It's been done. There are some quirks when it comes to some
microcontroller compilers, e.g. the placement of auto variables on a
stack, but good microcontroller compilers have a small finite list of
ways in which the flout the Standard.

In message 
<3...@e39g2000hsf.googlegroups.com>, 
Tomás Ó hÉilidhe <t...@lavabit.com> writes
>On May 11, 4:46 pm, Chris H <ch...@phaedsys.org> wrote:
>
>> >Every platform for which there is a C compiler which abides by the C
>> >Standard.
>> > In order to do this, I have to:
>> >1) Not invoke behaviour which is deemed to be "undefined" by the
>> >Standard. (e.g. the overflow of signed integer types, the subtraction
>> >of pointers that point to different objects)
>> >2) Not rely on implementation-defined behaviour (e.g. integer
>> >promotion, the assumption of no padding in structs, assuming a
>> >function pointer will fit in a void*).
>>
>> They your code will not run on all C compilers and is likely to be
>> hopelessly inefficient.
>
>
>Elaborate on that. I know you're wrong,

With stupidity like that I am not going to continue.


>> >C89 doesn't include stdint.h, but C99 does. There's many compliant C89
>> >compilers, but very few compilers that are fully-compliant to C99. I
>> >think all compilers nowadays have a stdint.h though.
>> Then you are wrong.
>Give me an example of a compiler that doesn't have an stdint.h. I know
>PIC C doesn't, but that's the only one I'm aware of.

Then I suspect you are working with a limited knowledge.

>For every one you mention that doesn't have stdint.h, I can give you
>several examples of the contrary.

I am sure you could but if only 1 doesn't have it your code is not 
portable.

>> >> >it. You'd be suprised how easy it is to stay fully-portable once you
>> >> >know the restrictions and freedoms of the C Standard.
>> >> Which standard? No, it's not a trick question.
>> >The C89 standard.
>> The ANSI standard?  Not the ISO C95?
>Not the 1989 standard, also known as the 1990 standard.

No it's not

>> >C89 is still the dominant standard though.
>> Not since 1990.....
>Nope, still 1989.

You don't understand.
-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In message 
<f...@34g2000hsh.googlegroups.com>, 
Tomás Ó hÉilidhe <t...@lavabit.com> writes
>I know C, I know it very well. I know what's portable and I know
>what's portable. I have 6 years experience of programming in C, but
>leaving that aside, forgetting that I've any experience, I still would
>only have to read the C Standard to see whether a particular action
>results in well-defined behaviour, implementation-defined behaviour,
>or undefined behaviour. That is ALL there is to it, simple as.

Not by a long way.... you have much to learn.


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

David Brown <d...@hesbynett.removethisbit.no> writes:
> Tomás Ó hÉilidhe wrote:
> > On May 10, 9:11 am, "aamer" <raqeeb...@yahoo.com> wrote:
> >>
> >> Are there any hard and fast rules for code optimization
> >> in C targetting a processor?
[snip]
> > Another thing would be about the use of the post-increment and post-
> > decrement operators in a conditional. For instance:
> > 
> > void strcpy(char *dst, char const *src)
> > {
> >     while (*dst++ = *src++);
> > }
> > 
> > The idiom of using *p++ is widespread, but unfortunately its use is no
> > longer advisable because hardware has moved on. I think it was the
> > PDP11 that had a single instruction for dereferencing a pointer and
> > also incrementing it at the same time, thus it was beneficial to use *p
> > ++ wherever possible -- however modern machines don't have such an
> > instruction, so the assembler produced for *p++ when used as the
> > conditional in an if statement, for instance, might be sub-optimal.

Many of the "bigger" processors (68K family, ARM, etc.) do have such
a capability.  The compiler has to support the operation regardless
of how it does it, so use of the auto-increment/decrement construct
at the source level shouldn't be a liability.

> > So I'd say opt for:
> > 
> >     for ( ; *dst = *src; ++dst, ++src) ;
> 
> In any code review, that form would be taken out and shot.

It took me quite awhile to realize that it even produced the
desired result...

[snip]

In message 
<7...@m45g2000hsb.googlegroups.com>, 
Tomás Ó hÉilidhe <t...@lavabit.com> writes
>On May 11, 4:56 pm, Chris H <ch...@phaedsys.org> wrote:
>
>> Never mind the portability. What about efficiency?  Code that will run
>> well on a 32bit system is not likely to run well on an 8 bit system. You
>> would have to re-write it to work well with the smaller system.
>
>
>Again with the blind, sweeping statements. I find it incredibly easy
>to accomodate both microcontrollers and PC's when writing fully-
>portable code.
>

Having read  the threads you are currently in on this NG I can only 
conclude you are  a self deluded idiot.

What do you do for a full time job?


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/