Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #150513 > unrolled thread

How to div only once to get remainder and quotient?

Back to article view | Back to comp.lang.c

Contents

  How to div only once to get remainder and quotient? Francis Assissi <invalid@invalid.invalid> - 2020-03-12 20:18 +0000
    Re: How to div only once to get remainder and quotient? Bart <bc@freeuk.com> - 2020-03-12 20:26 +0000
      Re: How to div only once to get remainder and quotient? Francis Assissi <invalid@invalid.invalid> - 2020-03-12 20:30 +0000
        Re: How to div only once to get remainder and quotient? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-03-12 20:40 -0700
      Re: How to div only once to get remainder and quotient? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-03-12 16:38 -0400
        Re: How to div only once to get remainder and quotient? richard@cogsci.ed.ac.uk (Richard Tobin) - 2020-03-12 20:44 +0000
          Re: How to div only once to get remainder and quotient? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-03-12 17:00 -0400
            Re: How to div only once to get remainder and quotient? richard@cogsci.ed.ac.uk (Richard Tobin) - 2020-03-13 09:35 +0000
              Re: How to div only once to get remainder and quotient? David Brown <david.brown@hesbynett.no> - 2020-03-13 11:12 +0100
        Re: How to div only once to get remainder and quotient? scott@slp53.sl.home (Scott Lurndal) - 2020-03-12 22:16 +0000
          Re: How to div only once to get remainder and quotient? Francis Assissi <invalid@invalid.invalid> - 2020-03-12 22:39 +0000
            Re: How to div only once to get remainder and quotient? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-03-12 19:51 -0400
              Re: How to div only once to get remainder and quotient? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-13 00:47 +0000
                Re: How to div only once to get remainder and quotient? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-03-12 23:02 -0400
                Re: How to div only once to get remainder and quotient? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-03-12 20:39 -0700
              Re: How to div only once to get remainder and quotient? scott@slp53.sl.home (Scott Lurndal) - 2020-03-13 15:00 +0000
              Re: How to div only once to get remainder and quotient? Spiros Bousbouras <spibou@gmail.com> - 2020-03-14 08:35 +0000
    Re: How to div only once to get remainder and quotient? jak <nospam@please.ty> - 2020-03-12 21:55 +0100
      Re: How to div only once to get remainder and quotient? Francis Assissi <invalid@invalid.invalid> - 2020-03-12 21:56 +0000
        Re: How to div only once to get remainder and quotient? jak <nospam@please.ty> - 2020-03-12 23:26 +0100
    Re: How to div only once to get remainder and quotient? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-12 21:11 +0000
      Re: How to div only once to get remainder and quotient? Francis Assissi <invalid@invalid.invalid> - 2020-03-12 21:57 +0000
      Re: How to div only once to get remainder and quotient? Bart <bc@freeuk.com> - 2020-03-12 22:23 +0000
        Re: How to div only once to get remainder and quotient? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-13 01:05 +0000
    Re: How to div only once to get remainder and quotient? David Brown <david.brown@hesbynett.no> - 2020-03-13 11:33 +0100
      Re: How to div only once to get remainder and quotient? Bart <bc@freeuk.com> - 2020-03-13 11:03 +0000
        Re: How to div only once to get remainder and quotient? David Brown <david.brown@hesbynett.no> - 2020-03-13 14:31 +0100
          Re: How to div only once to get remainder and quotient? Bart <bc@freeuk.com> - 2020-03-13 15:12 +0000
            Re: How to div only once to get remainder and quotient? David Brown <david.brown@hesbynett.no> - 2020-03-13 18:03 +0100
              Re: How to div only once to get remainder and quotient? Bart <bc@freeuk.com> - 2020-03-13 18:01 +0000
                Re: How to div only once to get remainder and quotient? David Brown <david.brown@hesbynett.no> - 2020-03-13 19:06 +0100
                  Re: How to div only once to get remainder and quotient? Bart <bc@freeuk.com> - 2020-03-13 19:12 +0000
        Re: How to div only once to get remainder and quotient? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-13 13:34 +0000
          Re: How to div only once to get remainder and quotient? Bart <bc@freeuk.com> - 2020-03-13 15:00 +0000
            Re: How to div only once to get remainder and quotient? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-13 20:34 +0000
              Re: How to div only once to get remainder and quotient? Bart <bc@freeuk.com> - 2020-03-13 21:41 +0000
                Re: How to div only once to get remainder and quotient? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-14 01:47 +0000
                  Re: How to div only once to get remainder and quotient? Bart <bc@freeuk.com> - 2020-03-14 12:24 +0000
                    Re: How to div only once to get remainder and quotient? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-14 16:35 +0000
                      Re: How to div only once to get remainder and quotient? Bart <bc@freeuk.com> - 2020-03-14 18:05 +0000
    Re: How to div only once to get remainder and quotient? already5chosen@yahoo.com - 2020-03-13 03:52 -0700
    Re: How to div only once to get remainder and quotient? Guillaume <message@bottle.org> - 2020-03-13 16:41 +0100
      Re: How to div only once to get remainder and quotient? Francis Assissi <invalid@invalid.invalid> - 2020-03-13 16:07 +0000
        Re: How to div only once to get remainder and quotient? David Brown <david.brown@hesbynett.no> - 2020-03-13 18:10 +0100
          Re: How to div only once to get remainder and quotient? Francis Assissi <invalid@invalid.invalid> - 2020-03-13 19:32 +0000
            Re: How to div only once to get remainder and quotient? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-13 16:08 -0400
              Re: How to div only once to get remainder and quotient? Francis Assissi <invalid@invalid.invalid> - 2020-03-13 20:50 +0000
                Re: How to div only once to get remainder and quotient? jameskuyper@stellarscience.com - 2020-03-13 16:05 -0700
                  Re: How to div only once to get remainder and quotient? Francis Assissi <invalid@invalid.invalid> - 2020-03-13 23:42 +0000
                    Re: How to div only once to get remainder and quotient? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-13 19:59 -0400
                      Re: How to div only once to get remainder and quotient? Francis Assissi <invalid@invalid.invalid> - 2020-03-14 00:07 +0000
                        Re: How to div only once to get remainder and quotient? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-13 20:27 -0400
                          Re: How to div only once to get remainder and quotient? Francis Assissi <invalid@invalid.invalid> - 2020-03-14 01:37 +0000
                      Re: How to div only once to get remainder and quotient? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 07:45 -0700
                        Re: How to div only once to get remainder and quotient? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-02 08:09 -0700
                        Re: How to div only once to get remainder and quotient? gazelle@shell.xmission.com (Kenny McCormack) - 2020-04-02 16:03 +0000
                          Re: How to div only once to get remainder and quotient? Öö Tiib <ootiib@hot.ee> - 2020-04-04 04:31 -0700
                            Invitations (Was: How to div only once to get remainder and quotient?) gazelle@shell.xmission.com (Kenny McCormack) - 2020-04-04 17:04 +0000
                              Re: Invitations (Was: How to div only once to get remainder and quotient?) Öö Tiib <ootiib@hot.ee> - 2020-04-07 00:10 -0700
        Re: How to div only once to get remainder and quotient? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-13 14:30 -0400
          Re: How to div only once to get remainder and quotient? Francis Assissi <invalid@invalid.invalid> - 2020-03-13 20:54 +0000
            Re: How to div only once to get remainder and quotient? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-13 23:10 +0000
            Re: How to div only once to get remainder and quotient? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-13 20:18 -0400
              Re: How to div only once to get remainder and quotient? Francis Assissi <invalid@invalid.invalid> - 2020-03-14 00:34 +0000
                Re: How to div only once to get remainder and quotient? Francis Assissi <invalid@invalid.invalid> - 2020-03-14 01:47 +0000
    Re: How to div only once to get remainder and quotient? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-03-13 14:39 -0600
      Re: How to div only once to get remainder and quotient? felix@palmen-it.de (Felix Palmen) - 2020-03-13 22:10 +0100
        Re: How to div only once to get remainder and quotient? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-03-13 16:26 -0600
        Re: How to div only once to get remainder and quotient? David Brown <david.brown@hesbynett.no> - 2020-03-14 16:41 +0100
          Re: How to div only once to get remainder and quotient? felix@palmen-it.de (Felix Palmen) - 2020-03-14 17:00 +0100
            Re: How to div only once to get remainder and quotient? David Brown <david.brown@hesbynett.no> - 2020-03-15 13:39 +0100
      Re: How to div only once to get remainder and quotient? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-13 23:07 +0000
        Re: How to div only once to get remainder and quotient? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-03-14 12:13 -0600
    Re: How to div only once to get remainder and quotient? Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-07 09:35 +0200

Page 4 of 4 — ← Prev page 1 2 3 [4]

#150563

> Why do you find it disappointing?
The issue falls down to readability, and I fail to see any benefit 
between:
*ptr = '0' + number % 2;
number /= 2;
and
result = div(number, 2);
*ptr = '0' + result.rem;
number /= 2;

[toc] | [prev] | [next] | [standalone]

#150570

Francis Assissi <invalid@invalid.invalid> writes:

>> Why do you find it disappointing?
> The issue falls down to readability, and I fail to see any benefit 
> between:
> *ptr = '0' + number % 2;
> number /= 2;
> and
> result = div(number, 2);
> *ptr = '0' + result.rem;
> number /= 2;

In general, you'd only use div if you want to use both parts:

 number = result.quot;

but as I originally said, you don't really want to use it.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#150574

On 3/13/20 4:54 PM, Francis Assissi wrote:
>> Why do you find it disappointing?
> The issue falls down to readability, and I fail to see any benefit 
> between:
> *ptr = '0' + number % 2;
> number /= 2;
> and
> result = div(number, 2);
> *ptr = '0' + result.rem;
> number /= 2;

You were talking, or so I thought, about the implementation of div(),
not the use of it. When you wrote:

On 3/13/20 12:07 PM, Francis Assissi wrote:
...
> The fact that implementations does
> exactly what I did for div() is disappointing.

I assumed that "what I did" was a reference to

On 3/12/20 4:18 PM, Francis Assissi wrote:
...
>                 *ptr = '0' + number % 2;
>                 number /= 2;

and that the implementation you were referring to was:

On 3/12/20 4:38 PM, Lew Pitcher wrote:
...
> For instance, this is div(), from one implementation of the standard
> library...
>
>   #include <stdlib.h>
>   /* Return the `div_t' representation of NUMER over DENOM.  */
>   div_t
>   div (int numer, int denom)
>   {
>     div_t result;
>     result.quot = numer / denom;
>     result.rem = numer % denom;
>     return result;
>   }

Now, your original code would almost certainly be optimized to use a
hardware instruction that returns both a quotient and a remainder, on
any platform which has such an instruction. The same is likely to be
true of div(), if it is defined using such code. Finally, since the
behavior of div() is defined precisely by the C standard, a conforming
implementation of C is free to inline it rather than calling the library
function. As a result, if you were to unnecessarily complicate your code
by writing

  div_t result = div(number, 2);
  *ptr = '0' + result.rem;
  number = result.quot;

then there's a pretty good chance that a decently optimizing compiler
will inline the call to div() and optimize it that same way.

[toc] | [prev] | [next] | [standalone]

#150576

You can try the programs below with gcc -S -O3, both results in the same 
assembly code, the compiler does everything, it really comes down to 
readability.

int main(void)
{
        int number = 123456789;
        int result;

        result = number % 10;
        result = number / 10;
        return 0;
}


#include <stdlib.h>

int main(void)
{
        int number = 123456789;
        div_t result;

        result = div(number, 10);
        return 0;
}

[toc] | [prev] | [next] | [standalone]

#150579

Pardon the formatting, copying from the terminal and pasting to Pan is a 
bad idea.

[toc] | [prev] | [next] | [standalone]

#150561

Francis Assissi <invalid@invalid.invalid> writes:
>         while(number > 0 && ptr > bin_string) {
>                 *ptr = '0' + number % 2;
>                 number /= 2;

Note that those divisions are a special case for which you could use
*ptr = '0' + number & 1;
number >>= 1;

Though
(1) today's architectures are so optimized there's every chance doing
the division would be just as fast as doing the bit operations

(2) if the bit operations are actually faster, there's every chance the
compiler would optimize away the divisions anyway.

[toc] | [prev] | [next] | [standalone]

#150564

* Joe Pfeiffer <pfeiffer@cs.nmsu.edu>:
> Francis Assissi <invalid@invalid.invalid> writes:
>>         while(number > 0 && ptr > bin_string) {
>>                 *ptr = '0' + number % 2;
>>                 number /= 2;
> 
> Note that those divisions are a special case for which you could use
> *ptr = '0' + number & 1;
> number >>= 1;

I'd actually *prefer* to write the code that way. People talk about
clarity and readable code, and that's indeed important. But when then
task is a string representation of binary, looking at each bit while
shifting is a much more obvious thing in my mind than dividing and
modulo.

And then:

> (1) today's architectures are so optimized there's every chance doing
> the division would be just as fast as doing the bit operations

That's correct most of the time -- but C compilers exist even for a 6502
CPU, which doesn't even have an instruction for division :)

> (2) if the bit operations are actually faster, there's every chance the
> compiler would optimize away the divisions anyway.

I'd assume so, indeed. But maybe some compilers targeting more "exotic"
platforms aren't as intelligent as those mainstream compilers we're used
to nowadays. Anyways, a compiler generating *worse* code when written
with bitshifts over divisions would be severely (intentionally?) broken.

-- 
 Dipl.-Inform. Felix Palmen  <felix@palmen-it.de>   ,.//..........
 {web}  http://palmen-it.de  {jabber} [see email]   ,//palmen-it.de
 {pgp public key}     http://palmen-it.de/pub.txt   //   """""""""""
 {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A

[toc] | [prev] | [next] | [standalone]

#150567

felix@palmen-it.de (Felix Palmen) writes:

> * Joe Pfeiffer <pfeiffer@cs.nmsu.edu>:
>> Francis Assissi <invalid@invalid.invalid> writes:
>>>         while(number > 0 && ptr > bin_string) {
>>>                 *ptr = '0' + number % 2;
>>>                 number /= 2;
>> 
>> Note that those divisions are a special case for which you could use
>> *ptr = '0' + number & 1;
>> number >>= 1;
>
> I'd actually *prefer* to write the code that way. People talk about
> clarity and readable code, and that's indeed important. But when then
> task is a string representation of binary, looking at each bit while
> shifting is a much more obvious thing in my mind than dividing and
> modulo.

Funny, when I wrote my response I was thinking in terms of the original
code and this being an optimization.  But if I had been writing it from
scratch this is probably the way I would have done it, for exactly the
reasons you state.

> And then:
>
>> (1) today's architectures are so optimized there's every chance doing
>> the division would be just as fast as doing the bit operations
>
> That's correct most of the time -- but C compilers exist even for a 6502
> CPU, which doesn't even have an instruction for division :)
>
>> (2) if the bit operations are actually faster, there's every chance the
>> compiler would optimize away the divisions anyway.
>
> I'd assume so, indeed. But maybe some compilers targeting more "exotic"
> platforms aren't as intelligent as those mainstream compilers we're used
> to nowadays. Anyways, a compiler generating *worse* code when written
> with bitshifts over divisions would be severely (intentionally?) broken.

Indeed.

[toc] | [prev] | [next] | [standalone]

#150583

On 13/03/2020 22:10, Felix Palmen wrote:
> * Joe Pfeiffer <pfeiffer@cs.nmsu.edu>:
>> Francis Assissi <invalid@invalid.invalid> writes:
>>>          while(number > 0 && ptr > bin_string) {
>>>                  *ptr = '0' + number % 2;
>>>                  number /= 2;
>>
>> Note that those divisions are a special case for which you could use
>> *ptr = '0' + number & 1;
>> number >>= 1;
> 
> I'd actually *prefer* to write the code that way. People talk about
> clarity and readable code, and that's indeed important. But when then
> task is a string representation of binary, looking at each bit while
> shifting is a much more obvious thing in my mind than dividing and
> modulo.

Readability is in the eye of the beholder, but given that you have been 
talking about different bases, it would be strange to write a special 
and different version just for base 2.

> 
> And then:
> 
>> (1) today's architectures are so optimized there's every chance doing
>> the division would be just as fast as doing the bit operations
> 

General divisions are not nearly as fast as bit operations.  They 
typically take several cycles, are often are not (fully) pipelined, and 
generally have fewer choices of execution unit for superscaler 
operation.  Multiplication is usually as fast as bit operations.  So 
good compilers, when faced with integer division by a constant, 
typically generate code involving multiplications and bit-shifts.

> That's correct most of the time -- but C compilers exist even for a 6502
> CPU, which doesn't even have an instruction for division :)

Even 6502 compilers will generally turn divide by 2 into a shift.

Generally, you know if your code is going to be run on such small 
processors - and it is only then that it makes sense to write it in a 
manner that works efficiently on such systems.  (It can be good to make 
your code portable across a wide range of targets, but don't try to 
optimise it for unrealistic targets.)

> 
>> (2) if the bit operations are actually faster, there's every chance the
>> compiler would optimize away the divisions anyway.
> 
> I'd assume so, indeed. But maybe some compilers targeting more "exotic"
> platforms aren't as intelligent as those mainstream compilers we're used
> to nowadays. Anyways, a compiler generating *worse* code when written
> with bitshifts over divisions would be severely (intentionally?) broken.
> 

Compilers for "exotic" platforms sometimes have more sophisticated 
optimisations than mainstream compilers (in particular, it's a lot 
easier to do extensive "whole program" optimisations when the whole 
program is limited to a few KB of space).  And sometimes they are much 
more limited.  But optimising division by 2 is going to be common on 
most choices.

On the other hand, I can imagine a compiler handling division better 
than bit operations (though not in this particular case).  Some 
compilers are quite good at re-arranging arithmetic operations, 
evaluating them at compile time, and establishing information about the 
results.  Bit operations can often be harder to handle (though in this 
case, they would be simple).  A general rule for getting good results 
from an optimising compiler is to write the code in the simplest, 
clearest and most obvious way and let the compiler handle the low-level 
optimisations.

[toc] | [prev] | [next] | [standalone]

#150584

* David Brown <david.brown@hesbynett.no>:
> On 13/03/2020 22:10, Felix Palmen wrote:
>> * Joe Pfeiffer <pfeiffer@cs.nmsu.edu>:
>>> *ptr = '0' + number & 1;
>>> number >>= 1;
>> 
>> I'd actually *prefer* to write the code that way. People talk about
>> clarity and readable code, and that's indeed important. But when then
>> task is a string representation of binary, looking at each bit while
>> shifting is a much more obvious thing in my mind than dividing and
>> modulo.
> 
> Readability is in the eye of the beholder, but given that you have been 
> talking about different bases, [...]

No, I only talked about binary ...

> it would be strange to write a special 
> and different version just for base 2.

Base 2 *is* a special case because that's how computers work. Sure, it
depends on your personal background which version you find more
readable. But I bet anyone knowing a bit about hardware and logic
circuitry will prefer the notion of examining each bit for display.

> Even 6502 compilers will generally turn divide by 2 into a shift.

Probably. I know one compiler targeting the 6502 that still couldn't
automatically turn all 'i++' into '++i' where possible a few years ago,
so I wouldn't be entirely sure about that either.

> Generally, you know if your code is going to be run on such small 
> processors - and it is only then that it makes sense to write it in a 
> manner that works efficiently on such systems.

No objections here. Just stating there *are* still reasons for manual
optimization sometimes.

>                               A general rule for getting good results 
> from an optimising compiler is to write the code in the simplest, 
> clearest and most obvious way and let the compiler handle the low-level 
> optimisations.

That's a good approach most of the time. But as shown above, the *most
obvious way* can have a subjective touch.

-- 
 Dipl.-Inform. Felix Palmen  <felix@palmen-it.de>   ,.//..........
 {web}  http://palmen-it.de  {jabber} [see email]   ,//palmen-it.de
 {pgp public key}     http://palmen-it.de/pub.txt   //   """""""""""
 {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A

[toc] | [prev] | [next] | [standalone]

#150590

On 14/03/2020 17:00, Felix Palmen wrote:
> * David Brown <david.brown@hesbynett.no>:
>> On 13/03/2020 22:10, Felix Palmen wrote:
>>> * Joe Pfeiffer <pfeiffer@cs.nmsu.edu>:
>>>> *ptr = '0' + number & 1;
>>>> number >>= 1;
>>>
>>> I'd actually *prefer* to write the code that way. People talk about
>>> clarity and readable code, and that's indeed important. But when then
>>> task is a string representation of binary, looking at each bit while
>>> shifting is a much more obvious thing in my mind than dividing and
>>> modulo.
>>
>> Readability is in the eye of the beholder, but given that you have been
>> talking about different bases, [...]
> 
> No, I only talked about binary ...

Sorry, the OP and others have talked about different bases.  I guess I 
assumed you were too.

> 
>> it would be strange to write a special
>> and different version just for base 2.
> 
> Base 2 *is* a special case because that's how computers work. Sure, it
> depends on your personal background which version you find more
> readable. But I bet anyone knowing a bit about hardware and logic
> circuitry will prefer the notion of examining each bit for display.

If you are only talking about binary, then "2" is not a special case - 
it is your /only/ case.  But it is correct that you could write things 
in different ways than you would with other bases.

> 
>> Even 6502 compilers will generally turn divide by 2 into a shift.
> 
> Probably. I know one compiler targeting the 6502 that still couldn't
> automatically turn all 'i++' into '++i' where possible a few years ago,
> so I wouldn't be entirely sure about that either.
> 

I know of a lot of small accumulator-based 8-bit cpus in current use. 
The 6502 is not one of them - I am surprised to hear of anyone compiling 
anything for a 6502 this side of the millennium, unless it is just for 
fun.  (8051, PIC, COP8, and a number of other small cpus are much more 
common.)

>> Generally, you know if your code is going to be run on such small
>> processors - and it is only then that it makes sense to write it in a
>> manner that works efficiently on such systems.
> 
> No objections here. Just stating there *are* still reasons for manual
> optimization sometimes.

There are no reasons for using a 6502, other than for fun.  There are 
reasons for using other small devices, and sometimes there you need to 
use poorly optimising compilers (though usually they are not too bad). 
But coding for systems where the choice of "x >>= 1" or "x /= 2" makes a 
difference to the assembly, and the speed of the assembly is 
significant, is a very niche area.  I see a more cases of "cool tricks" 
code that leads to less efficient results or directly incorrect code, 
than helpful results.  And I work with small microcontrollers.

So yes, there are cases where manual micro-optimisation is important - 
but they are increasingly rare.

(If you think the changes make the code clearer, that's a different 
matter entirely.)

> 
>>                                A general rule for getting good results
>> from an optimising compiler is to write the code in the simplest,
>> clearest and most obvious way and let the compiler handle the low-level
>> optimisations.
> 
> That's a good approach most of the time. But as shown above, the *most
> obvious way* can have a subjective touch.
> 

[toc] | [prev] | [next] | [standalone]

#150569

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:

> Francis Assissi <invalid@invalid.invalid> writes:
>>         while(number > 0 && ptr > bin_string) {
>>                 *ptr = '0' + number % 2;
>>                 number /= 2;
>
> Note that those divisions are a special case for which you could use
> *ptr = '0' + number & 1;

  *ptr = '0' + (number & 1);

& has a lower precedence that one might expect because it used to be
used as the logical 'and' before early C got && for that specific
purpose.

<cut>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#150587

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>
>> Francis Assissi <invalid@invalid.invalid> writes:
>>>         while(number > 0 && ptr > bin_string) {
>>>                 *ptr = '0' + number % 2;
>>>                 number /= 2;
>>
>> Note that those divisions are a special case for which you could use
>> *ptr = '0' + number & 1;
>
>   *ptr = '0' + (number & 1);
>
> & has a lower precedence that one might expect because it used to be
> used as the logical 'and' before early C got && for that specific
> purpose.

Ouch!  You are correct, of course.

[toc] | [prev] | [next] | [standalone]

#151175

The compiler will do it for you !

void f( unsigned dividend, unsigned divisor, unsigned *quotient, 
unsigned *remainder )
{
     *quotient  = dividend / divisor;
     *remainder = dividend % divisor;
}

MSVC:

     mov    r10d, edx
     mov    eax, ecx
     xor    edx, edx
     div    r10d
     mov    DWORD PTR [r8], eax
     mov    DWORD PTR [r9], edx
     ret

gcc:

     movl   %edi, %eax
     movq   %rdx, %rdi
     xorl   %edx, %edx
     divl   %esi
     movl   %eax, (%rdi)
     movl   %edx, (%rcx)
     ret

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

Back to top | Article view | comp.lang.c

csiph-web