Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0);

Reply
Thread Tools

do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0);

 
 
Willem
Guest
Posts: n/a
 
      07-29-2011
James Kuyper wrote:
) If so, his point was wrong. C provides no way to specify such details. C
) source code which you might imagine specifies generation of one
) particular sequence of assembly language instructions on a given
) platform does nothing of the sort. A conforming compiler for that
) platform can translate that code into any other sequence that produces
) the same result.

Technically/pedantically, yes. Practically, given a known compiler,
you can most certainly influence the output by the choice of C code.
The case in point is if the compiler would use a variable or not for
a certain construct, and that seems entirely plausible.

I would imagine that C compilers that target embedded systems could
even document this to an extent, given that embedded programmers care
so much about such issues.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
 
Reply With Quote
 
 
 
 
Thomas Boell
Guest
Posts: n/a
 
      07-29-2011
On Fri, 29 Jul 2011 10:42:10 -0400
James Kuyper <(E-Mail Removed)> wrote:

> On 07/29/2011 09:58 AM, Thomas Boell wrote:
> > On Fri, 29 Jul 2011 09:23:27 -0400
> > James Kuyper <(E-Mail Removed)> wrote:
> >
> >> On 07/29/2011 08:38 AM, Thomas Boell wrote:

> ...
> >>> Programming uCs in assembly is hard, error-prone, and the code will not
> >>> be easy to maintain. If anyone says they would rather program uCs in C,
> >>> they certainly have a point.
> >>
> >> That's a very reasonable decision to make, but there's a corresponding
> >> price you'll pay for the convenience of having the compiler generate
> >> assembly for you: you lose control of details such as the ones Francois
> >> was worried about.

> >
> > Not necessarily, which I think was kind of his point...

>
> If so, his point was wrong. C provides no way to specify such details. C
> source code which you might imagine specifies generation of one
> particular sequence of assembly language instructions on a given
> platform does nothing of the sort. A conforming compiler for that
> platform can translate that code into any other sequence that produces
> the same result.


uC code is not really portable anyway. You use a specific compiler and
toolchain, so it's valid to optimize for that particular toolchain.

Besides, it's reasonable to assume that code which specifies to create
a variable will create a variable more often than code which specifies
not creating one. Optimizing the variable away might not be possible
at all. Also, relying on the compiler to always generate optimal code
regardless of what you throw at it is just wishful thinking.



 
Reply With Quote
 
 
 
 
Ali
Guest
Posts: n/a
 
      07-29-2011
On Jul 29, 9:23*pm, James Kuyper <(E-Mail Removed)> wrote:
> On 07/29/2011 08:38 AM, Thomas Boell wrote:
>
>
>
>
>
>
>
>
>
> > On Fri, 22 Jul 2011 08:14:44 -0700 (PDT)
> > "Kleuskes & Moos" <(E-Mail Removed)> wrote:

>
> >> On Jul 22, 4:11 pm, Francois Grieu <(E-Mail Removed)> wrote:
> >> [..]
> >>> If I rationalize: on low-end platforms (PIC..) that I often use, RAM
> >>> size is a few hundred bytes and program space a few kbytes, so every
> >>> byte counts. Even on relatively powerful CPUs (Arm, x86) and when memory
> >>> is not an issue, using one more register may force the shift of
> >>> something into memory rather than in a register, or/and a little extra
> >>> code could abruptly reduce cache efficiency, and in turn slow down
> >>> things considerably. I bet I could construct an articial demo where the
> >>> suggested change increases execution time/power draw quite perceptibly,
> >>> say by 30%.

>
> >>> * *Francois Grieu

>
> >> If such finegrained control is needed, wouldn't you be better off
> >> using assembly? Most uC targeted compilers i know of mix the two quite
> >> well.

>
> >> From what i read portability isn't a great concern, since you're quite
> >> specific on the platform, so that can't be the issue.

>
> > Have you ever used assembly on a microcontroller? Many of the
> > widely-used Atmel uCs, for example, don't have a multiply instruction.
> > They cannot do calculations on any integers larger than 8 bits
> > directly. There is no "add immediate" instruction either; you have to
> > negate the value and use "subtract immediate" instead. Letting the
> > compiler handle things like 16-bit multiplication certainly makes
> > things a lot easier.

>
> > Programming uCs in assembly is hard, error-prone, and the code will not
> > be easy to maintain. If anyone says they would rather program uCs in C,
> > they certainly have a point.

>
> That's a very reasonable decision to make, but there's a corresponding
> price you'll pay for the convenience of having the compiler generate
> assembly for you: you lose control of details such as the ones Francois
> was worried about.
> --
> James Kuyper


And we have a nice old thing to talk. Goto Vs. Function return calls.

I will go for "goto".

regards,
ali
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      07-30-2011
On 07/29/2011 10:56 AM, Willem wrote:
> James Kuyper wrote:
> ) If so, his point was wrong. C provides no way to specify such details. C
> ) source code which you might imagine specifies generation of one
> ) particular sequence of assembly language instructions on a given
> ) platform does nothing of the sort. A conforming compiler for that
> ) platform can translate that code into any other sequence that produces
> ) the same result.
>
> Technically/pedantically, yes. Practically, given a known compiler,
> you can most certainly influence the output by the choice of C code.
> The case in point is if the compiler would use a variable or not for
> a certain construct, and that seems entirely plausible.


Yes, by knowing enough about a given compiler, you can do that. However,
in order to be certain, you really need to disassemble and understand
the generated assembly language, to make sure it's generating the code
that you want. If you change compilers, or even if you merely update the
compiler, you'll have to check all over again, because something
relevant might be different. If you know what you want in sufficient
detail to second-guess the compiler, it's much simpler to just write the
code you want yourself.
--
James Kuyper

 
Reply With Quote
 
Willem
Guest
Posts: n/a
 
      07-30-2011
James Kuyper wrote:
) Yes, by knowing enough about a given compiler, you can do that. However,
) in order to be certain, you really need to disassemble and understand
) the generated assembly language, to make sure it's generating the code
) that you want. If you change compilers, or even if you merely update the
) compiler, you'll have to check all over again, because something
) relevant might be different.

Not in all cases. Looks like you're using reductio ad absurdam.
It al depends on how fine the requirements are. Some things are
really easy to spot in a disassembly output, such as register use,
flow control statements, stuff like that.

Also, 'disassemble the generated assembly language' is an absurd statement.
You generate machine code by assembling assembly language, and when you
disassemble machine code, you get assembly language.

Note that most compilers generate assembly language, not machine code
directly, so examining the generated assembly is quite easy.

) If you know what you want in sufficient
) detail to second-guess the compiler, it's much simpler to just write the
) code you want yourself.

All the OP wanted was to avoid the use of extra variables tying up
registers or memory slots. That's a pretty coarse requirement which
can certainly be influenced by changing the code, will work on a range
of compilers, and is very easily checked by a once-over of the assembly
output, whereas writing everything yourself would be very much harder.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      07-30-2011
On 07/30/2011 05:12 AM, Willem wrote:
....
> Also, 'disassemble the generated assembly language' is an absurd statement.


It's an editing error; the original statement was about disassembling
the program, then I incompletely corrected it to refer directly to the
generated assembly language, forgetting to remove the word disassemble.
--
James Kuyper
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments