Tomás Ó hÉilidhe schreef:
> On May 11, 3:23 pm, 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.

My experience with multi-platform development is one can claim something 
is portable across *certain* targets only after one has build for each 
individual target, tested it on those targets and confirmed that it does 
behave as specified on those targets. Claiming that something is *fully* 
portable would imply you would have done all that for any conceivable 
platform with any conceivable compiler.

Sticking to the constructs that are the well-defined in the standard is 
a good start for making things portable, but is by no means sufficient 
to be able to claim that your code is *fully* portable. Even if you 
limit your claim to compilers that claim to be fully compliant with the 
standard you may still encounter corner cases were different compilers 
do yield different behavior. Sometimes because the compiler knowingly or 
unknowingly deviates from the standard, or because of ambiguities in the 
standard.

Tomás Ó hÉilidhe wrote:
> On May 10, 8:19 pm, David Brown
> <david.br...@hesbynett.removethisbit.no> wrote:
> 
>> It is virtually impossible to write fully portable code - and totally
>> impossible within the world of embedded programming.  Forget the
>> machines that have weird values for zeros, or bizarre numbers of bits
>> (although some DSP's have 16-bit or 32-bit chars), or something other
>> than two's complement arithmetic, or non-ASCII for their basic character
>> set.  It's not worth it - code suitable for an ARM is not suitable for
>> running on a 1970's mainframe anyway.
> 
> 
> I write fully-portable code all the time and I find it to be a simple
> task a lot of the time. The C Standard provides you with plenty of
> information to write fully-portable algorithms and programs.

I haven't seem much indication from your posts that you can write 
legible C code at all, never mind "fully portable" code (to the extent 
that such a thing really exists).  Portability is a gradual scale, not 
an absolute - you can write code that is more or less portable, across a 
smaller or wider range of targets, compilers and standards.  Only a fool 
considers "portability", in whatever form you mean, to be the main goal 
for writing C code - it's merely one of the many factors that you can 
aim for or ignore when writing code.  You balance it with things like 
code legibility and maintainability, code size and speed, programmer 
productivity, and many other issues that are often far more important in 
the real world.

Tim is not quite right - I haven't been earning money at embedded 
programming since before you were born - merely since you were about 5 
or 6 years old.  There are others in this group who've been at it much 
longer.  You are even trying to argue about C standards with people who 
not only have been programming C for longer than you've been alive, but 
who have been heavily involved in defining the standards themselves.

If you want to find some kids to impress with your great knowledge and 
experience, this is not the place for it.  If you want to have a useful 
discussion, and learn a lot from more experienced developers, and maybe 
give us a few new ideas too (you don't last in embedded development if 
you think you know it all), then stick around.  Listen to others here, 
and join in when you're ready to learn.

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

> Having read =A0the threads you are currently in on this NG I can only
> conclude you are =A0a self deluded idiot.


Yeah and I get the idea you're a bit of a dickhead.

On May 11, 11:25=A0pm, David Brown
<david.br...@hesbynett.removethisbit.no> wrote:

> I haven't seem much indication from your posts that you can write
> legible C code at all, never mind "fully portable" code (to the extent
> that such a thing really exists).


I don't think I've posted any C code here on comp.arch.embedded.


> =A0Portability is a gradual scale, not
> an absolute - you can write code that is more or less portable, across a
> smaller or wider range of targets, compilers and standards. =A0Only a fool=

> considers "portability", in whatever form you mean, to be the main goal
> for writing C code - it's merely one of the many factors that you can
> aim for or ignore when writing code. =A0You balance it with things like
> code legibility and maintainability, code size and speed, programmer
> productivity, and many other issues that are often far more important in
> the real world.


If you're used to writing fully-portable code, then it's a trivial
exercise to "keep things portable" as you move along. Sometimes it's
as simple as CHAR_BIT instead of a hardcoded 8.


> Tim is not quite right - I haven't been earning money at embedded
> programming since before you were born - merely since you were about 5
> or 6 years old. =A0There are others in this group who've been at it much
> longer. =A0You are even trying to argue about C standards with people who
> not only have been programming C for longer than you've been alive, but
> who have been heavily involved in defining the standards themselves.


I don't have to argue about the C Standard, I know what I'm talking
about. We can take the discussion over to comp.lang.c if  you really
want to get into it.


> If you want to find some kids to impress with your great knowledge and
> experience, this is not the place for it. =A0If you want to have a useful
> discussion, and learn a lot from more experienced developers, and maybe
> give us a few new ideas too (you don't last in embedded development if
> you think you know it all), then stick around. =A0Listen to others here,
> and join in when you're ready to learn


Em.... amn't I the person who's asked about a thousand questions in
the last month.. ? How many active threads are there here that were
started by me asking questions?

David Brown wrote:

> Using the "fast" types can make sense, especially for speed-critical 
> code.  There are advantages in using the size-specific types, however - 
> specifying "uint8_t" rather than "uint_fast8_t" may let the compiler (or 
> linter) spot range errors that would not be found if "uint_fast8_t" 
> boils down to a 32-bit value.

That may be a benefit for some compilers or half-baked lint, but I expect a 
good static checker to warn for expressions exceeding 8 bits for 
uint_fast8_t, regardless of the nominal target.

-- 
Thad

In message 
<4...@p25g2000hsf.googlegroups.com>, 
Tomás Ó hÉilidhe <t...@lavabit.com> writes
>On May 11, 11:25 pm, David Brown
><david.br...@hesbynett.removethisbit.no> wrote:
>
>If you're used to writing fully-portable code, then it's a trivial
>exercise to "keep things portable" as you move along.

You are wrong

>> Tim is not quite right - I haven't been earning money at embedded
>> programming since before you were born - merely since you were about 5
>> or 6 years old.  There are others in this group who've been at it much
>> longer.  You are even trying to argue about C standards with people who
>> not only have been programming C for longer than you've been alive, but
>> who have been heavily involved in defining the standards themselves.
>
>
>I don't have to argue about the C Standard, I know what I'm talking
>about.

No you don't.  I can see that and  I am not the greatest expert here. 
There are others far more knowledgeable than me you have told are wrong

 > We can take the discussion over to comp.lang.c if
 > you really want to get into it.

As for moving to C.L.C you will get eaten alive for you complete lack of 
knowledge and your attitude.  You have already pissed of some of the 
main contributors to C.L.C who are also on this NG.

Actually I have noticed that in the several threads you are in on both 
the embedded and c.l.c you are being told by everyone that most of your 
"facts" are wrong.

If you really want to be taken apart you could go on to the C standards 
NG... They don't suffer idiots gladly and they will kill file you in 
minutes.

Until you realise you know a LOT less than you think you do (a common 
mistake of novices) and change your attitude you will get know where.

-- 
Chris Hills  Phaedrus Systems Ltd

Eur. Ing. Chris Hills  BSc(Hons), CEng, MIEE, MBCS, MIEEE, FRGS
Member of ISO/BSI C and C++ Standards Panel
Member of ISO High-Integrity Study Group
Member of MISRA-C Steering Committee
Chair  of MISRA-Languages Panel
Member of IEE Tech Advisory Panel for  Microelectronics & Embedded Systems

Tomás Ó hÉilidhe wrote:
> On May 11, 11:25 pm, David Brown
> <david.br...@hesbynett.removethisbit.no> wrote:
> 
>> I haven't seem much indication from your posts that you can write
>> legible C code at all, never mind "fully portable" code (to the extent
>> that such a thing really exists).
> 
> 
> I don't think I've posted any C code here on comp.arch.embedded.
> 

You don't have to post C (although you've posted snippets).  We're 
getting a pretty good idea of the way you think from your posts.  Note 
also exactly what I wrote - it doesn't preclude you writing good C code, 
you just haven't given any basis for us to believe that you can write 
good code.  Pretentious "my code is more portable than your code" 
programs do not count as "good" code here in the real world.



> 
>>  Portability is a gradual scale, not
>> an absolute - you can write code that is more or less portable, across a
>> smaller or wider range of targets, compilers and standards.  Only a fool
>> considers "portability", in whatever form you mean, to be the main goal
>> for writing C code - it's merely one of the many factors that you can
>> aim for or ignore when writing code.  You balance it with things like
>> code legibility and maintainability, code size and speed, programmer
>> productivity, and many other issues that are often far more important in
>> the real world.
> 
> 
> If you're used to writing fully-portable code, then it's a trivial
> exercise to "keep things portable" as you move along. Sometimes it's
> as simple as CHAR_BIT instead of a hardcoded 8.
> 
> 
>> Tim is not quite right - I haven't been earning money at embedded
>> programming since before you were born - merely since you were about 5
>> or 6 years old.  There are others in this group who've been at it much
>> longer.  You are even trying to argue about C standards with people who
>> not only have been programming C for longer than you've been alive, but
>> who have been heavily involved in defining the standards themselves.
> 
> 
> I don't have to argue about the C Standard, I know what I'm talking
> about. We can take the discussion over to comp.lang.c if  you really
> want to get into it.
> 

The comp.lang.c language lawyers live in an ivory tower. 
comp.arch.embedded is a group for real-world professionals and serious 
hobby developers who make real working systems for real companies.  We 
don't whine about "but the standard says..." - we write code that works 
on actual targets, compiled with real compilers, not some theoretical 
pure standards-compliant complier.

For us, "portable" code might just as well mean "works on version 1.01 
of the hardware as well as version 1.00".  Or it might mean "compiles 
using two different compilers for the same target, despite their 
different non-standard extensions".  Or it might mean "works well on 
8-bit, 16-bit and 32-bit targets".

Similarly, "standards-compliant" might mean C89, ANSI, or C99 standards. 
  It might mean "limited C99 with gcc extensions as supported by 
Metrowerks".  It might mean "coded to MISRA standards", or "coded to our 
company's standards".

> 
>> If you want to find some kids to impress with your great knowledge and
>> experience, this is not the place for it.  If you want to have a useful
>> discussion, and learn a lot from more experienced developers, and maybe
>> give us a few new ideas too (you don't last in embedded development if
>> you think you know it all), then stick around.  Listen to others here,
>> and join in when you're ready to learn
> 
> 
> Em.... amn't I the person who's asked about a thousand questions in
> the last month.. ? How many active threads are there here that were
> started by me asking questions?

No, you're the one that has written about a thousand posts telling us 
how *you* make your electronics, and how principles of good engineering 
and design don't apply to you or devices you intend to make.  I see you 
listening to some details of the electronics, but arguing against any 
attempt to show you the basics that will improve all your work 
(electronics and programming).

You've clearly got the interest, enthusiasm and aptitude for embedded 
design.  But unless you understand the limits of your knowledge, and 
that the real world is far removed from your books, standards documents, 
and connect four games, you are going to have trouble doing professional 
work.  No one is going to employ an over-grown teenager who thinks he 
knows it all (or at least, they won't employ you for long).  They *will* 
employ someone who is ready and willing to learn how embedded design 
works in reality.

Grant Edwards wrote:
> On 2008-05-10, Tom <t...@nospam.com> wrote:
>> In article <6...@mid.uni-berlin.de>, Nils <n...@cubic.org> wrote:
>>> My main-points (for speed and size) are:
>>> 5. Don't use unsigned integers for loop-variables unless you need the 
>>> wrap-around feature.
>> Not necessarily true:
>>
>> ...................    while (my_unsigned8var < 5) {}
>> 1BF0:  MOVF   x85,W
>> 1BF2:  SUBLW  04
>> 1BF4:  BNC   1BF8
>> 1BF6:  BRA    1BF0
>> ...................    while (my_signed8var < 5) {}
>> 1BF8:  BTFSC  x86.7
>> 1BFA:  BRA    1C02
>> 1BFC:  MOVF   x86,W
>> 1BFE:  SUBLW  04
>> 1C00:  BNC   1C04
>> 1C02:  BRA    1BF8
>> ...................
>>
>> On this particular combination of target and compiler (PIC18 with CCS C) 
>> unsigned in always faster than signed.
> 
> I've seen various other compilers/targets where use of unsigned
> loop indexes is faster.  For example, one of the tips/tricks
> listed when using GCC for the MSP430 target:
> 
>   Tips and trick for efficient programming
> 
>     [...]
>     
>     10. Use unsigned int for indices - the compiler will snip
>         _lots_ of code.
> 
> On second thought, that might be refering to array indexes
> instead of loop indexes.  Hmm...
>         

Unsigned multiplication can often be faster than signed multiplication, 
so array indices are often best done using unsigned types (it also 
seldom makes sense to use signed data as an index).

There are also other cases where unsigned types are more efficient than 
signed types, especially for small and limited cpus and when using data 
that is bigger than the bit size of the cpu.  In particular, comparisons 
such as in your loop can require bigger and slower code for signed types.

So Nils rule 5 "don't use unsigned integers for loop variables" is 
basically rubbish (his other rules are mostly fair, with varying degrees 
of relevance).

David Brown schreef:
> Grant Edwards wrote:
>> On 2008-05-10, Tom <t...@nospam.com> wrote:
>>> In article <6...@mid.uni-berlin.de>, Nils 
>>> <n...@cubic.org> wrote:
>>>> My main-points (for speed and size) are:
>>>> 5. Don't use unsigned integers for loop-variables unless you need 
>>>> the wrap-around feature.
>>> Not necessarily true:
>>>
>>> ...................    while (my_unsigned8var < 5) {}
>>> 1BF0:  MOVF   x85,W
>>> 1BF2:  SUBLW  04
>>> 1BF4:  BNC   1BF8
>>> 1BF6:  BRA    1BF0
>>> ...................    while (my_signed8var < 5) {}
>>> 1BF8:  BTFSC  x86.7
>>> 1BFA:  BRA    1C02
>>> 1BFC:  MOVF   x86,W
>>> 1BFE:  SUBLW  04
>>> 1C00:  BNC   1C04
>>> 1C02:  BRA    1BF8
>>> ...................
>>>
>>> On this particular combination of target and compiler (PIC18 with CCS 
>>> C) unsigned in always faster than signed.
>>
>> I've seen various other compilers/targets where use of unsigned
>> loop indexes is faster.  For example, one of the tips/tricks
>> listed when using GCC for the MSP430 target:
>>
>>   Tips and trick for efficient programming
>>
>>     [...]
>>         10. Use unsigned int for indices - the compiler will snip
>>         _lots_ of code.
>>
>> On second thought, that might be refering to array indexes
>> instead of loop indexes.  Hmm...
>>         
> 
> Unsigned multiplication can often be faster than signed multiplication, 
> so array indices are often best done using unsigned types (it also 
> seldom makes sense to use signed data as an index).

It may very well make no difference at all. For example when iterating 
over the elements of an array, the compiler may decide to just advance 
the pointer used to access array elements by the size of the array 
element with each iteration (as opposed to fully calculating the address 
each iteration). The results of optimization attempts that were based on 
assumptions are often very disappointing.

On May 12, 7:12=A0am, Chris H <ch...@phaedsys.org> wrote:

> >it's a trivial
> >exercise to "keep things portable" as you move along.
>
> You are wrong


OK then I'll rephrase that:

    If find it a trivial exercise to "keep things portable" as I go
along.

Incredibly trivial if truth be told.


> >I don't have to argue about the C Standard, I know what I'm talking
> >about.
>
> No you don't. =A0I can see that and =A0I am not the greatest expert here.
> There are others far more knowledgeable than me you have told are wrong


Yes I have, in regard to portable programming in C, reason being that
I know portable programming in C. You'll notice I don't correct them
on things that they know more about than me.


> =A0> We can take the discussion over to comp.lang.c if
> =A0> you really want to get into it.
>
> As for moving to C.L.C you will get eaten alive for you complete lack of
> knowledge and your attitude. =A0You have already pissed of some of the
> main contributors to C.L.C who are also on this NG.


Yes I have, I seem to have pissed off Jack Klein and Richard
Heathfield over on comp.lang.c. Why? Well firstly, Jack Klein was
incredibly rude and hostile to me from the offset, so I didn't place
much weight in being courteous to him. It would seem Richard's pissed
off at me for being rude to Jack. He's welcome to "choose his side",
but it's no reflection on me.

Again I invite anyone here to give me any example of where I've been
rude to anyone who has been courteous to me.


> Actually I have noticed that in the several threads you are in on both
> the embedded and c.l.c you are being told by everyone that most of your
> "facts" are wrong.


Actually you'll find that I've only posted ONE wrong fact recently --
I mixed up the semantics of coverting unsigned to signed with the
semantic of converting signed to unsigned. I was soon corrected and
acknowledged my mistake. Now for that one mistake I made I invite you
to count how many true "facts" I posted.


> If you really want to be taken apart you could go on to the C standards
> NG... They don't suffer idiots gladly and they will kill file you in
> minutes.


I'm quite familiar with the audience at comp.lang.c and comp.std.c. I
get along fine with most of them, but quite a few of them are hostile
and rude.


> Until you realise you know a LOT less than you think you do (a common
> mistake of novices) and change your attitude you will get nowhere.


I welcome you to prove how bad I am at programming. Pose a C question,
or perhaps ask me to write a small algorithm, that way you can see how
crap and non-portable my coding is. Go ahead.