Shifting left – a general C question

[EThom.3]

Hi,

I have a piece of CRC calculating code that I nicked from somewhere a couple of decades ago. I've been wondering about a few lines:

  *CRCVal ^= (*CRCVal << 8) << 4;
  *CRCVal ^= ((*CRCVal & 0xFF) << 4) << 1;

(CRCVal is a pointer to a uint16_t variable.)

What I'm curious about is the slightly weird left-shifting notation. Shouldn't it give exactly the same result if it was written like this?

  *CRCVal ^= (*CRCVal << 12);
  *CRCVal ^= (*CRCVal & 0xFF) << 5;

Does anyone have a hunch why the shifts are split up like this? Could it be something related to a specific compiler or device that handles half-byte shifts in a certain way?

By the way, it would be great if this forum had a "General programming" board. I prefer to ask questions here, as I think that the community has a nice vibe.

[Andrew Neil]

---

@EThom.3 wrote:

Or perhaps an 8051, if that even had a C compiler 20-30 years ago. .

---

Keil C51 was well-established 20-30 years ago.

Keil was established as an 8051 tools company long before ARM bought them.

https://en.wikipedia.org/wiki/Keil_(company)

[EThom.3]

Interesting. Thanks.

Thus, my best guess is that the piece of code was originally made for either a PIC or an 8051.

[Andrew Neil]

Maybe by someone trying to write assembler in C: they didn't realise that the compiler can work out how to do a 12-bit shift - they didn't have to manually decompose it themselves?

Used to see a lot of that.

Also people thinking that cramming as much as possible into a single source line would produce less object code!

[EThom.3]

I just thought of something.

If this – quite old – code was indeed written for a PIC, it might have been written in an ancient MPLAB C compiler environment. Around the turn of the century, the MPLAB C17 compiler was not ANSI C compliant, had insane limitations, and was riddled with errors. If the CRC code was used in that environment, the doubled shifting operations might have been a work-around to get the code to compile correctly.

[EThom.3]

---

@Andrew Neil wrote:

Also people thinking that cramming as much as possible into a single source line would produce less object code!

---

I have seen one guy removing whitespaces and empty lines, to make the program smaller. Or go faster – I'm not sure.

[TDK]

> I have seen one guy removing whitespaces and empty lines, to make the program smaller. Or go faster – I'm not sure.

Compressing whitespace in C does not affect program output.

[EThom.3]

Of course it doesn't. That's what made the guy's attempts mildly amusing.