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

It is certainly true that the optimiser may well avoid any differences. 
  This is especially true in loops - the compiler can often use strength 
reduction to turn the array lookup into pointer arithmetic, and it can 
turn a signed int index variable into an unsigned char if that's what 
works best on the target (assuming it knows the bounds of the loop). 
That's why it's important to benchmark code, and examine generated 
assembly code, before doing any source-code optimisations.

But there is certainly no point in having a rule like "use signed types 
for loop indexes" which gives less clear source code (unsigned types are 
often more appropriate for the logic of the program), and leads to 
slower and bigger code in some cases.

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

RSA encryption routine.
Plain text in and cipher text out via RS232 serial

8051    (keil compiler)
ST10  (Cosmic Compiler)
Coldfire (IAR compiler and Sciopta RTOS)
ARM7  (GHS compiler )
6809  (Crossware compiler)
PPc 860  (Code Warrior compiler )
MSP430  (Crossworks compiler)
AVR    (AVR Studio)
C6808 (ByteCraft compiler)


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

In message <P...@lyse.net>, David Brown 
<d...@hesbynett.removethisbit.no> writes
>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.


David, I have had a private email from Tomas. As it was private I won't 
post it here.   Given what he says about some jobs he has had and the 
manner of his leaving several I would say:

1 He is deluded
2 unemployable
3 not likely to write effective code compliant to anyone else's standard 
but his own.

As you said:-
>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.

He has had trouble and apparently more than once.

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

He does not appear to have learnt his lesson but still thinks he has the 
"higher moral ground"

> They *will* employ someone who is ready and willing to learn how 
>embedded design works in reality.

Very true. I have worked many places where even new graduates had to do 
an "apprenticeship" of sorts under the guidance of someone experienced 
before they were seen as a competent novice.


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

Don't ask me how I came up with the signed/unsigned loop counter thing. 
I could have sworn that signed is faster because the compiler may assume 
no overflow and thus has a easier job at unrolling/modulo scheduling.

Not so! I compiled a bunch of routines with and without signed counters 
and it didn't made any difference.

You're all right of course. It does not make a difference except for 
architecture specific nuances.

   Nils

Nils wrote:
> Don't ask me how I came up with the signed/unsigned loop counter thing. 
> I could have sworn that signed is faster because the compiler may assume 
> no overflow and thus has a easier job at unrolling/modulo scheduling.
> 
> Not so! I compiled a bunch of routines with and without signed counters 
> and it didn't made any difference.
> 
> You're all right of course. It does not make a difference except for 
> architecture specific nuances.
> 
>   Nils

In a large number of loops, the compiler can be sure that there is no 
overflow, simply because it knows the bounds of the loops.  If it does 
not know, then it is equally ignorant for signed and unsigned types. 
The only real difference is what happens to the value during an overflow 
(I know the standard makes a difference, but for any practical 
architecture in c.a.e., you have either twos-compliment arithmetic with 
obvious overflow effects, or some sort of DSP saturated arithmetic).

In article <Z...@lyse.net>, 
d...@hesbynett.removethisbit.no says...
> Nils wrote:
> > Don't ask me how I came up with the signed/unsigned loop counter thing. 
> > I could have sworn that signed is faster because the compiler may assume 
> > no overflow and thus has a easier job at unrolling/modulo scheduling.
> > 
> > Not so! I compiled a bunch of routines with and without signed counters 
> > and it didn't made any difference.
> > 
> > You're all right of course. It does not make a difference except for 
> > architecture specific nuances.
> > 
> >   Nils
> 
> In a large number of loops, the compiler can be sure that there is no 
> overflow, simply because it knows the bounds of the loops.  If it does 
> not know, then it is equally ignorant for signed and unsigned types. 
> The only real difference is what happens to the value during an overflow 
> (I know the standard makes a difference, but for any practical 
> architecture in c.a.e., you have either twos-compliment arithmetic with 
> obvious overflow effects, or some sort of DSP saturated arithmetic).

Considering this c.a.e, knowing bounds/limits of every stage especially
for real world I/O interactions and partial calculations is one of the 
main problems people get wrong.

This also relates to loops as many calculations/decisions involve loops.

The classic case of getting it wrong I ever saw was on a graphical demo
for a data acquisition package that was wrong in so many ways!

Basic demo was a furnace oven, being continually heated, with simple
control open/close door. Opening door lowered oven temperature, closing 
door raised oven temperature. They were two measurements ambient and oven 
temperature. Demo could run to +/-infinity (in reality the 
floating point on that PC representation of infinity), just because it
was left open or closed. So many basic laws of thermodynamics were
thrown out the window.

Wonder if anybody else recognises that demo program?

To Tomas can you recognise the function that was not bounded and 
what it should have been bounded to?

-- 
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 12, 11:40=A0am, Chris H <ch...@phaedsys.org> wrote:

> David, I have had a private email from Tomas. As it was private I won't
> post it here. =A0 Given what he says about some jobs he has had and the
> manner of his leaving several I would say:
>
> 1 He is deluded
> 2 unemployable
> 3 not likely to write effective code compliant to anyone else's standard
> but his own.


You're some character. You seem to spend a lot of your time attempting
to discredit me, is there a reason for that? It's quite pathetic
actually that you'll spend your time private-emailing and discussing
me on a newsgroup. I'd say it's flattering but really it isn't, I mean
you're just sad.


> He does not appear to have learnt his lesson but still thinks he has the
> "higher moral ground"


Do you speak English? For the umpteenth time, I invite you to show one
instance of me being rude to someone who has been courteous to me.
Until you can provide such evidence, shut up.

Don't address any corresondence to me, whether it be private or
public, I've no interest.