Noob question: why equ 1<<0 in barebones tutorial

[gfmoore]

I am so sorry about this question, but I can't find any answer and I don't get it.

In the barebones (which I have got working from a usb memory stick with Grub2 - hurrah!) there are the first lines that go

MODULEALIGN equ 1<<0 ; align loaded modules on page boundaries
MEMINFO equ 1<<1

Now I know that << means shift left, but since the first one means 1 shifted left by 0 places then isn't it just 1, so why not just write that.
And 1<<1 means 10 which is 2 so why not just write that?

And if you care to explain how this aligns the code on a page boundary I'd be pleased

Gordon

[Velko]

Now I know that << means shift left, but since the first one means 1 shifted left by 0 places then isn't it just 1, so why not just write that.
And 1<<1 means 10 which is 2 so why not just write that?

And if you need to set 21-st bit, why not just write 2097152?

There's no need to pre-calculate constants, it will take few microseconds for compiler to do that. And writing 1<<0, 1<<1 or 1<<21 your code clearly says "A value with its 0-th, 1-st or 21-st bit set" not "some magic number".

[Solar]

It's just common practice:

Code: Select all

1 << 0     # Bit #0
1 << 1     # Bit #1
1 << 2     # Bit #2

And so on.

[rdos]

It's ugly. I'd use hex or binary notation instead.

[SDS]

it is ugly, but it is also clear.

For instance (1 << 4) --> The fourth bit, rather than 16 which could be being used for all manner of things. It is some attempt to communicate contextual information, speeding the processes of a programmer comprehending both what, how and why a piece of code is doing what it does.

Similar to comments really.

[rdos]

it is ugly, but it is also clear.

For instance (1 << 4) --> The fourth bit, rather than 16 which could be being used for all manner of things. It is some attempt to communicate contextual information, speeding the processes of a programmer comprehending both what, how and why a piece of code is doing what it does.

Similar to comments really.

1 << 4 would be 0x10. It is clear. I'd only use bitshifts if the shifts themselves are subject to possible change:

Code: Select all

#define SOME_BIT 4

...

    if (bit & (1 << SOME_BIT))

Better (if bits are not subject to change)

Code: Select all

#define MASK 0x10

...

    if (bit & MASK)

[Solar]

You might do that. Other people do different.

The idea behind "contextual information" is that 0x10 is just a number, while 1 << 4 is an integer with (only) bit #4 set. The integer is the same, but 1 << 4 makes the intent explicit.

But people are still resisting the idea of code comments, so who am I to judge.

[Chandra]

But people are still resisting the idea of code comments

I prefer documenting few portions of code that carries complex logic behind it and for which inline commenting renders it as an essay.

[gfmoore]

Phew I didn't get my head bitten off - I was so worried (lol)

Thanks guys and now it is clear as to why it is done that way.

As Solar says: Every good solution is obvious once you've found it.

[rdos]

What about this then:

Code: Select all

#define ACTION_MASK 0x180

...

   if (Msg & ACTION_MASK)

would you do it like this:

Code: Select all

#define ACTION_MASK (1 << 8) | (1 << 7)

...

   if (Msg & ACTION_MASK)

I find this type of notation kind of "reinventing the wheel". The compiler already has ways to provide bitmasks. At least my PIC compiler can do this:

Code: Select all

    movlw b'0001000'

or

Code: Select all

    movlw b'1001010'

I would not want to change the last example to:

Code: Select all

    movlw (1 << 7) | (1 << 4) | (1 << 2)

As it is totally unreadable!

[gerryg400]

Code: Select all

    movlw b'1001010'

I would not want to change the last example to:

Code: Select all

    movlw (1 << 7) | (1 << 4) | (1 << 2)

As it is totally unreadable!

And incorrect. It should be

Code: Select all

    movlw (1 << 6) | (1 << 3) | (1 << 1)

In any event, I agree with you rdos. I've been reading plain old binary and hex for my entire programming life I'm used to it.

[Velko]

Code: Select all

    movlw b'1001010'

I would not want to change the last example to:

Code: Select all

    movlw (1 << 7) | (1 << 4) | (1 << 2)

As it is totally unreadable!

So, you would prefer

Code: Select all

and $0b1111111111111111111111111111111111111111111111101011111011111111, %rax

over

Code: Select all

and $~(1 << 8 | 1 << 14 | 1 << 16), %rax

[SDS]

Code: Select all

#define ACTION_MASK 0x180

Code: Select all

#define ACTION_MASK (1 << 8) | (1 << 7)

To be honest, I wouldn't particularly care. That said, if it was the specific bits which were important I would probably use the latter.

As you mentioned, bitmasks work fine. However, if you have set, say the 47th bit in a 64bit integer, then then I would argue that

Code: Select all

1 << 47

is substantially clearer than any of

Code: Select all

b'100000000000000000000000000000000000000000000000'
800000000000
140737488355328

simply as I'm not very good at counting any number of zeros over, say, four at a momentary glance, whereas I can read the number 47.

Once I have a working general solution, I see little reason to use a less general solution for simple cases. It doesn't make things more clear to represent them as a number after all.

[SDS]

If it is in C, then it's very error prone the way you wrote it.

Assuming that normal good practice is used ... such as

Code: Select all

#define ACTION_MASK ((1 << 8) | (1 << 7))

[Casm]

then isn't it just 1, so why not just write that.
And 1<<1 means 10 which is 2 so why not just write that?

I must admit that is what I would do. If it was some obscure bit like 27 there might be some point in doing it the other way, but up to about 0x200 I would just write 0x200.