워드 어드레싱

Word addressing

컴퓨터 구조에서 단어 어드레싱은 컴퓨터의 메모리 주소가 기억의 단어를 고유하게 식별하는 것을 의미한다.주로 바이트 주소 지정과 대조적으로 사용되며, 여기서 주소는 바이트를 고유하게 식별한다.거의 모든 현대 컴퓨터 아키텍처들은 바이트 어드레싱을 사용하며, 단어 어드레싱은 대체로 역사적 관심사일 뿐이다.단어 주소 지정을 사용하는 컴퓨터를 워드 머신이라고도 한다.

바이트 및 워드 어드레싱으로 구성된 동일한 데이터를 보여주는 표

기본 사항

524,288 비트의19 메모리를 제공하는 컴퓨터를 생각해 보십시오.해당 메모리가 8비트 바이트를 사용하여 바이트 주소 지정이 가능한 플랫 주소 공간으로 배열되면 0에서 65,535까지의 유효한 주소가 65,536(2) 있으며16, 각각 8비트의 독립된 메모리를 나타낸다.대신 32비트 단어를 사용하여 워드 어드레스 가능한 플랫 어드레스 공간에 배치되는 경우 0부터 16,383까지의 유효한 어드레스가 16,384(2) 있으며14, 각각 독립적인 32비트를 나타낸다.

보다 일반적으로, 최소 주소 지정 가능 단위(MAU)는 특정 메모리 추상화의 속성이다.컴퓨터 내의 서로 다른 추상화는 동일한 기본 메모리를 나타내는 경우에도 서로 다른 MAU를 사용할 수 있다.예를 들어 컴퓨터는 명령 집합에 바이트 어드레싱이 있는 32비트 주소를 사용할 수 있지만 CPU의 캐시 일관성 시스템은 64바이트 캐시 라인의 세분화에서만 메모리와 함께 작동하여 특정 캐시 라인을 26비트 주소로만 식별하고 캐시의 오버헤드를 줄일 수 있다.

가상 메모리에 의해 이루어지는 주소 변환은 주소 공간의 구조와 너비에 영향을 주는 경우가 많지만, MAU를 변경하지는 않는다.

서로 다른 최소 주소 지정 가능 단위의 트레이드오프

최소 주소 지정 가능한 메모리 단위의 크기는 복잡한 절충을 가질 수 있다.더 큰 MAU를 사용하면 동일한 양의 메모리를 더 작은 주소로 덮을 수 있으며, 이는 프로그램의 메모리 요구 사항을 실질적으로 줄일 수 있다.그러나 더 작은 MAU를 사용하면 작은 데이터 항목으로 효율적으로 작업할 수 있다.

어떤 프로그램이 서양 점성술의 12가지 전통적인 기호들 중 하나를 저장하기를 원한다고 가정해보자.하나의 기호는 4비트로 저장할 수 있다.기호가 자체 MAU에 저장되면 바이트 어드레싱(50% 효율성)으로 4비트가 낭비되고, 32비트 워드 어드레싱(12.5% 효율성)으로 28비트가 낭비된다.기호가 다른 데이터와 함께 MAU로 "패킹"되는 경우, 읽고 쓰는 것이 상대적으로 더 비쌀 수 있다.예를 들어 다른 데이터가 포장된 MAU에 새 부호를 쓰려면 컴퓨터는 MAU의 현재 값을 읽고 적절한 비트만 덮어쓴 다음 새 값을 다시 저장해야 한다.프로그램이 다른 스레드를 MAU의 다른 데이터를 동시에 수정하도록 허용해야 하는 경우, 이것은 특히 비쌀 것이다.

더 일반적인 예는 텍스트 문자열이다.8비트 코드 포인트의 시퀀스로 UTF-8 및 ASCII 저장 문자열과 같은 공통 문자열 형식.바이트 어드레싱으로, 각 코드 포인트는 오버헤드 없이 독립적으로 주소 지정이 가능한 MAU에 배치할 수 있다.32비트 워드 어드레싱으로 각 코드 포인트를 별도의 MAU에 배치하면 메모리 사용량이 300% 증가하는데, 이는 대량의 텍스트로 작동하는 프로그램에서는 실행할 수 없다.인접한 코드 포인트를 한 단어로 포장하면 이러한 비용을 피할 수 있다.그러나 텍스트로 작업하는 많은 알고리즘은 코드 포인트를 독립적으로 다룰 수 있는 것을 선호한다. 이렇게 하려면 알고리즘은 단어 안에 문자의 오프셋도 저장하는 "넓은" 주소를 사용해야 한다.만약 이 넓은 주소를 프로그램의 기억장치 내에 다른 곳에 저장해야 한다면, 그것은 보통의 주소보다 더 많은 메모리를 요구할 수 있다.

전체 프로그램에 대한 이러한 효과를 평가하려면 크고 복잡한 페이지를 표시하는 웹 브라우저를 고려하십시오.브라우저의 메모리의 일부는 이미지나 텍스트와 같은 간단한 데이터를 저장하는 데 사용될 것이다; 브라우저는 가능한 한 효율적으로 이 데이터를 저장하는 것을 선택할 것 같고, MAU의 크기와 상관없이 대략 같은 양의 메모리를 점유할 것이다. 다른 메모리는 페이지에 있는 다양한 객체의 브라우저 모델을 나타낼 것이다. 그리고 이러한 오브젝트들은 브라우저의 모델을 나타낼 것이다.ts에는 서로에 대한 많은 참조, 이미지 및 텍스트 데이터 등이 포함될 것이다.이러한 개체를 저장하는 데 필요한 메모리 양은 컴퓨터의 주소 폭에 따라 크게 달라진다.

만약 프로그램의 모든 주소가 32비트라면, 이 웹 페이지는 약 10기가바이트의 메모리를 차지한다고 가정해 보자.

  • 웹브라우저가 32비트 주소와 바이트 어드레스 가능 메모리가 있는 컴퓨터에서 실행 중인 경우 주소 공간은 4기가바이트의 메모리를 커버하는데, 이는 불충분하다.브라우저는 이 페이지를 표시할 수 없거나, 일부 데이터를 느린 스토리지로 기회적으로 이동할 수 있어야 하며, 이는 성능을 상당히 저하시킬 것이다.
  • 웹 브라우저가 64비트 주소와 바이트 주소 메모리가 있는 컴퓨터에서 실행되고 있다면, 더 큰 주소를 저장하기 위해서는 훨씬 더 많은 메모리가 필요할 것이다.정확한 오버헤드는 10기가바이트 중 얼마나 많은 양이 단순한 데이터인지와 얼마나 많은 물체와 유사하고 참조가 밀집되어 있는지에 따라 달라지겠지만, 총 14기가바이트에 대해 40%의 수치는 신뢰할 수 없다.물론 이것은 64비트 주소 공간의 기능 내에 있다.그러나 브라우저는 대체 자원과 동일한 자원을 가정할 때 일반적으로 컴퓨터 내 메모리 캐시를 더 나쁘게 사용하고 위치도 더 나빠질 것이다.
  • 웹브라우저가 32비트 주소와 32비트 워드 어드레스 메모리가 있는 컴퓨터에서 실행되고 있다면, 그것은 부최적 패킹과 몇 개의 넓은 주소가 필요하기 때문에 추가 메모리가 필요할 것이다.브라우저가 가장 중요한 목적을 위해 패킹 및 비와이드 주소를 사용하고 브라우저가 최대 주소 범위인 16기가바이트 내에 편안히 맞기 때문에 이 영향은 상대적으로 작을 것 같다.그러나 이미지 및 텍스트에 대한 패킹 데이터의 광범위한 사용으로 인해 상당한 런타임 오버헤드가 발생할 수 있다.더 중요한 것은 16기가바이트는 상대적으로 낮은 한계로, 웹 페이지가 크게 늘어나면 이 컴퓨터는 주소 공간을 소진하고 바이트 애드레스 컴퓨터와 같은 어려움을 겪기 시작할 것이다.
  • 웹 브라우저가 64비트 주소와 32비트 워드 어드레스 메모리가 있는 컴퓨터에서 실행 중인 경우 위의 두 가지 런타임 오버헤드에 모두 시달릴 것이다. 즉, 더 큰 64비트 주소를 수용하기 위해서는 훨씬 많은 메모리가 필요하며, 로컬리티를 해치는 동시에 텍스트와 이미지의 광범위한 패킹 작업으로 인한 런타임 오버헤드가 발생한다.e. 워드 어드레싱이란 프로그램이 이론적으로 16EB 대신 최대 64EB의 메모리를 처리할 수 있다는 것을 의미하지만, 프로그램이 이 정도의 메모리를 필요로 하는 곳(그리고 실제로 어떤 실제 컴퓨터도 그것을 제공할 수 없기 때문에), 이것은 아무런 이점도 제공하지 않는다.

그러므로 단어 어드레싱은 컴퓨터가 주소 너비를 증가시키지 않고 그에 상응하는 메모리 사용량의 큰 증가를 야기하지 않고 실질적으로 더 많은 메모리를 다룰 수 있게 한다.그러나 이는 작업 세트 크기의 비교적 좁은 범위 내에서만 가치가 있으며, 애플리케이션에 따라 상당한 런타임 오버헤드를 도입할 수 있다.이미지, 텍스트, 파일 및 네트워크 트래픽과 같은 바이트 지향 데이터로 상대적으로 거의 작동하지 않는 프로그램은 가장 큰 혜택을 볼 수 있을 것이다.

하위 단어 액세스 및 광범위한 주소

워드 어드레싱을 사용하는 컴퓨터에서 실행 중인 프로그램은 더 작은 장치에 대한 액세스를 에뮬레이션하여 더 작은 메모리 단위로 여전히 작동할 수 있다.로드의 경우, 이것은 둘러싸인 단어를 로드한 다음 원하는 비트를 추출해야 한다.상점의 경우, 이것은 동봉된 단어를 로드하고, 새로운 값을 제자리에 옮기고, 원하는 비트를 덮어쓰고, 동봉된 단어를 저장해야 한다.

UTF-8 문자열의 연속 코드 포인트 4개를 32비트 단어로 묶어야 한다고 가정합시다.첫 번째 코드 포인트는 비트 0–7, 두 번째 8-15, 세 번째 16–23 및 네 번째 24–31을 점유할 수 있다(메모리가 바이트 주소 지정이 가능했다면, 이것은 약간 엔디안 바이트 순서가 될 것이다).

예를 특정 단어 애드레스 아키텍처에 너무 밀접하게 연결하지 않고 하위 단어 접근에 필요한 코드를 명확하게 설명하기 위해, 다음의 예들은 MIPS 어셈블리를 사용한다.실제로 MIPS는 8비트 및 16비트 값을 로딩 및 저장하는 직접적인 지원을 받는 바이트 애드레스 아키텍처지만, 예는 32비트 로드 및 저장소를 제공할 뿐이며, 32비트 워드 내의 오프셋은 주소와 별도로 저장해야 하는 것으로 간주한다.MIPS는 이러한 운영을 더욱 편리하게 할 수 있는 전문 시설이 없는 단순한 조립 언어이기 때문에 선택되었다.

프로그램이 세 번째 코드 포인트를 레지스터로 읽기를 원한다고 가정해 보십시오.r1등록되어 있는 주소의 말에서.r2명령 집합의 다른 지원이 없을 경우 프로그램은 전체 단어를 로드하고, 처음 두 개의 코드 포인트를 삭제하기 위해 16단계를오른쪽으로 이동해야 하며, 다음 네 번째 코드 포인트를 마스킹해야 한다.

ldw $r1, 0($r2) # 단어 전체 로드 srl $r1, $r1, 16 # 오른쪽 이동 16 및i $r1, $r1, 0xFF # 다른 코드 포인트에서 마스크 꺼짐

오프셋을 정적으로 알 수 없지만 대신 비트 오프셋이 레지스터에 저장된 경우r3, 약간 더 복잡한 접근법이 필요하다.

ldw $r1, 0($r2) # 전체 단어 srlv $r1, $r1, $r3 # 비트 오프셋을 기준으로 오른쪽으로 Shift 및 $r1, $r1, 0xFF # 다른 코드 포인트에서 마스크 꺼짐

대신 프로그램이 레지스터의 코드 포인트를 할당하려고 한다고 가정하십시오.r1의 주소에서 단어의 세 번째 코드 포인트까지.r2명령 집합의 다른 지원이 없을 경우 프로그램은 전체 단어를 로드하고, 해당 코드 포인트의 이전 값을 마스크하여 새 값을 제자리에 옮기고, 값을 병합하고, 전체 단어를 다시 저장해야 한다.

sll $r1, $r1, 16 # 새 값을 16lhi $r5, 0x00만큼 이동FF        # Construct a constant mask to select the third byte   nor  $r5, $r5, $zero    # Flip the mask so that it clears the third byte   ldw  $r4, 0($r2)        # Load the full word   and  $r4, $r5, $r4      # Clear the third byte from the word   or   $r4, $r4, $r1      # Merge the new value into the word   stw  $r4, 0($r2)        # Store the re몹시 더운.

다시, 오프셋이 대신 저장된 경우r3, 보다 복잡한 접근법이 필요하다.

sllv $r1, $r1, $r3 # 비트 오프셋 llo $5, 0x00로 새 값 이동FF        # Construct a constant mask to select a byte   sllv $r5, $r5, $r3      # Shift the mask left by the bit offset   nor  $r5, $r5, $zero    # Flip the mask so that it clears the selected byte   ldw  $r4, 0($r2)        # Load the full word   and  $r4, $r5, $r4      # Clear the selected byte from the word   or   $r4, $r4, $r1      # Merge thestw $r4, 0($r2)이라는 단어의 새로운 값 # 결과를 전체 단어로 저장

이 코드 순서는 다른 스레드가 단어의 다른 바이트를 동시에 수정할 수 없다고 가정한다.동시 수정이 가능한 경우 수정사항 중 하나가 손실될 수 있다.이 문제를 해결하려면 마지막 몇 가지 지시사항을 원자 비교 교환 루프로 전환하여 동시 수정하면 단순히 새로운 값으로 연산을 반복하게 된다.이 경우에는 기억장벽이 필요하지 않다.

단어 주소의 쌍과 단어 내의 오프셋을 넓은 주소(지방 주소 또는 지방 포인터라고도 한다)라고 한다.(이것은 배열의 한계와 같은 다른 종류의 보충 데이터를 저장하기 위해 넓은 주소의 다른 사용과 혼동되어서는 안 된다.)저장된 오프셋은 비트 오프셋 또는 바이트 오프셋일 수 있다.위의 코드 시퀀스는 오프셋을 시프트 카운트로 사용하기 때문에 비트로 표시함으로써 이득을 얻는다. 바이트 선택을 직접 지원하는 아키텍처는 바이트 오프셋만 저장하는 것을 선호할 수 있다.

이러한 코드 시퀀스에서는 추가 오프셋을 기본 주소와 함께 저장해야 하므로 주소의 전체 스토리지 요구사항이 실질적으로 두 배가 된다.주로 주소 자체가 접근을 더 효율적으로 만들기 위해 다른 데이터로 채워지지 않기 때문에, 이것은 워드 머신에서 항상 사실이 아니다.예를 들어 Cray X1은 64비트 단어를 사용하지만 주소는 32비트 밖에 되지 않는다. 주소를 메모리에 저장하면 자체 워드에 저장되므로 바이트 오프셋을 단어의 상위 32비트에 배치할 수 있다.그 시스템에 넓은 주소를 사용하는 비효율성은 단지 이 오프셋을 조작하고 단어 안에 바이트를 추출하여 삽입하기 위한 추가적인 논리일 뿐이다; 그것은 기억 사용의 영향이 없다.

관련개념

컴퓨터의 최소 주소 지정 가능 단위는 반드시 컴퓨터 명령어 세트의 최소 메모리 액세스 크기와 같지는 않다.예를 들어, 컴퓨터는 단일 바이트를 직접 읽거나 쓰도록 지시하지 않고 바이트 어드레싱을 사용할 수 있다.프로그램은 위의 코드 시퀀스 예시와 같이 비트 조작으로 소프트웨어에서 이러한 작업을 모방할 것으로 예상된다.이는 DEC 알파와 크레용 X1과 같은 32비트 슈퍼컴퓨터 또는 미니컴퓨터의 계승자로 설계된 64비트 컴퓨터 아키텍처에서 비교적 흔하다.

C 표준은 포인터가 주소의 일반적인 표현을 가질 것으로 예상된다고 명시한다.또한 C는 비트 필드를 제외한 모든 개체에 포인터를 형성할 수 있도록 허용한다. 여기에는 바이트 배열의 각 개별 요소가 포함된다.단어 어드레싱을 사용하는 컴퓨터의 C 컴파일러는 종종 크기에 따라 다른 유형의 포인터에 대해 다른 표현을 사용한다.단어를 채울 수 있을 만큼 큰 유형의 포인터는 간단한 주소인 반면, 포인터는 다음과 같은 주소가 될 것이다.char*또는void*넓은 포인터가 될 것이다: 한 단어의 주소와 그 단어의 바이트 오프셋의 쌍.따라서 포인터 유형 간 변환은 반드시 사소한 작업이 아니며 잘못 수행될 경우 정보가 손실될 수 있다.

왜냐하면 C의 크기 때문이다.struct그것에 대한 포인터의 표현을 결정할 때 항상 알려진 것은 아니다.struct, 위의 규칙을 신뢰성 있게 적용하는 것은 불가능하다.컴파일러가 시작점을 정렬해야 할 수 있음struct보다 효율적인 포인터 표현을 사용할 수 있도록.

예

  • 평균자책 1103은 36비트 단어로 어드레싱을 사용한다.주소 0-1023만 랜덤 액세스 메모리를 가리킨다. 다른 주소들은 매핑되지 않았거나 드럼 메모리를 가리킨다.
  • PDP-10은 36비트 워드와 18비트 주소의 워드 어드레싱을 사용한다.
  • 1980년대와 1990년대의 대부분의 크레용 슈퍼컴퓨터는 64비트 단어로 어드레싱을 사용한다.크레용-1과 크레용 X-MP는 24비트 주소를 사용하는 반면 다른 대부분은 32비트 주소를 사용한다.
  • Cray X1은 64비트 주소의 바이트 어드레싱을 사용한다.64비트 이하의 메모리 액세스를 직접 지원하지 않으며, 이러한 액세스는 소프트웨어에서 에뮬레이션해야 한다.X1용 C 컴파일러는 16비트 액세스 에뮬레이션을 지원하는 최초의 Cray 컴파일러였다.[1]
  • DEC Alpha는 64비트 주소의 바이트 어드레싱을 사용한다.초기 알파 프로세서는 8비트 및 16비트 메모리 액세스에 대한 직접적인 지원을 제공하지 않으며, 프로그램은 포함된 64비트 워드를 로딩한 다음 바이트를 별도로 추출하여 바이트를 로드해야 한다.Alpha는 바이트 어드레싱을 사용하기 때문에, 이 오프셋은 여전히 주소의 최소 중요 비트로 표시되며(넓은 어드레스로 따로 표시하지 않고), Alpha는 부하와 저장되지 않은 명령어를 편리하게 제공한다.ldq_u그리고stq_u)은 이러한 비트를 무시하고 포함된 정렬된 단어를 로드하고 저장한다.[2]아키텍처(BWX)에 대한 이후 바이트 워드 확장은 알파 21164a를 시작으로 8비트 및 16비트 로드와 저장소를 추가했다.[3]다시 말하지만, 이 확장은 Alpha가 항상 바이트 어드레싱을 사용했기 때문에 심각한 소프트웨어 비호환성 없이 가능했다.

참고 항목

참조

  1. ^ 테리 그레이츠크, 크레용 주식회사Cray X1 컴파일러 과제(및 해결 방법)
  2. ^ "The Alpha AXP, part 8: Memory access, storing bytes and words and unaligned data". 16 August 2017.
  3. ^ "Alpha: The History in Facts and Comments - Alpha 21164 (EV5, EV56) and 21164PC (PCA56, PCA57)".