code optimiation

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.

Reply to
David Brown
Loading thread data ...

Yeah and I get the idea you're a bit of a d*****ad.

Reply to
Tomás Ó hÉilidhe

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

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.

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.

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?

Reply to
Tomás Ó hÉilidhe

In message , Tomás Ó hÉilidhe writes

You are wrong

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

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
 Click to see the full signature
Reply to
Chris H

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.

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

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.

Reply to
David Brown

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

Reply to
David Brown

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.

Reply to
Dombo

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.

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.

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

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.

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.

Reply to
Tomás Ó hÉilidhe

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.

Reply to
David Brown

In message , Tomás Ó hÉilidhe writes

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     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H

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

He has had trouble and apparently more than once.

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

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     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H

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

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

Reply to
David Brown

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          | paul@pcserviceselectronics.co.uk
    PC Services
 Click to see the full signature
Reply to
Paul Carpenter

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.

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.

Reply to
Tomás Ó hÉilidhe

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.