단일 바이트가 있다고 가정 해 봅시다.

0110110

하나의 왼쪽 비트 시프트를 적용하면 다음과 같이됩니다.

1101100

가장 왼쪽에있는 0은 바이트에서 벗어나고 바이트의 오른쪽 끝에 새로운 0이 추가되었습니다.

비트는 롤오버되지 않습니다. 그들은 버려집니다. 즉, 1101100을 왼쪽으로 옮긴 다음 오른쪽으로 옮길 경우 동일한 결과를 얻지 못합니다.

왼쪽으로 N만큼 이동하면 ^2N 으로 곱하는 것과 같습니다 .

N만큼 오른쪽으로 이동하면 ( 1의 보수를 사용 하는 경우 )는 ^2N 으로 나누고 반올림 하는 것과 같습니다 .

비트 쉬프팅은 2의 거듭 제곱으로 작업하는 경우, 매우 빠른 곱셈과 나눗셈에 사용할 수 있습니다. 거의 모든 저수준 그래픽 루틴은 비트 쉬프팅을 사용합니다.

예를 들어 옛날에는 게임에 모드 13h (320×200 256 색)를 사용했습니다. 모드 13h에서, 비디오 메모리는 픽셀마다 순차적으로 배치된다. 즉, 픽셀의 위치를 ​​계산하기 위해 다음 수학을 사용합니다.

memoryOffset = (row * 320) + column

요즘 시대에는 속도가 중요했기 때문에 비트 시프트를 사용하여이 작업을 수행했습니다.

그러나 320은 2의 거듭 제곱이 아니므로이 문제를 해결하려면 함께 더한 2의 거듭 제곱이 320을 만드는 것을 찾아야합니다.

(row * 320) = (row * 256) + (row * 64)

이제 왼쪽 시프트로 변환 할 수 있습니다.

(row * 320) = (row << 8) + (row << 6)

최종 결과 :

memoryOffset = ((row << 8) + (row << 6)) + column

고가의 곱셈 연산 대신 두 개의 비트 시프트를 사용한다는 점을 제외하고는 이전과 동일한 오프셋을 얻습니다. 몇 가지 실수와 32 비트 예제를 추가했습니다))

mov ax, 320; 2 cycles
mul word [row]; 22 CPU Cycles
mov di,ax; 2 cycles
add di, [column]; 2 cycles
; di = [row]*320 + [column]

; 16-bit addressing mode limitations:
; [di] is a valid addressing mode, but [ax] isn't, otherwise we could skip the last mov

전체 : 고대 CPU가 이러한 타이밍을 가졌을 때마다 28주기.

Vrs

mov ax, [row]; 2 cycles
mov di, ax; 2
shl ax, 6;  2
shl di, 8;  2
add di, ax; 2    (320 = 256+64)
add di, [column]; 2
; di = [row]*(256+64) + [column]

동일한 고대 CPU에서 12주기.

예, 우리는 16 번의 CPU 사이클을 줄이기 위해 열심히 노력할 것입니다.

32 또는 64 비트 모드에서 두 버전 모두 훨씬 짧아지고 빠릅니다. Intel Skylake ( http://agner.org/optimize/ 참조 ) 와 같은 최신 비 순차적 실행 CPU 는 매우 빠른 하드웨어 곱셈 (낮은 대기 시간 및 높은 처리량)을 가지므로 이득이 훨씬 작습니다. AMD 불도저 제품군은 특히 64 비트 곱하기에 약간 느립니다. Intel CPU 및 AMD Ryzen에서 두 가지 변화는 대기 시간이 약간 적지 만 곱하기보다 더 많은 명령어 수 (처리량 감소로 이어질 수 있음) :

imul edi, [row], 320    ; 3 cycle latency from [row] being ready
add  edi, [column]      ; 1 cycle latency (from [column] and edi being ready).
; edi = [row]*(256+64) + [column],  in 4 cycles from [row] being ready.

vs.

mov edi, [row]
shl edi, 6               ; row*64.   1 cycle latency
lea edi, [edi + edi*4]   ; row*(64 + 64*4).  1 cycle latency
add edi, [column]        ; 1 cycle latency from edi and [column] both being ready
; edi = [row]*(256+64) + [column],  in 3 cycles from [row] being ready.

컴파일러는이를 위해 다음을 수행합니다 . 최적화 할 때 GCC, Clang 및 Microsoft Visual C ++가 모두 shift + lea를 사용return 320*row + col; 하는 방법을 확인하십시오 .

여기서 가장 주목할만한 점은 x86에는LEA 작은 왼쪽 시프트를 수행하고 동시에 명령어로 수행 할 수 있는 시프트 앤 추가 명령어 ( ) 가 있다는 것 add입니다. ARM은 더욱 강력합니다. 명령의 피연산자 하나를 왼쪽이나 오른쪽으로 자유롭게 이동할 수 있습니다. 따라서 2의 거듭 제곱으로 알려진 컴파일 시간 상수에 의한 스케일링은 곱하는 것보다 훨씬 효율적일 수 있습니다.

좋아, 현대에 … 이제 더 유용한 것은 비트 시프 팅을 사용하여 두 개의 8 비트 값을 16 비트 정수로 저장하는 것입니다. 예를 들어, C #에서 :

// Byte1: 11110000
// Byte2: 00001111

Int16 value = ((byte)(Byte1 >> 8) | Byte2));

// value = 000011111110000;

C ++에서 struct두 개의 8 비트 멤버와 함께 a를 사용한 경우 컴파일러 에서이를 수행해야하지만 실제로는 항상 그렇지는 않습니다.

답변

  bit | 15| 14| 13| 12| 11| 10| 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1  | 0 |
      |       Blue        |         Green         |       Red          |

 #define GREEN_MASK  0x7E0
 #define GREEN_OFFSET  5

 // Read green
 uint16_t green = (pixel & GREEN_MASK) >> GREEN_OFFSET;

#define GREEN_MASK  0x7E0

uint16_t green = (pixel & GREEN_MASK) ...;

uint16_t green = (pixel & GREEN_MASK) >> GREEN_OFFSET;

 i <<= x;  // i *= 2^x;
 i >>= y;  // i /= 2^y;

 Pixel-Color Value in Hex:    B9B9B900
 Pixel-Color Value in Binary: 10111001  10111001  10111001  00000000

                                 Red     Green     Blue       Alpha
 Pixel-Color Value in Binary: 10111001  10111001  10111001  00000000

                  Red      Green      Blue      Alpha
 color :        10111001  10111001  10111001  00000000
 green_mask  :  00000000  11111111  00000000  00000000

 masked_color = color & green_mask

 masked_color:  00000000  10111001  00000000  00000000

 green_value = masked_color >>> 16

 Pixels-Green Value in Hex:     000000B9
 Pixels-Green Value in Binary:  00000000 00000000 00000000 10111001
 Pixels-Green Value in Decimal: 185

char x = -1;
x >> 1;

(long) 4 >> 65

(long) 4 >> (65 % 64)