• mmddmm@lemm.ee
      link
      fedilink
      arrow-up
      2
      ·
      1 month ago

      And compiler. And hardware architecture. And optimization flags.

      As usual, it’s some developer that knows little enough to think the walls they see around enclose the entire world.

      • timhh@programming.dev
        link
        fedilink
        arrow-up
        0
        ·
        1 month ago

        I don’t think so. Apart from dynamically typed languages which need to store the type with the value, it’s always 1 byte, and that doesn’t depend on architecture (excluding ancient or exotic architectures) or optimisation flags.

        Which language/architecture/flags would not store a bool in 1 byte?

        • brian@programming.dev
          link
          fedilink
          arrow-up
          1
          ·
          1 month ago

          things that store it as word size for alignment purposes (most common afaik), things that pack multiple books into one byte (normally only things like bool sequences/structs), etc

          • timhh@programming.dev
            link
            fedilink
            arrow-up
            0
            ·
            1 month ago

            things that store it as word size for alignment purposes

            Nope. bools only need to be naturally aligned, so 1 byte.

            If you do

            struct SomeBools {
              bool a;
              bool b;
              bool c;
              bool d;
            };
            

            its 4 bytes.

            • brian@programming.dev
              link
              fedilink
              arrow-up
              1
              ·
              1 month ago

              sure, but if you have a single bool in a stack frame it’s probably going to be more than a byte. on the heap definitely more than a byte

              • timhh@programming.dev
                link
                fedilink
                arrow-up
                0
                ·
                1 month ago

                but if you have a single bool in a stack frame it’s probably going to be more than a byte.

                Nope. - if you can’t read RISC-V assembly, look at these lines

                        sb      a5,-17(s0)
                ...
                        sb      a5,-18(s0)
                ...
                        sb      a5,-19(s0)
                ...
                

                That is it storing the bools in single bytes. Also I only used RISC-V because I’m way more familiar with it than x86, but it will do the same thing.

                on the heap definitely more than a byte

                Nope, you can happily malloc(1) and store a bool in it, or malloc(4) and store 4 bools in it. A bool is 1 byte. Consider this a TIL moment.

                • brian@programming.dev
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  1 month ago

                  c++ guarantees that calls to malloc are aligned https://en.cppreference.com/w/cpp/memory/c/malloc .

                  you can call malloc(1) ofc, but calling malloc_usable_size(malloc(1)) is giving me 24, so it at least allocated 24 bytes for my 1, plus any tracking overhead

                  yeah, as I said, in a stack frame. not surprised a compiler packed them into single bytes in the same frame (but I wouldn’t be that surprised the other way either), but the system v abi guarantees at least 4 byte alignment of a stack frame on entering a fn, so if you stored a single bool it’ll get 3+ extra bytes added on the next fn call.

                  computers align things. you normally don’t have to think about it. Consider this a TIL moment.

  • skisnow@lemmy.ca
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 month ago

    Back in the day when it mattered, we did it like

    #define BV00		(1 <<  0)
    #define BV01		(1 <<  1)
    #define BV02		(1 <<  2)
    #define BV03		(1 <<  3)
    ...etc
    
    #define IS_SET(flag, bit)	((flag) & (bit))
    #define SET_BIT(var, bit)	((var) |= (bit))
    #define REMOVE_BIT(var, bit)	((var) &= ~(bit))
    #define TOGGLE_BIT(var, bit)	((var) ^= (bit))
    
    ....then...
    #define MY_FIRST_BOOLEAN BV00
    SET_BIT(myFlags, MY_FIRST_BOOLEAN)
    
    
    • ethancedwards8@programming.dev
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 month ago

      Okay. Gen z programmer here. Can you explain this black magic? I see it all the time in kernel code but I have no idea what it means.

      • skisnow@lemmy.ca
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        1 month ago

        The code is a set of preprocessor macros to stuff loads of booleans into one int (or similar), in this case named ‘myFlags’. The preprocessor is a simple (some argue too simple) step at the start of compilation that modifies the source code on its way to the real compiler by substituting #defines, prepending #include’d files, etc.

        If myFlags is equal to, e.g. 67, that’s 01000011, meaning that BV00, BV01, and BV07 are all TRUE and the others are FALSE.

        The first part is just for convenience and readability. BV00 represents the 0th bit, BV01 is the first etc. (1 << 3) means 00000001, bit shifted left three times so it becomes 00001000 (aka 8).

        The middle chunk defines macros to make bit operations more human-readable.

        SET_BIT(myFlags, MY_FIRST_BOOLEAN) gets turned into ((myFlags) |= ((1 << 0))) , which could be simplified as myFlags = myFlags | 00000001 . (Ignore the flood of parentheses, they’re there for safety due to the loaded shotgun nature of the preprocessor.)

      • NιƙƙιDιɱҽʂ@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        1 month ago

        It’s called bitshifting and is used to select which bits you want to modify so you can toggle them individually.

        1 << 0 is the flag for the first bit
        1 << 1 for the second
        1 << 2 for the third and so on

        I think that’s correct. It’s been years since I’ve used this technique tbh 😅

    • Quatlicopatlix@feddit.org
      link
      fedilink
      arrow-up
      1
      ·
      1 month ago

      With embedded stuff its still done like that. And if you go from the arduino functionss to writing the registers directly its a hell of a lot faster.

    • bastion@feddit.nl
      link
      fedilink
      arrow-up
      0
      ·
      1 month ago

      The alignment of the language and the alignment of the coder must be similar on at least one metric, or the coder suffers a penalty to develop for each degree of difference from the language’s alignment. This is penalty stacks for each phase of the project.

      So, let’s say that the developer is a lawful good Rust zealot Paladin, but she’s developing in Python, a language she’s moderately familiar with. Since Python is neutral/good, she suffers a -1 penalty for the first phase, -2 for the second, -3 for the third, etc. This is because Rust (the Paladin’s native language) is lawful, and Python is neutral (one degree of difference from lawful), so she operates at a slight disadvantage. However, they are both “good”, so there’s no further penalty.

      The same penalty would occur if using C, which is lawful neutral - but the axis of order and chaos matches, and there is one degree of difference on the axis of good and evil.

      However, if that same developer were to code in Javascript (chaotic neutral), it would be at a -3 (-6, -9…) disadvantage, due to 2 and 1 degree of difference in alignment, respectively.

      Malbolge (chaotic evil), however, would be a -4 (-8, -12) plus an inherent -2 for poor toolchain availability.

      …hope this helps. have fun out there!

      • squaresinger@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        16 days ago

        If JS is chaotic neutral, what then is chaotic evil?

        All I’m saying is

        "10" + 1 => "101"
        "10" - 1 => 9
        "a" - "b" => NaN
        
        • bastion@feddit.nl
          link
          fedilink
          arrow-up
          2
          ·
          14 days ago

          fair enough. My personal opinion might be that it’s evil, but perhaps that’s because I expected some kind of order.