단어 당 2 비트의 비트가 "편리한"입니까? 그렇다면 왜 그렇습니까?


11

바이너리 워드 (예 : 바이트 당 8 비트)에서 2의 거듭 제곱 비트가 "좋은 것"또는 "편리한 것"이라고 주장하는 여러 출처를 발견했습니다. 이유를 지적하는 출처가 없습니다.

에서 어떤 바이트는 8 비트 이유의 역사는? 우리는 승인 된 답변을 읽습니다.

이진 컴퓨터는 디자이너에게 2의 크기를 제고하도록 동기를 부여합니다.

그래, 왜? 같은 질문이지만 질문의 주석 필드에 다음이 있습니다.

농담의 마지막 문장입니까? 12 비트 바이트는 2의 거듭 제곱이 아니므로 불편합니다.-robjb

다시, 근거가없는 ...

주소 계산은 2의 거듭 제곱으로 훨씬 간단하고 작은 캔으로 원시 트랜지스터에서 논리를 만들 때 계산됩니다-Mike

바이트는 주소를 지정할 수있는 가장 작은 단위이므로 의미가 없습니다. 댓글에 대한 많은 공감대. 어쩌면 나는 뭔가를 놓쳤다.

에서 위키 백과 :

사실상 8 비트의 표준은 2의 편리한 거듭 제곱으로 1 바이트에 대해 0에서 255 사이의 값을 허용합니다.

그리고 이것은 편리하기 때문에 ...?

명확히하기 위해, 이것은 바이트 당 의 수 (예 : 2 8 또는 2 6 등)가 아니라 바이트 당 비트 수 (예 : 8 또는 6 등)에 관한 것입니다. 혼란 때문에 나는 이것이 단어 크기에 관한 것이 아니라고 지적합니다.

나는 역사적인 이유에 지나치게 관심이 없습니다. 그것들은 다른 곳에서 잘 설명되었습니다 (링크 참조).


SO에 대한 관련 질문 : https : //.com/questions/1606827/why-is-number-of-bits-always-a-power-of-two


2
@gnat 나는 바이트 당 나타낼 수있는 값의 수 (즉 8 비트 바이트의 2 ^ 8)가 아니라 바이트 당 비트 수 (즉 8 비트 바이트의 8)에 대해 이야기하고 있다고 확신합니다. 예를 들어 6 비트 바이트가있는 경우 6 은 2의 거듭 제곱이 아니지만 예, 6 비트 바이트는 2 개 값의 거듭 제곱을 나타낼 수 있습니다.
8bittree

2
@ 8bittree 설명을 해주셔서 감사합니다. (중복 투표 철회-마지막 의견과 같은 설명을 질문에 편집 하면 독자가 더 쉬울 것이라고 생각하지만 , 이것은 다소 미묘한 것 같습니다)
gnat

2
SO에 대한 비슷한 질문 : stackoverflow.com/q/1606827/3723423- 대답은 편의성에 대한 그럴듯한 주장을 가져옵니다
Christophe

2
@Snowman : OP의 게시물에 "질문을 던지다"라는 오류가 있습니다. "왜 두 개의 제곱이 편리한 바이트 크기로 간주됩니까?" 그렇지 않습니다. 그것은 2의 거듭 제곱과 관련이 없습니다. 그는 Wikipedia 기사의 문장을 잘못 읽었습니다.
Robert Harvey

3
@RobertHarvey "바이트가 8 비트 인 이유는 무엇입니까?" (내 질문에도 연결되어 있음) 다음과 같은 문장이 있습니다. "바이너리 컴퓨터는 디자이너가 크기를 2로 제곱하도록 동기를 부여합니다." 나도 이것을 잘못 읽었습니까? 귀하의 의견으로는 두 가지 출처가 무엇을 의미합니까? 단지 "당신이 틀렸다"고 말하는 것은 실제로 나를 위해 그것을하지 않습니다.
Andreas

답변:


10

나는 8 비트 바이트가 2의 거듭 제곱 인 너비를 가지고 있기 때문에 성공하지 못했다고 생각합니다. 비트를 개별적으로 처리하고 싶지 않고 현재와 과거의 공통 기능이 아닌 경우 2의 거듭 제곱을 갖는 것은 실제로 중요하지 않습니다 (단지-지금은 스페어 할 때 과거보다 훨씬 더 중요합니다) 하드웨어와 소프트웨어 엔지니어를위한 리플렉션과 다른 목적을 위해서는 친숙한 장소에 머무르는 것이 중요합니다.) 컴퓨터 판독 기록 (1)에서 언급 한 것을 기억하지 못합니다. 하나는 소문자가 필요했는데, 이는 당시 지배적 인 6 비트 문자 세트보다 더 큰 의미가있었습니다. ASCII는 7 비트 였지만 ASCII는 순전히 상호 교환과 같으므로 처리를 위해 내부 코드로 변환되었습니다.

소위원회는 컴퓨터 제조업체가 7 비트 코드를 내부적으로 사용하는 컴퓨터를 설계하지 않을 것임을 인식하고 있습니다. 4 비트, 6 비트 및 8 비트 코드를 사용할 가능성이 높습니다. 현재 컴퓨터와 컴퓨터 및 관련 입력 / 출력 장비간에 128 개 이상의 개별 문자와 고유 문자를 교환 할 필요가 없습니다. [8 비트의 자연스러운 프레임 크기를 가지지 만 패리티가 필요한 페이퍼 테이프는 프레임의 페이로드가 7 비트가되었으므로 ASCII의 경우 7 비트 문자를 선호하며 8의 이점 중 2의 거듭 제곱은 인용되지 않았습니다. ] (2)

하드웨어의 8 비트 바이트는 데이터의 75 %가 숫자이고 BCD (3)로 표시 될 때 한 바이트에 2 개의 10 진수를 넣을 수 있기 때문에 원했습니다.

(1) 예를 들어 컴퓨터 아키텍처 인 Blaauw and Brooks ; MacKenzie, 코드화 된 문자 세트, 히스토리 및 개발 은 모두 해당 주제에 대한 토론입니다.

(3) MacKenzie가 인용 한 ASCII를 담당하는 소위원회 X3.2의 문서.

(3) 다시 맥켄지.


1
감사합니다. 귀하의 답변이 제자리에 있으며 참조를 가져 왔습니다. 당신은 내 투표를했습니다. 나는 당신이 말하는 것이 사실이라면 증명하는 것도 불가능하다는 것을 알고 있습니다. 존재하지 않는 것을 증명할 수 없습니다. "편의성"이라고 주장하는 사람들을 실제로 소개하고 그들의 출처를 확인해야한다고 생각합니다. 어쩌면 그것은 널리 퍼진 소문 일뿐입니다.
Andreas

또 다른 편의 요소는 바이트를 2 개의 16 진 값으로 쉽게 표현할 수 있다는 것입니다. 1 바이트에 2 개의 이진 코드 10 진수 (BCD)를 넣는 것을보다 일반적으로 팩형 10 진수라고합니다. 데이터가 16 진으로 표시 될 때 소수를 10 진수로 읽을 수 있기 때문에 이는 실제로 편리한 것으로 간주되었습니다.
JimmyJames

12 비트 바이트는 3 개의 16 진수 값으로 쉽게 표현할 수 있습니다. 그리고 3 개의 BCD 번호를 12 비트 바이트에 저장할 수 있습니다. 분명히 그것은 두 개의 16 진 값과 두 개의 BCD 숫자보다 훨씬 낫습니다. 실제로 10 비트 바이트에는 3 개의 10 진수가 포함될 수 있습니다. 그리고 이것이 IEEE 소수점 부동 소수점 표준이 작동하는 방식이라고 생각합니다.
gnasher729

1
@JimmyJames, 나는 당신이 인과 관계를 16 진수로 바꾸 었다고 생각합니다. 16 진수는 8 비트 바이트를 나타내는 컴팩트 한 방법 이었기 때문에 인기가있었습니다. 이전에 8 진수가 훨씬 인기가있었습니다 (8 비트 바이트를 가지고 있지만 3 비트 필드가 중요한 PDP-11과 같은 컴퓨터에서 더 많이 사용되었습니다) 명령어 세트 인코딩에서).
AProgrammer

@ gnasher729, 8 비트 바이트는 60 년대의 자식입니다. 6 비트 문자에서 12 비트 문자로의 전환은 60 년대에는 생각할 수 없었습니다. UTF-16이 너무 낭비 적이라고 여겨지기 때문에 오늘날 우리가 훨씬 덜 제한적 인 UTF-8이 인기가 있습니다. 10 비트 바이트는 생각할 수없는 수준이었으며, 3 자리 10 진수당 10 비트 인코딩은 시간 기술을 사용한 구현에 대한 영향에 대해 언급하지 않고 레지스터 및 메모리에서 전면 패널의 값을 검사 할 때 완전히 실용적이지 않습니다.
AProgrammer

2

역사적 사고 이외에, 우리가 8/16/32/64 비트를 사용해야하는 특별한 이유는 없습니다. 12/24/48/96 비트가 실제로 더 유용하다고 가정합니다.

텍스트를 처리 할 때 가상의 UTF-24를 사용하는 유니 코드는 UTF32보다 저렴합니다. 가상 UTF-12는 모든 단일 및 이중 바이트 UTF-8 문자를 12 비트로, 모든 트리플 및 쿼드 바이트 UTF-8 문자를 24 비트로 저장합니다 (범위는 2 ^ 20 자로 약간 줄어들지 만 여전히 4 배입니다) 관대하게 사용되는 것 이상); 두 가지 변형 만 있기 때문에 코드가 더 간단합니다.

부동 소수점의 경우 일반적으로 48 비트로 충분합니다. 96 비트는 80 비트 확장보다 훨씬 낫습니다. 24 비트는 그래픽에 유용합니다. 일부 그래픽 카드에서 지원하는 16 비트보다 훨씬 유용합니다. 48 비트 포인터는 256 테라 바이트를 처리 할 수 ​​있습니다.

유일한 단점은 12로 나누기가 바이트 위치를 계산해야하는 비트 배열입니다. 그것이 중요하다고 생각되면 하드웨어에서 12로 나누는 것이 매우 효율적으로 구현 될 수 있다고 확신합니다.


약간 주제가 아닌 UTF에 대한 흥미로운 점. 부동 소수점 바이트 (또는 비트) 크기는 메모리와 정밀도 사이의 끝없는 싸움입니다. 비트 배열에 대한 좋은 지적.
Andreas

1
흥미로운 생각이지만 이것이 질문에 대한 대답인지 확실하지 않습니다.

1
문제는 "8 비트가 왜 편리한 것으로 간주 되는가"였다. 확실히 "그렇지 않다"는 것은 그 질문에 대한 답입니다.
gnasher729

1
@ gnasher729 질문은 "왜 바이트 당 2 비트의 힘이 편리한 것으로 간주 됩니까?"라는 대답이었습니다 .
8bittree

2
의견은 긴 토론을위한 것이 아닙니다. 이 대화는 채팅 으로 이동 되었습니다 .
yannis

2

이는 32 비트 및 64 비트 아키텍처와 같이 8의 배수를 사용하는 일반적인 하드웨어 아키텍처로 인해 편리합니다. 이는 8 비트 데이터 저장 및 전송을 사용할 때 더 큰 효율성을 의미합니다.

"그러나 디자인의 경제성에 대한 고려는 단일 크기 또는 소수 또는 소수 (소수)와 관련된 크기를 기본 크기로 강하게 밀어 붙입니다.이 기본 크기는 아키텍처의 단어 크기가됩니다."

단어 (컴퓨터 아키텍처)

참조 : 바이트는 8 비트 이유의 역사는 무엇입니까?


5
나는 이것을 대답으로 받아들이지 않을 것이다. 내 질문은 사실상 표준이 8 비트가 아닌 2의 거듭 제곱이 편리한 이유입니다. 그리고 8 비트에 대한 역사는 5, 6, 7 비트가 실제적인 이유로 사용되고 있고, 7에서 8로가는 것은 "meh, why not"으로 동기를 부여합니다. 나는 2의 전력이 현재 시스템과의 호환성보다 더 많은 다른 소스를 읽는 느낌을 받았습니다. (실제로 8 비트는 7 비트 문자 세트 패리티를 부여했습니다.) Word는 2의 거듭 제곱의 이점을 얻는 것과 다른 점입니다. 즉, 계산에서 다중 대신 시프트를 사용할 수 있습니다.
Andreas

3
@RobertHarvey이 질문은 스위치 당 상태 수 (즉, 이진 대 삼진 이상)가 아니라 그룹화 할 스위치 수에 관한 것입니다. 질문에 대한 편집 내용을 참조하십시오.
8bittree

2
편집에 관해서 는 바이트 당 비트 수와 바이트 당 값 수 사이에 의미있는 구별없습니다 . 같은 것을 표현하는 두 가지 방법이 있습니다. 바이트가 보유 할 수있는 값의 수는 포함하는 비트 수에서 직접 따릅니다. 바이트는 8 비트이므로 최대 값을 보유 할 수 있습니다 2⁸-1.
Robert Harvey

2
논리적으로, 편리한 숫자 범위를 보유 할 수있는 바이트 크기를 선택합니다. ASCII는 7 비트이므로 로마자, 숫자, 문장 부호, 제어 문자 및 여러 특수 문자를 모두 인코딩하기에 충분한 128 개의 서로 다른 값을 제공합니다. 바이트는 텔레타이프에 적합한 총 8 비트의 오류 검사를 위해 7 개의 ASCII 비트와 1 개의 패리티 비트를 보유 할 수 있습니다. 우리는 그 이후로 그 크기를 바이트로 사용했습니다.
Robert Harvey

2
@JeremyKato 내가 언급 한 장치는 구형 (대부분 60-80 년대)이기 때문에 아마도 익숙하지 않을 것입니다. ASCII는 실제로 7 비트 인코딩입니다 (패리티는 표준의 일부가 아님). 그러나 귀하의 의견의 주요 부분은 아닙니다. 8 비트가 특히 편리한 이유가 있다는 것을 알고 있습니다. 귀하와 Robert Harvey가 누락 한 것은 문제가 8 비트가 아니라 일반적 으로 2 비트의 거듭 제곱에 대해 묻는 것 입니다.
8bittree

1

Wikipedia article for word 에 따르면 메모리 주소 지정과 관련된 계산이 훨씬 쉬워집니다.

다른 정도의 메모리는 다른 정밀도로 데이터 값을 저장하는 데 사용됩니다. 일반적으로 사용되는 크기는 일반적으로 주소 확인 단위 (바이트 또는 워드)의 2 배의 거듭 제곱입니다. 배열의 항목 색인을 항목의 주소로 변환하면 곱하기보다는 시프트 연산 만 필요합니다. 경우에 따라이 관계는 나누기 작업의 사용을 피할 수도 있습니다. 결과적으로, 대부분의 최신 컴퓨터 디자인은 워드 크기 (및 다른 피연산자 크기)를 사용하여 바이트 크기의 2 배입니다.


2
예, 바이트 크기의 2 배입니다. 바이트가 8 비트 여야하고 9, 12 또는 15가 아닌 고유 한 이유는 없습니다.
gnasher729

@ gnasher729, 9 또는 12 또는 15로 나누는 것보다 8 (또는 16 또는 32 또는 64)로 나누는 것이 훨씬 쉽습니다.
robert bristow-johnson

@ gnasher729 워드가 2의 제곱 비트이고 2의 제곱 바이트 인 경우 바이트가 2의
제곱

@vartec 기사와 인용문에 따르면 "일반적으로 사용되는 크기는 일반적으로 주소 해상도 단위 (바이트 또는 단어)의 2 배의 배수입니다"와 "대부분의 최신 컴퓨터 설계에는 단어 크기 (및 기타 피연산자 크기)가 있습니다 바이트 크기의 두 배입니다. " "워드 크기"는 비트가 아닌 바이트 단위로 측정됩니다. 비트 단위의 워드 크기에 대한 규칙은 기사에서 2의 거듭 제곱이어야합니다.
Andreas

@vartec : IF. 분명히 아무도 32 비트 워드와 12 비트 바이트를 가진 머신을 만들지 않을 것입니다. 그러나 48 비트 또는 96 비트 워드와 12 비트 바이트를 가진 머신에 대해서는 아무 것도 말하지 않습니다. 그리고 단어가 10 바이트 인 기계가있었습니다.
gnasher729

0

주소 공간과 밀접한 관련이 있습니다. 주소 버스에 1 비트를 더 추가하면 두 배의 메모리 위치를 지정할 수 있습니다. 따라서 추가 라인을 추가 할 때 전체 라인을 사용할 수도 있습니다.

이것은 1, 2, 4, 8, 16, 32 등의 자연스러운 진행으로 이어집니다.

생산 기술 수준에서 동일한 리소그래피 패턴을 반복하는 것도 쉽습니다. 즉, 두 배로하는 것입니다. 하나의 래치로 시작한 다음 패턴을 두 배로 늘리면 6, 10 또는 12가 아닌 8을 전달합니다.


1
이것은 바이트의 비트 수와 어떻게 관련이 있습니까? 32 비트 논리 AND가 36 또는 28 비트보다 구현하기 쉽다고 진지하게 주장하고 있습니까?
gnasher729

1
나는 그런 주장을하지 않았다. 내 제안은 트랜지스터가 저렴 해지고 IC가 더 작은 회로를 허용함에 따라 widrh에서 점진적으로 확장 된 초기 설계에서 비롯된 것입니다.
Martin Maat

1
생산 기술 수준에 대한 흥미로운 이론. 당신은 뭔가에있을 수 있습니다. 단락을 확장하거나 기본 사항을 설명하는 링크를 제공 할 수 있습니까?
Andreas

1
말도 안 돼요 예를 들어, 다양한 장소에서 모든 종류의 홀수 비트 크기가 필요한 그래픽 카드에서 모든 것이 정확히 1 비트가 아닌 필요한 크기로 수행됩니다. 어떤 작업에 h.264 디코더에 19 비트 정밀도가 필요한 경우 하드웨어는 20 또는 24 또는 32가 아닌 19 비트를 구현합니다. 실례합니다. 리소그래피 패턴을 조작하지 마십시오. 하드웨어를 정의한 다음 레이아웃을 생성하는 일부 소프트웨어를 통해 실행합니다.
gnasher729

1
@MartinMaat : 마케팅 + 표준화를 기술적 이유와 혼동하고 있습니다. 그리고 기술은 우리가 논의하고있는 것입니다.
gnasher729

0

단어 너비가 항상 2의 거듭 제곱 인 것은 아닙니다. 최근에는 숫자에 대해서는 32 비트 워드 너비를 가지고 있지만 opcode (48 비트 너비)에는 사용하지 않는 SHArC DSP에서 일부 코딩을 수행했습니다 .

워드 폭이 2의 거듭 제곱 인 이유는 단일 비트를 테스트 (또는 설정 또는 지우기 또는 토글)하거나 지정된 비트 수만큼 왼쪽 또는 오른쪽으로 이동 (또는 회전)하는 일부 명령어 때문일 수 있습니다. opcode에는 단일 비트의 위치 또는 이동할 비트 수를 지정하는 비트 필드가 있습니다. 워드 폭이 2의 거듭 제곱 인 경우,이 비트 필드에는 전체 워드를 포함하기 위해 로그 2 (word_width) 비트가 필요합니다 . 즉, 폭이 32 비트 인 워드는 이러한 연산을 위해 opcode에 5 비트 필드가 필요합니다. 단어의 너비가 33 비트 인 경우 6 개가 필요합니다. 그렇지 않으면 전체 단어를 처리 할 수 ​​없지만 단어의 너비가 64 비트 인 경우에도 마찬가지입니다.

opcode의 비트는 매우 귀중하므로 일반적으로 낭비하지는 않습니다. 그런 다음 단어를 2의 거듭 제곱으로 만드는 것이 합리적입니다.

바이트가 8 비트 인 이유는 ASCII 문자 (7 비트)를 보유 할 수있는 2의 가장 작은 제곱이기 때문입니다.


이것은 내 전문 분야는 아니지만 2 바이트 AND 워드 크기의 제곱의 유효한 이유처럼 들립니다. UB에 대해서도 걱정할 필요가 없다고 생각합니다. 시프트의 경우 33 비트에는 6 비트 opcode가 필요하지만 가능한 값의 약 절반 (0-32) 만 유용한 의미를 갖습니다. 동의하겠습니까?
Andreas

opcode는 시프트 카운트에 필요한 비트 필드보다 넓어야합니다. 바이트는 8 비트 인 단어 외에는 아무것도 아닙니다. 컴퓨터 하드웨어가 이유 경향이 8 또는 16 또는 32 또는 64 비트입니다 워드 크기를 사용하기 때문에 vartec에 의해 주어진 내가 위에서 준 이유와 이유입니다 (항상 그렇지 않다, 기존의 DSP56000 24 비트 단어가 있었다) : 묶음 단어의 비트 맵이 주어지고 특정 픽셀의 행과 열 번호가 주어지면, 픽셀을 테스트하거나 변경하기 위해 액세스 할 단어를 알기 위해 열 번호를 단어 너비로 나눕니다. 2의 거듭 제곱으로 나누는 것은 쉽습니다.
robert bristow-johnson 2012

"포장 단어의 비트 맵"이란 무엇입니까? HighColor가 해당 설명에 적합합니까?
Andreas

@ robertbristow-johnson : 상상력의 부족. 9 비트 바이트를 사용하면 RGBA에서 36 비트 단어, 1600 만 색상 대신 1,300 만 색상, RGB555 대신 RGB666 또는 저품질 색상을 위해 RGB565를 사용하여 모든 것이 잘 될 것입니다. ASCII는 라틴 확장까지 512자를 포함합니다.
gnasher729

@Andreas, 아니, 나는 두 가지 "색상"을 의미했다. 완전히 흰색 또는 완전히 검은 색입니다.
robert bristow-johnson
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.