In message <6...@mid.uni-berlin.de>, Nils 
<n...@cubic.org> writes
>My main-points (for speed and size) are:
>
>7. Embedded CPU's often have small caches

Most have no cache.

> and slow external memory.

Not always true.

>And last: It's not worth to outsmart the compiler.

Absolutely. It usually hampers the compiler.

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

Tomás Ó hÉilidhe wrote:

> I write fully-portable code all the time and I find it to be a simple
> task a lot of the time.

Given the cavalier attitude to robustness you've consistently expressed 
here, I find it hard to give this statement much credibility.  I 
consider it much more likely you just didn't look closely enough to see 
the portability problems in your code.

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.


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:
* Integer types may contain padding bits, and so sizeof(type) *
CHAR_BIT won't necessarily give you the amount of bits in a integer
type.
* The null pointer constant need not be all-bits-zero, thus using
memset(p,0,sizeof p) to set it has undefined behaviour according to
the Standard. Same goes for float and double.
* Types smaller than int always promote to signed int, unless you're
dealing with an small unsigned type whose greatest value is greater
than INT_MAX, in which case it promotes to unsigned int.

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.

In message 
<8...@c58g2000hsc.googlegroups.com>, 
Tomás Ó hÉilidhe <t...@lavabit.com> writes
>
>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.

Portable across how many platforms?

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.

>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.


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

Tomás Ó hÉilidhe wrote:

> * Integer types may contain padding bits, and so sizeof(type) *
> CHAR_BIT won't necessarily give you the amount of bits in a integer
> type.

On the contrary, that's exactly what it gives you: the amount of bits in 
the type.  That's not the same as the amount of bits in the value. 
That's what you get <limits.h> for.

That set aside, I wonder how someone with this level attention to detail 
in one field, could be so recklessly resistent to advice in others.

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.
 
> 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.

.....

> 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!

-- 
Paul Carpenter          | p...@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>;    PC Services
<http://www.pcserviceselectronics.co.uk/fonts/>; Timing Diagram Font
<http://www.gnuh8.org.uk/>;  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/>; For those web sites you hate

On May 11, 2:26=A0pm, Hans-Bernhard Br=F6ker <HBBroe...@t-online.de>
wrote:
> Tom=E1s =D3 h=C9ilidhe wrote:
> > * Integer types may contain padding bits, and so sizeof(type) *
> > CHAR_BIT won't necessarily give you the amount of bits in a integer
> > type.
>
> On the contrary, that's exactly what it gives you: the amount of bits in
> the type. =A0That's not the same as the amount of bits in the value.
> That's what you get <limits.h> for.


The C Standard calls them "value representational bits".

Strangely enough, limits.h doesn't tell you how many value-
representational bits there are in the various types (except for
"char"). Using constants such as UINT_MAX, ULONG_MAX, though, you can
narrow it down. There is, however, a clever macro called IMAX_BITS
which can be used to determine the quantity value-representational
bits in any integer type on any system.


> That set aside, I wonder how someone with this level attention to detail
> in one field, could be so recklessly resistent to advice in others.


I'm taking people's advice on board here, and I'm redesigning my
circuit. I've even been making up small circuits on my bread board and
using an ammeter to measure the current going through the LED's. The
next incarnation of my Connect4 board will have plenty of 250 ohm
resistors. :-D

On May 11, 1:43=A0pm, 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*).


> 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. And for the few
that don't, you can always write a little one yourself, for example
here'd be one appropriate for the PIC16F684:

typedef char unsigned uint_fast8_t;
typedef unsigned uint_fast16_t;
typedef long unsigned uint_fast32_t;


> >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. 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:

* stdint.h
* compound literals (e.g. being able to write (int[2])(5,6) as an R-
value)
* the "inline" keyword for functions

C89 is still the dominant standard though.

Tomás Ó hÉilidhe 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.  There's no point in knowing that, so there's 
no need for <limits.h> to contain that knowledge.

Chris H schrieb:

>> 7. Embedded CPU's often have small caches
> 
> Most have no cache.
> 
>> and slow external memory.
> 
> Not always true.

Oh well, yes. It's written from the perspective of the CPUs I have to 
deal with at work. That's mostly ARM and DSP. Also MIPS-variants, SH4 
and so on.

E.g. CPUs that have roughly the number-crunching power as a 8 year old 
PC. All these had cache so far. Sometimes just 4k, sometimes a bit more..

In my experience on such CPUs memory bandwidth is the limiting factor 
unless the code is unoptimized beyond hope.

Cheers,
   Nils