Bitwise shift question

[seanken]

Hi All,

I have this piece of C code. Any idea of why it uses a bitwise shift ('<<' at the bottom of this note)? The file contains hexidecimal records... The wvar seems to be 1 char/int returned to the calling routine. Is it some way to identify the bytes on the record to return?

I'm supposed to be maintaining this code so I suppose it'd be a good idea to understand it..

Thanks,
Sean

void HandleCommonRecord(BYTE bType)
{

struct EffISDNEstruct stInternal;

memset(&stInternal,0,sizeof(stInternal));

ReadTL3Word(stAppInst.fInFile,&stInternal.wRecSize);

}

void ReadTL3Word(FILE *iFile,WORD *wVar)
{

BYTE bHigh = 0,bLow = 0;

fread(&bHigh,1,1,iFile);
fread(&bLow,1,1,iFile);

*wVar = bLow + (bHigh << 8);

}

 

[Zyrenthian]

What is happening is the 2 bytes (high and low) are the high 8 bits and low 8 bits of a 16 bit value. However, when the data was written out, it wrote it out in 8 bit parts. Reading in 16 bits will not give the same value as reading in 1 bit and another bit. Another way to approach this is to assign wVar as follows

*wVar = bLow | (bHigh<<8);

I hope this helped. If not I can give a more detailed description.

Matt

 

[seanken]

Hi Matt,

You'll have to spell it out, I'm afraid. Being from an Oracle background, this C will be giving me a pain for a while yet.

Seems to me that we have 16bits (8+8) in Hex format on the incoming file. The first 8 are read into bHigh and the second into bLow, then I get lost.

Sean

 

[Zyrenthian]

Ok, Lets say that the input from the file looks like this

17 21

reading in we get the high bit set to 17 and the low bit set to 21

First you have to understand how this looks in binary:

17 in binary (8 bits) is 00010001
21 in binary (8 bits) is 00010101

so bHigh currently is = 17

when we use the line (bHigh<<8) we shift the bits 8 to the left creating a new value. The new value is

0001000100000000 (in binary) or 4352 in decimal/1100 Hex

now, adding the two together will look like this

 0001000100000000
+0000000000010101
-----------------
 0001000100010101

or 4352+21 = 4373 in decimal

It is now in 16 bit representation. Does this help any more?

Matt

 

[seanken]

Matt,

Yep, have the theory now. Thanks. What was/is throwing me is why would anyone ever want to use something like this. If the 16 bit word coming from the switch (i'm in telecomms, more's the pity!) is, for example, 17 & 21 (or 11 & 15 in Hex format) I would have thought that the word would be displayed as such (1721) and left at that. Maybe there is some business logic behind this I have yet to come across.

Last thing, can you think of any practical examples for using bitwise? The only one I can think of would be maybe using it to convert to Binary, etc. Once I get a logical example into my head, I should be OK.

Anyway, thanks for taking the time to clear this up. Much appreciated.

Rgds,
Sean

 

[Zyrenthian]

One example could be endianism. Some machines represent bits from right to left and some from left to right. It is know as BIG Endian format and LITTLE Endian format. The process of manipulating the bits for each platform is known as byteswapping. With 8 bit representation, no byteswapping is required but with 2 4 or 8 BYTE represenation byteswapping would be required. With that in mind:

a character is 8 bits
a short is 16 bits
a long is 32 bits

looking at letters to represent the BYTES this is how byteswapping would work

8 bits A no byteswapping
16 bits AB would become BA
32 bits ABCD would become DCBA

by writing out the data 8 bits at a time, the data can remain intact and be read cross platform.

This is just one example, but it is one that popped out in my head.

Matt

 

[seanken]

mmmm...this rings a bell. I heard one of the switch guys mention something similar to this a while back. Makes sense to shift now.

Again, thanks for the help.

Sean

 

[tmoody]

Sean,

just a quick note. I write code for test equipment to test electronics product on a production line. I use the bitwise shift operator quite a bit. One of the routines I wrote receives a 32bit word, masks off the upper 24bits, writes the lower eight bits out a port, and then shits that 32bit word right 8 bits. I mask the upper twenty four and write the lower eight bits and shift right 8,.....etc. You see I am passed a 32 bit word but only have a 8 bit port so I need to shift to get all 32 bits out. Now in memory on the external device, I have put the LSB first and the MSB last, so if my original 32bits were 01020304, I would see them as 04030201 in my external device. Like the man said, cross platform compatability, but I always figured it was an inherent weakness to the Intel architecture, like segment-offset.

Tim