delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/05/17/16:45:41

From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Right shift
Date: 17 May 2000 18:54:38 GMT
Organization: Aachen University of Technology (RWTH)
Lines: 53
Message-ID: <8fupte$pfv$1@nets3.rz.RWTH-Aachen.DE>
References: <3922AD5F DOT EB45FD4D AT tiscalinet DOT it>
NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de
X-Trace: nets3.rz.RWTH-Aachen.DE 958589678 26111 137.226.32.75 (17 May 2000 18:54:38 GMT)
X-Complaints-To: abuse AT rwth-aachen DOT de
NNTP-Posting-Date: 17 May 2000 18:54:38 GMT
Originator: broeker@
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

>>Wrong question, sort of.
> No. I wanted just to understand how does >> really works, so i used a
> simple number.

It's not the particular number you used. The thing is that there is is
not really any way 'how >> really works'. There are lots of them, and
it may depend on influences you never though about which of them will
be used by your compiler next time you compile the same source file.

>>It's better for your programming skills if you do not know how this is
>>implemented, so you don't make any silent assumption that will break
>>if your program ever gets moved to another compiler, operating system
>>or machine.

> My prog works perfectly, but, as i do not make any silent assumpion, i
> was wondering how the da mn thing works, so i made a little test prog...

If at all, you should have been looking at the assembly code generated by
the compiler, not at the final output.

Your particular application may benefit from using shifts instead of
divides, but gcc is quite a clever optimizing compiler, so you should
ask yourself: "Why didn't it do the same optimization?" Chances are it
didn't because the optimization will break your program, as far as gcc
can deduce from what your code says. Telling gcc more precisely what
you want, like using unsigned variables, instead of signed ones, here,
might have yielded the same speed increase, without breaking the
cleanness of the program.

> About my prog skill: if i must improve (and i must) let me learn.

You misunderstood my mention of programming skills, I think. I didn't
imply yours has to improve. What I wanted to point out was that
knowing this particular detail will not improve your programming skill
at all. It'll leave it unchanged, or even deteriorate it.

>>Ignorance can protect you, sometimes.
> I prefer knowledge (do you like aphorisms?)

There is no fact to know, there. If you memorize a particular
implementation's behaviour, that 'knowledge' will become 100% useless
as soon as your compiler, or your CPU architecture, or any of a number
of possible other influences changes. Such information is not
'knowledge', it's useless trivia, in almost all applications. Learning
such knowledge usually leads to silent, unconscious assumptions based
on it, later, which wreak havoc on your programs, instead of improving
them.



-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019