• Mikademus (unregistered) in reply to Manni

    That is called "the hacker mentality". Few hackers are good pedagogues.

  • Mikademus (unregistered) in reply to Mikademus

    That was in reply to Manni's

    Sweets I appreciate you taking the time to try to explain exactly what the various pieces are doing. Everyone else was too busy trying to figure out how to reduce the operation to a flawless solution considering buffering bits or whatever, and so that it takes less than 2 microseconds.
  • Zatanix (unregistered)
    Alex Papadimoulis:

    <font color="#000099">#define</font> GENBIT(x) 1<<x color="#000099"><font>#define</font> NUMBITS 32

    <font color="#009900">// ED: Snip ...</font>

    <font color="#000099">unsigned int</font> resetBits(<font color="#000099">unsigned int</font> bitfield)
    {
      <font color="#000099">int</font> index=0;
      <font color="#000099">for</font>(index=0;index<numbits ;index="" color="#000099"><font {="">unsigned int</font> flag;
          flag = GENBIT(index);
          flag = ~flag;
          bitfield = bitfield & flag;
      }
      <font color="#000099">return</font> bitfield;
    }</numbits></x>


    this code won't compile...

  • (cs) in reply to Zatanix

    It's the '<' symbols that are making the code not display correctly. "1<<x" and "index < NUMBITS".

  • (cs) in reply to spotcatbug

    Those "<" were meant to be '<'s. I don't think I've ever managed to post correctly on this forum.

  • (cs) in reply to spotcatbug

    OMG! It worked!

  • (cs)

    Now I see what you guys are starting to complain about this terrible forums software! I edited the post to change the submitters' real name to a psedeonym. And that threw off all the formatting !#$&*!!!

    But hey, uhh ... its got a good architecture ....

  • (cs) in reply to Ifeanyi Echeruo
    Anonymous:

    But we can all agree that

    unsigned long int i = 0;

    will be 32 bits worth of zeros;



    Nonsense; haven't you ever heard of 64bit computers? It's not 32 bits here :)
  • Adam (unregistered)

    In Assembly just put the int into a register (eax as an example):
    xorl  %eax, %eax
    ret

  • (cs)

    How about flipping the on/off switch? That would be fast!

  • Zatanix (unregistered) in reply to nonDev
    nonDev:
    How about flipping the on/off switch? That would be fast!

    Good idea!

    I don't know about PC's but atleast when you do that on a C64, only about half of the memory will be filled with 0x00.. the rest will be filled with 0xFF.
    (so there'll be something like 0x40 bytes of 0x00's followed by 0x40 bytes of 0xFF's, then 0x40 bytes of 0x00's again... etc etc (if i remember correctly))

    But if you can live with this (or if PC's are different) then you've found a constant-time way of doing it even for n bytes! Cool! :)
    Hardware-acceleration at it's best!

    <font style="color: rgb(128, 128, 128);" size="1">PS. i really do hate the C way of starting hex-numbers with "0x".. but i just did it so you'ld know what i meant..</font>
  • cokes (unregistered) in reply to Zatanix

    On late x86-platforms with paralell-execution, xor is not the recommended way to clear something - mov eax, 0 is, though more complex, quicker.

    Pushing them through a nand-gate should do the trick. :D

  • David (unregistered)

    As somebody pointed out, this will not compile.

    <font>#define</font> GENBIT(x) 1<<X // should be lowercase x
    <font>#define</font> NUMBITS 32

    <font>// ED: Snip ...</font>

    <font>unsigned int</font> resetBits(<font>unsigned int</font> bitfield)
    {
      <font>int</font> index=0;
      <font>for</font>(index=0;index<NUMBITS;INDEX++) // again, lowercase index
      {   <font>unsigned int</font> flag;
          flag = GENBIT(index);
          flag = ~flag;
          bitfield = bitfield & flag;
      }
      <font>return</font> bitfield;
    }
    Alex you re-typed it??

  • (cs)

    aside from the various suggestions here, there is ALWAYS the delphi version, gets the all the bits regardless of the size of the mask :

    FillChar(Flag,SizeOf(Flag),#0);

    Destination, Size, byte pattern. Obviously, not very efficent for 32 bits or smaller, but since the dest is passed as typeless pointer, and the compiler worries about the data size, the code is safe, 100% efficent and totally safe, and since the COMPILER knows the size of the structure (delphi being a typed language and all), even though the function doesn't do range checking, it is still safe.

    I still prefer the old XOR EAX,EAX -> Confusing and obscure, but damn efficent since Intel decided to optimize specifically that opcode for zeroing.

    Of course, if you have a REALLY big data structure to move, you could always do something like :

    Push ES
    Push DS
    Pop ES
    LEA EAX,[flag]
    Mov ESI,EAX
    Inc EAX
    Mov EDi,EAX
    Mov ECX,[Count]
    Mov [byte ptr EDI],0
    REP MOVSB
    Pop ES
     
    true, not as sexy as xor ax,ax, but REP MOVSB can get hardware accerlation flowing.  Forgive any rustyness in my x86, its almost been a LONG time (long enough that I can remember accelerating computers by reducing the ram refresh rate)

  • bp (unregistered) in reply to Brian
    Anonymous:

    Remember:

    int i=0 DOES NOT guarantee that all bits will be 0.

    If this is "C", see:  http://groups-beta.google.com/group/comp.lang.c/msg/fed3e094bd617097?dmode=source&hl=en

    It discusses the two situtations in which 0 is NOT all bits 0



    There is nothing funky going on here, its a simple unsigned int parameter, so setting it to zero will  set all its bits to zero.
  • Dave (unregistered)

    dear God.  To program should require a license.

  • (cs) in reply to Alex Papadimoulis
    Alex Papadimoulis:

    Now I see what you guys are starting to complain about this terrible forums software! I edited the post to change the submitters' real name to a psedeonym. And that threw off all the formatting !#$&*!!!

    But hey, uhh ... its got a good architecture ....



    Hah! It blew up on Alex's face. Let's see if he changes it. [:p]
  • CT (unregistered)

    I presume this wont compile because INDEX is not declared. If it did compile because it was declared somewhere, it is going to loop forever 'cos index is not getting incremented.

    Crazy coding or wot. Just delete the routine, unless you are having to clear a hardware register in which case just setting to zero may not work since when I used to do assembler, clr instructions would do a read-modify-write.

  • diaphanein (unregistered) in reply to Gary

    Anonymous:
    Wait a minute, there. I can certainly agree that if you are restricted to working at the gate level, XOR would be slower, but if you are working directly in, say, CMOS, could you not have something with cross-wired P vs. N gates?  (I know that's not very clear, but I can't draw a picture here.  I mean can you make an XOR directly in transistors that is smaller, simpler, and faster than if you did it using AND/OR primitives?)

    There are faster implementations using dynamic logic than using the boolean primitives.  However, they're still slower than A & ~A.  Especially if you're using dynamic logic, you typically already have the A and ~A signals available to you at no cost.  Of course, you'd prolly want to use inverted logic, as well.

  • (cs) in reply to Brian
    Anonymous:

    Remember:

    int i=0 DOES NOT guarantee that all bits will be 0.

    If this is "C", see:  http://groups-beta.google.com/group/comp.lang.c/msg/fed3e094bd617097?dmode=source&hl=en

    It discusses the two situtations in which 0 is NOT all bits 0

    Even though I highly doubt that return 0 will compile to something other than returning all bits as 0, Couldn't you do something like this?  return 0x0000000000000000;

  • Edgar The Virus Hunter (unregistered)

    The biggest WTF I see is he forgot to add the line:
    assert(bitfield == 0);

    :)

  • Edgar The Virus Hunter (unregistered) in reply to Robin Lavall&#233;e

    You've clearly never written a compiler before.

  • Zatanix (unregistered) in reply to dubwai
    dubwai:

    Even though I highly doubt that return 0 will compile to something other than returning all bits as 0, Couldn't you do something like this?  return 0x0000000000000000;


    hehe.. yeah, coz clearly 0 != 0x0000000000000000 :)
  • (cs) in reply to Xepol
    Xepol:
    true, not as sexy as xor ax,ax, but REP MOVSB can get hardware accerlation flowing

    I think these days the best way to move large amounts of data around is by using the SSE (Streaming SIMD* Extensions)  instructions.

    * SIMD (Single Instruction Multiple Data)

  • (cs) in reply to Edgar The Virus Hunter

    Anonymous:
    You've clearly never written a compiler before.

    What is it with the anonymous cowards posting replies with no context.  Who are you referring to?  What is your point?

  • (cs) in reply to dubwai

    An anonymous ... oh, no, it was dubwai: "What is it with the anonymous cowards posting replies with no context"

    Perhaps Edgar the Virus Hunter (not so anonymous) was expecting the 'Reply' button to add something more than it did. Like some threading to add context.

  • (cs) in reply to Bellinghman

    Bellinghman:
    Perhaps Edgar the Virus Hunter (not so anonymous)

    Yeah, just like 'Deep Throat' wasn't anonymous.

  • (cs) in reply to dubwai

    It looks a little less anonymous than 'dubwai', at least to me.

  • (cs) in reply to Bellinghman

    Bellinghman:
    It looks a little less anonymous than 'dubwai', at least to me.

    Well, you are entitled to your (wrong) opinion.

  • (cs) in reply to Bellinghman

    Bellinghman:
    It looks a little less anonymous than 'dubwai', at least to me.

    My given name is so common that 'dubwai' is a lot less anonymous, if you must know.

  • Edgar The Virus Hunter (unregistered) in reply to Edgar The Virus Hunter

    You see, anyone can post a message as Edgar The Virus Hunter.  It's also quite simple to just create a new name when you want to post something and are too cowardly to associate it to your forum persona.

    That's what I mean by 'anonymous coward'.  There's nothing difficult to understand about it.  I don't understand why you are having trouble.

  • (cs) in reply to dubwai

    "Well, you are entitled to your (wrong) opinion"

    Looks like we'll continue to differ, since you're obviously so fat-headed that you can't see when I'm so obviously right.

    (Note: I'm right. I'm always right. Even Ivanova is wrong when she disagrees with me.)

    I was bemused by your getting upset over 'Edgar' in the first place, and somewhat surprised at your categorisation of him as anonymous, when (a) pseudonymous would better fit, and (b) neither you nor I are posting under our real names either.

    (I've not checked to see whether I can register an ID as 'dubwai'.)

  • (cs) in reply to Bellinghman

    Bellinghman:
    "Well, you are entitled to your (wrong) opinion" Looks like we'll continue to differ, since you're obviously so fat-headed that you can't see when I'm so obviously right. (Note: I'm right. I'm always right. Even Ivanova is wrong when she disagrees with me.)

    No, that's not possible becasue I am always right.  Since you disagree with me you are wrong. QED

    Bellinghman:
    I was bemused by your getting upset over 'Edgar' in the first place,

    Perhaps the source of your bewilderment had it's roots in misinterpreting my criticizm as a sign of my being upset.

    Bellinghman:
    and somewhat surprised at your categorisation of him as anonymous, when (a) pseudonymous would better fit,,

    Well if pedantry is your thing, have at it.  I find semantical arguments to be a waste of time.

    and (b) neither you nor I are posting under our real names either. (I've not checked to see whether I can register an ID as 'dubwai'.)

    dubwai is as real a name as any other that I have.

  • Ignacio (unregistered)

    Truth is the guy gets paid for lines of code, or otherwise has some line count forecast to meet.

    (Engineering gets the fun out of programming!)

  • Anonymous Coward (unregistered) in reply to Ignacio

    You know, that piece of code might be for real...

    We don't know the context of the source. Did it come from a custom piece of hardware, where the default state of some part of memory needs to have all bits set to 0, but declaring an integer with a value of 0 on the particular platform, actually had bits set to 1? It might seem weird but it does happen.

    Maybe it was the only way of coming up with a guarenteed way of ensuring the particular devices memory was initialised/reset correctly.

    BUt if not, a major wt. Probably the worst yet

  • Thomas (unregistered)

    Why the hell would you even need a function for this?

  • (cs) in reply to Nice Day
    Anonymous:
    Bustaz Kool:
    If the INTEGER size changes from 32 bit to, say, 33 bit

    An integer in C would never have an odd number of bits - it used to generally be 16 bits, now it is usually 32 bits - it is always a power of two multiple of the basic data element (char in C)



    I agree that an integer in C never would (no one would be that daft), but technically it could.  There is one odd power of 2, you know.  On an architechture where sizeof(int) == sizeof(short) == 1 and CHAR_BIT == 33 ... but, of course, no one would be that daft.
  • (cs) in reply to Anonymoose
    Anonymous:

    It's not necessarily the fastest way on very late-model x86 architectures. The instruction decoder/scheduler might decide that "xor eax,eax" is dependent upon the result of a previous instruction which modifies eax (obviously it's not - but they might use the same logic for "xor ebx, eax", which is obviously dependent on eax). "mov eax, 0", or any other immediate load, on the other hand is obviously not dependent on any previous value of eax, so even though it's a more complex instruction to decode, it could conceivably be faster.



    That's technically true, but in practice there is so much code out there using "xor reg, reg" to zero registers that there is no way Intel would allow any change that caused a performance hit for this case.  Just think -- AMD would just have to get the dependency analysis right for "xor eax, eax", and they would gain an advantage over Intel.  Can you imagine either one being dumb enough to make such a mistake?

    But the larger point is a good one.  Whether operation X is a single instruction, whether it's in silicon or microcode, what is a good peephole optimisation -- these are all things that are totally dependent on the architecture, and no general statements can be made.
  • GrouchyAdmin (unregistered)

    What the hell? Even for a WTF, I'm thinking 'WTF? Just XOR it?' Why is this so confusing?

  • Anonypony (unregistered)

    Well this is just silly. The task can be done in a single line of C:

    while (bitfield >>= 1);

Leave a comment on “Flipping Out Over Nothin'”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article