가장 가까운 선행 store가 중요합니다
Load-Store Queue는 미완료 메모리 명령의 순서·주소·데이터를 추적하는 구조입니다. 단일 원형 큐는 설명 모델 중 하나이며 모든 CPU가 그 형태라는 뜻은 아닙니다. 아래는 같은 크기의 단일 값 접근을 가정한 자체 예제입니다.
1. store [0x100] = 0xBE (주소·값 준비) 2. store [?] = 0x5A (주소 미정) 3. load [0x100] (주소 준비)
2번 주소가 0x100이면 3번의 값은 0x5A, 다른 곳이면 1번의 0xBE입니다. 1번 주소가 일치한다는 이유만으로 2번을 무시할 수 없습니다. 주소가 같은 아무 store가 아니라 load보다 앞서면서 가장 가까운 store가 우선합니다. store 값이 아직 준비되지 않았다면 주소를 안다는 사실만으로 forwarding을 완료할 수도 없습니다.
주소 충돌 여부를 판별하는 memory disambiguation에는 실제 구현의 접근 크기·byte mask·주소 변환·권한도 중요합니다. 겹치는 일부 바이트, 서로 다른 가상 주소의 물리 alias, MMIO·원자적 명령은 위 단일 값 예제에 포함되지 않습니다.
기다리는 비용과 잘못 추측한 비용을 비교합니다
Stony Brook CSE 502 강의는 모든 선행 store 주소를 기다리는 방식, 충돌이 없다고 추측해 load를 먼저 실행하는 방식, 의존성 예측을 결합하는 방식을 비교합니다. 기다리면 불필요한 직렬화가 생길 수 있고 추측하면 나중에 순서 위반을 발견했을 때 복구가 필요합니다.
위 예에서 0xBE를 이미 사용한 뒤 2번 주소가 0x100으로 밝혀지면 load뿐 아니라 그 잘못된 값에 의존한 계산도 복구 대상입니다. 전부 flush할지 선택적으로 재실행할지는 설계의 문제입니다. 강의의 대안 비교를 특정 상용 코어가 그대로 구현했다는 증거로 쓰지 않습니다.
큐 할당·실행·commit·메모리 전달을 나눕니다
RISC-V BOOM LSU 문서는 별도 LDQ와 STQ를 사용합니다. decode에서 항목을 할당하고 store 주소·데이터의 준비 상태를 각각 추적합니다. load는 메모리 요청과 선행 store 주소 비교를 함께 시도하며 일치하면 요청을 취소하고 준비된 store 데이터를 전달합니다. 데이터가 없으면 load를 재우고 나중에 재시도합니다.
BOOM의 store는 commit 전까지 추측 상태이며 commit 뒤 프로그램 순서대로 STQ에서 메모리로 나갑니다. 늦게 확정된 store로 순서 위반을 찾으면 pipeline과 rename 상태를 복구합니다. 따라서 할당 순서, 실행 순서, commit 순서, cache로 나가는 시점을 하나의 “완료”로 뭉뚱그리면 안 됩니다.
큐 항목 할당 → 주소/데이터 준비 (서로 독립) → 실행 또는 대기/전달 → commit → store의 메모리 전달
주소 추적 모델과 실제 하드웨어 검증은 다릅니다
위 주소 예제의 두 분기와 선행 순서를 논리 검사하고 BOOM 문서 및 강의의 설명을 대조했습니다. BOOM RTL 시뮬레이션이나 실칩 실행은 하지 않았습니다. cache coherence, self-modifying code, ISA 메모리 모델과 보안·권한 검증은 LSQ 예제만으로 설명을 끝낼 수 없습니다.
출발 자료는 Todd Austin의 게시물과 보존 원고입니다. 원본 두 이미지를 재열람하거나 강의·BOOM의 도면을 복제하지 않았습니다.
English summary. A load must respect the youngest matching older store. Unknown addresses and unavailable store data are separate dependencies. Waiting, prediction and replay are design choices; BOOM's split queues and commit behavior are not universal CPU rules.