extracting front bits from an unsigned long long?

[pete]

BTW, does C make any guarantees that the code works both endianness? I
have worked with compilers where shifting didn't do what I expected
because the machine was little endian.

If you have a two byte int and you shift it to the right,
the low order bit of the high order byte goes into the low order byte.
That happens regardless of which byte is high order.
That's what's supposed to happen.
The byte with the higher address isn't inherently
high order or low order, as far as C is concerned.

You can write portable code to
print the values of all the bytes in an int object,
from lowest to highest address and/or from highest to lowest.
This code will use the address of the int object.

You can write portable C code to print the values
of all of the bytes of an int value which have value bits,
in order from least significant to most significant
or the other way around.
This code will not use the address of the object
and will be able to operate on constant expressions.

 

[Michael Mair]

If the compiler follows C standards. As I said before, I HAVE used a
compiler where this is not the case. But that is outside the scope of
c.l.c of course.
Definitely.



Yes. That's what I expected. What's with your "so what" ?

You used "But"; this seems to raise a contradictory point. From
the context
,----
| If the number is in hex and output in hex then of course it always
| works. But I was expecting something like:
|
| (305419896 >> 16) & 0xff == 52
`----
I can only infer that the expected result does in your opinion
not match the "always work"ing one in hex.
"So what" documented the fact that I do not see this contradiction.

-Michael

 

[Digital Puer]

int extractFrontBits(unsigned long long value, int num_bits)
{
return (int)(value & ((1ULL << num_bits) - 1))
}

This doesn't seem to work right. I'm getting the following output:

print binary of 7387272179287021119:
01100110 10000100 11011100 11101000 01011001 10000111 01010110
00111111
extractFrontBits (for 3 bits) returned 7

The 3 most signficant bits of that number are 011, which should be 3.

Here is how I called it:

main()
{
unsigned long long test = 7387272179287021119ULL;
print_binary_ull(test);
int value = extractFrontBits(test, 3);
printf("extractFrontBits (for 3 bits) returned %d\n", value);
}

void print_binary_ull(unsigned long long value)
{
unsigned long long value2;
int i;
printf("print binary of %llu:\n", value);
for (i = 63; i >= 0; i--)
{
value2 = value & ((unsigned long long)1 << i);
printf("%d", value2 ? 1 : 0);
if (i == 32) printf(" ");
else if ((i %8) == 0) printf(" ");
}
printf("\n");
}

 

[pete]

This doesn't seem to work right. I'm getting the following output:

print binary of 7387272179287021119:
01100110 10000100 11011100 11101000 01011001 10000111 01010110
00111111
extractFrontBits (for 3 bits) returned 7

The 3 most signficant bits of that number are 011, which should be 3.

Oh, you want the Most significant bits! (Good call, Keith Thompson!)

The just do what everybody else has been saying,
shift your value to right
by the difference between
the number of bits in the type, and n.

Padding bits can screw this up,
but I've never actually seen a padding bit,
so if you don't care, I don't care.
There might also be problems if the result of the shift
excedes INT_MAX.

#include <stdio.h>
#include <limits.h>

int extractFrontBits(unsigned long long value, int num_bits)
{
return (int)(value >> (CHAR_BIT * sizeof value - n));
}

void print_binary_ull(unsigned long long value);

int main(void)

{
unsigned long long test = 7387272179287021119ULL;
print_binary_ull(test);
int value = extractFrontBits(test, 3);
printf("extractFrontBits (for 3 bits) returned %d\n", value);

return 0;

}

void print_binary_ull(unsigned long long value)
{
unsigned long long value2;
int i;
printf("print binary of %llu:\n", value);
for (i = 63; i >= 0; i--)
{
value2 = value & ((unsigned long long)1 << i);
printf("%d", value2 ? 1 : 0);
if (i == 32) printf(" ");
else if ((i %8) == 0) printf(" ");
}
printf("\n");
}

 

[Digital Puer]

Oh, you want the Most significant bits! (Good call, Keith Thompson!)

Great! thank you very much, pete and everyone else!

Just for my edification, how else would one interpret "front bits"?
I'm assuming you're talking about the byte order in memory
(endianness), right? I just thought it would be pretty clear that
the "front bits" of a number would be the most signficant bits.
E.g. the front digit of 543 is 5.

 

[Keith Thompson]

Great! thank you very much, pete and everyone else!

Just for my edification, how else would one interpret "front bits"?
I'm assuming you're talking about the byte order in memory
(endianness), right? I just thought it would be pretty clear that
the "front bits" of a number would be the most signficant bits.
E.g. the front digit of 543 is 5.

I thought it most likely meant the most significant bits, but I
wouldn't use the term "front" in the first place.

 

[Netocrat]

]

Padding bits can screw this up,
but I've never actually seen a padding bit,
so if you don't care, I don't care.

Peter Nilson provided equally simple code that did care and was portable.
Why ignore it?

 

[pete]

]

Padding bits can screw this up,
but I've never actually seen a padding bit,
so if you don't care, I don't care.

Peter Nilson provided equally
simple code that did care and was portable.
Why ignore it?

I didn't understand the problem at the time that he posted it.

 

[Mark McIntyre]

Just for my edification, how else would one interpret "front bits"?

I wouldn't - it doesn't mean anything to me. Arrays of bits don't have
backs, fronts or sides...

E.g. the front digit of 543 is 5.

First perhaps. Leftmost perhaps. Front no.

 

[slebetman]

I wouldn't - it doesn't mean anything to me. Arrays of bits don't have
backs, fronts or sides...


First perhaps. Leftmost perhaps. Front no.

Haven't had much experience with non-native english speakers have you?
In a lot of eastern languages front and first are synonyms.

 

[Richard Tobin]

Haven't had much experience with non-native english speakers have you?
In a lot of eastern languages front and first are synonyms.

They are often synonyms in English. In particular, when objects are
moving along a path, the front one will be the first one. But when
(as is the case here) the idea is of looking at a static sequence of
objects, the situation is less clear. "3" is the first digit of 315
when you read or write it, but if you imagine the sequence itself
pointing in left-to-right order (i.e. English reading order) then you
would call "5" the front digit.

In such circumstances it is better to be explicit and say "leftmost",
or if you don't even want to commit to a particular writing direction,
"most significant".

-- Richard

 

[Mark McIntyre]

Haven't had much experience with non-native english speakers have you?

No, I only worked for a French bank for 10 years. Plus let me tell
you, working in London is like working in the tower of babel..

In a lot of eastern languages front and first are synonyms.

So what?

 

[Flash Gordon]

Haven't had much experience with non-native english speakers have you?
In a lot of eastern languages front and first are synonyms.

That's as maybe, but this is not one of those eastern languages.

I would not use front or first. I would possibly use left, but generally
highest or most significant.

 

[pete]

I didn't.

Me neither.

I would call that, the most significant digit.

Haven't had much experience with non-native english speakers have you?
In a lot of eastern languages front and first are synonyms.

It seemed to me, that given a choice between bit0 and bit1,
that bit0, the low order bit, would be the first one.

But I often have trouble understanding plain English,
and yes, it is my only language.

I like to code but I don't enjoy extracting specifications.
I really would have to be paid, in order to do that.

When somebody posts a question and I don't understand it right,
then I answer it wrong.

When somebody posts a question and I do understand it right,
then my chances are better.

 

[slebetman]

So what?

So, to a lot of people like me, who often 'think' in our native
language and then translate into english we often say front instead of
first. In Malay for instance, first relates to chronological sequence
and front relates to spatial sequence. A sequence of bits in a register
or in memory is spatial. I'm not saying you're wrong. As in english it
IS better to use 'first'. Actually it is better to use 'most
significant'. My point is simply that not everyone thinks that way.

OK, so there was a misunderstanding. It has been resolved. The OP is
happy. Move along now...

 

[Dik T. Winter]

> In article <[email protected]>,
....
> In such circumstances it is better to be explicit and say "leftmost",
> or if you don't even want to commit to a particular writing direction,
> "most significant".

And both do not really convey the meaning of the OP. Which was (as I
understand it now) the sequence of 'k' bits starting at the first 1 bit
in the binary representation of the number. Or (in other terms) the
first 'k' bits if leading 0's are ignored.

 

[Mark McIntyre]

So, to a lot of people like me, who often 'think' in our native
language and then translate into english we often say front instead of
first.

If you cast your mind back, you'll recall that the question I was
answering was "how would you interpret front bits". Not unnaturally I
expressed my opinion of how I'd intrepret it, and what I'd call the
leftmost bit of eg 543.

It was NOT "how would you expect someone with limited grasp of English
to translate their own word for 'first' into English". So I didn't
answer this question.

So you see, I consider your comment utterly bloody irrelevant!

OK, so there was a misunderstanding. It has been resolved.

I do hope so