hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
Z/아키텍처 레지스터
각 프로세서에는 다음 레지스터가 있다.
각 CPU에는 16개의 32비트 접근 레지스터가 있다. AR 모드에서 실행되는 프로그램이 레지스터 1-15를 기본 레지스터 또는 주소를 포함하는 레지스터 피연산자로 지정하면, CPU는 주소 변환 중에 관련 접근 레지스터를 사용한다.
64비트 BEAR는 명령어의 순차적 실행을 중단시킨 마지막 명령어의 주소를 포함한다. 인터럽트는 실제 주소 272 (11016)의 이중 워드에 BEAR를 저장한다. 분기 실행 후 BEAR는 분기의 주소가 아닌 실행의 주소를 포함한다.
16개의 64비트 제어 레지스터는 PSW에 포함된 정보를 제외하고 CPU의 제어 및 상태를 제공한다. 이들은 이전 S/390 프로세서의 ESA/390 제어 레지스터의 진화적인 개선 사항이다. 특정 기능에 따라 어떤 필드가 의존적인지에 대한 자세한 내용은 작동 원칙을 참조한다.
z/아키텍처는 제어 레지스터를 32비트에서 64비트로 확장하므로, 비트 번호 지정이 ESA/390과 다르다.
Z/아키텍처 레지스터
FPC 레지스터에는 인터럽트 마스크 (IM), 상태 플래그 (SF), 데이터 예외 코드 (DXC), 십진 반올림 모드 (DRM), 이진 반올림 모드 (BRM)가 포함된다. AFP 레지스터 (추가 부동소수점 레지스터) 제어 비트인 제어 레지스터 0의 비트 13이 1인 경우에만 인터럽트가 FPC 레지스터에 DXC를 저장한다. 또한 DXC의 개별 비트가 일반적으로 의미를 가지지만, 프로그램은 일반적으로 개별 비트를 조회하는 대신 8비트 정수로 처리해야 한다.
각 CPU에는 16개의 64비트 부동소수점 레지스터가 있었으며, FP0–15는 VR0–15의 비트 0–63을 차지한다.
각 CPU에는 16개의 64비트 범용 레지스터가 있으며, 이는 누산기, 기본 레지스터 및 인덱스 레지스터로 사용된다. "그랑데"로 지정된 명령어는 모든 64비트에서 작동하며, 확장 즉시 기능을 통해 추가된 일부 명령어는 레지스터 내의 모든 하프워드 또는 워드에서 작동한다. 다른 대부분의 명령어는 비트 0–31을 변경하거나 사용하지 않는다.
Z/아키텍처 레지스터
접두사 레지스터는 실제 주소를 절대 주소로 변환하는 데 사용된다. z/아키텍처 모드에서 PSA는 2페이지 (8KiB)이다. 비트 0–32와 51–63은 항상 0이다. 실제 주소의 비트 0–50이 0이면 접두사 레지스터의 비트 0–50으로 대체된다. 실제 주소의 비트 0–50이 접두사 레지스터의 비트 0–50과 같으면 0으로 대체된다.
PSW는 명령어 주소와 현재 CPU에서 실행 중인 프로그램의 상태를 반영하는 다른 필드를 포함한다. 프로그램의 상태는 제어 레지스터의 내용에도 영향을 받는다.
각 CPU에는 32개의 128비트 벡터 레지스터가 있다. VR0–15의 비트 0–63은 또한 FPR0–15이다. 벡터 레지스터는 16개의 8비트 필드, 8개의 16비트 필드, 4개의 32비트 필드, 2개의 64비트 필드 또는 1개의 128비트 필드를 포함할 수 있다.
Z/아키텍처 메모리
IBM은 z/아키텍처의 메모리를 메인 스토리지와 확장 스토리지로 분류한다.
메인 스토리지는 8비트 바이트 (옥텟) 단위로 주소 지정되며, 더 큰 정렬된 그룹화가 있다.
하프워드
2바이트
16비트
워드
4바이트
32비트
더블워드
8바이트
64비트
쿼드워드
16바이트
128비트
페이지
4096바이트
z/아키텍처는 0부터 264-1까지의 실제 및 가상 주소를 허용하지만, 엔지니어링 제약으로 인해 현재 및 계획된 모델은 훨씬 적은 용량으로 제한된다.
확장 스토리지는 4KiB 블록 단위로 주소 지정되며, 블록 번호는 0부터 232까지이다.
Z/아키텍처 주소 지정
z/아키텍처에는 세 가지 유형의 메인 스토리지 주소가 있다.
가상 주소
애플리케이션 프로그램이 보는 주소. 주소 공간에 대한 오프셋이며 페이지 및 세그먼트 테이블을 통한 주소 변환이 적용된다.
실제 주소
주소 변환 후의 주소, 또는 변환이 꺼진 상태에서 OS 구성 요소가 보는 주소. 접두사가 적용된다.
절대 주소
접두사 레지스터를 통해 처음 두 페이지에 대한 참조에 접두사 지정 후의 주소.
z/아키텍처는 ESA와 동일한 잘린 주소 지정 방식을 사용하며, 몇 가지 추가 명령어 형식이 있다. ESA와 마찬가지로 AR 모드에서는 0이 아닌 각 기본 레지스터가 주소 공간을 지정하는 기본 레지스터와 연결된다. 명령어에 따라 주소는 여러 다른 형식으로 제공될 수 있다.
R
주소가 범용 레지스터에 포함됨
상대
현재 명령어로부터의 부호 있는 16비트 하프워드 오프셋
상대 롱
현재 명령어로부터의 부호 있는 32비트 하프워드 오프셋
RS
기본 레지스터와 12비트 변위
RX
기본 레지스터, 인덱스 레지스터 및 12비트 변위
Z/아키텍처 주소 지정
Y
기본 레지스터, 인덱스 레지스터 및 20비트 변위; 비공식적으로 "Yonder"로 알려짐
S/370-XA 및 ESA에서 지원하는 두 가지 주소 지정 모드 외에도, z/아키텍처는 64비트 가상 주소를 가진 확장 주소 지정 모드를 제공한다. 주소 지정 모드는 PSW의 EA (비트 31) 및 BA (비트 32) 비트에 의해 제어된다. 유효한 조합은 다음과 같다.
z/아키텍처는 PSW의 비트 5, DAT 모드 비트, 비트 16–17, 주소 공간 제어 (AS) 비트에 의해 제어되는 4가지 가상 변환 모드를 지원한다.
기본 공간 모드
모든 스토리지 참조는 기본 주소 공간의 변환 테이블을 사용한다.
액세스 레지스터 모드
모든 스토리지 참조는 기본 레지스터와 관련된 액세스 레지스터에 의해 지정된 변환 테이블을 사용한다.
보조 공간 모드
모든 스토리지 참조는 보조 주소 공간의 변환 테이블을 사용한다.
홈 공간 모드
모든 스토리지 참조는 홈 주소 공간의 변환 테이블을 사용한다.
Z/아키텍처 운영체제 지원
IBM의 운영체제인 z/OS, z/VSE, z/TPF, z/VM은 각각 MVS, VSE, 트랜잭션 처리 기능 (TPF), VM의 버전으로 z/아키텍처를 지원한다. z/OS, z/VSE, z/VM의 이전 버전은 32비트 시스템을 계속 지원했다. z/OS 버전 1.6 이상, z/VSE 버전 4 이상, z/VM 버전 5 이상은 z/아키텍처를 필요로 한다.
리눅스도 리눅스 온 IBM Z와 함께 z/아키텍처를 지원한다.
z/아키텍처는 서로 다른 주소 크기를 사용하는 경우에도 여러 개의 동시 운영 체제와 애플리케이션을 실행할 수 있도록 지원한다. 이를 통해 소프트웨어 개발자는 애플리케이션 및 데이터 구조에 가장 유리한 주소 크기를 선택할 수 있다.
Z/아키텍처 운영체제 지원
2009년 7월 7일, IBM은 새로운 운영 체제 버전 발표와 함께 아키텍처 레벨 세트 4 (ALS 4)가 존재하며 System z10 및 이후 머신에 구현된다고 암시적으로 밝혔다. ALS 4는 LOADxx에서도 ARCHLVL 3으로 지정되어 있으며, 이전 z900, z800, z990, z890, System z9는 ARCHLVL 2로 지정되었다. System z10의 이전 발표에서는 단순히 z/아키텍처에 일부 추가 기능, 즉 50개 이상의 새로운 기계 명령어, 1MB 페이지 프레임, 하드웨어 십진 부동소수점 장치(HDFU)를 구현한다고 명시했다.
z/OS를 포함한 z/아키텍처용 대부분의 운영체제는 효율성과 호환성 때문에 각 가상 주소 공간의 첫 2GB(31비트 주소, 즉 231개의 주소 지정 가능한 바이트)로 코드 실행을 제한하며, 이는 아키텍처적 제한 때문이 아니다. Linux on IBM Z는 코드가 64비트 주소 범위 내에서 실행될 수 있도록 한다.
각 z/OS 주소 공간은 64비트 주소 공간이라고 불리며, 크기는 16 엑사바이트이다.
Z/아키텍처 운영체제 지원
자바 프로그래밍 언어의 z/OS 구현은 예외이다. z/OS 가상 메모리 구현은 여러 2GB 주소 공간을 지원하여 2GB 이상의 동시 상주 프로그램 코드를 허용한다.
데이터 전용 공간은 읽고 쓸 수는 있지만 실행 가능한 코드로 사용할 수 없는 메모리 영역이다. (다른 최신 프로세서의 NX 비트와 유사하다.)
기본적으로 z/아키텍처 메모리 공간은 64비트 포인터로 인덱싱되어 실행 중인 프로그램에 최대 16엑사바이트의 메모리를 표시할 수 있다.
16 엑사바이트 이상의 데이터 주소 공간이 필요한 애플리케이션은 추가 주소 공간 또는 데이터 전용 공간을 사용하여 확장된 주소 지정 기술을 사용할 수 있다. 사용자 프로그램에 사용 가능한 데이터 전용 공간은 다음과 같다.
이러한 공간은 프로그램이 생성할 수 있는 가상 스토리지 영역이라는 점에서 비슷하며, 최대 2 기가바이트에 달할 수 있다. 주소 공간과 달리 데이터 공간 또는 하이퍼 공간은 사용자 데이터만 포함하며, 시스템 제어 블록이나 공통 영역을 포함하지 않는다. 프로그램 코드는 데이터 공간이나 하이퍼 공간에서 실행될 수 없다.
Z/아키텍처 운영체제 지원
데이터 공간은 바이트 주소 지정이 가능한 반면, 하이퍼 공간은 페이지 주소 지정이 가능하다는 점에서 다르다.
전통적으로 IBM 메인프레임 메모리는 바이트 주소 지정이 가능했다. 이러한 종류의 메모리는 "중앙 스토리지"라고 불린다. IBM 메인프레임 프로세서는 1980년대와 1990년대 대부분 동안 또 다른 종류의 메모리인 확장 스토리지를 지원했다. 이는 1985년 IBM 3090 고급 메인프레임 시리즈와 함께 처음 도입되었다.
확장 스토리지는 4KB 페이지 주소 지정이 가능하다. 애플리케이션이 확장 스토리지의 데이터에 액세스하려면 먼저 중앙 스토리지로 이동해야 한다. 마찬가지로 중앙 스토리지에서 확장 스토리지로의 데이터 이동은 4KB 페이지 단위로 수행된다. 초기에는 페이지 이동이 상대적으로 비용이 많이 드는 명령어, 즉 페이징 서브시스템 코드를 사용하여 수행되었다.
중앙 스토리지와 확장 스토리지 간의 단일 및 그룹 페이지 이동 오버헤드는 MVPG (페이지 이동) 명령어 및 ADMF (비동기 데이터 이동기 기능) 기능의 도입으로 줄어들었다.
Z/아키텍처 운영체제 지원
MVPG 명령어와 ADMF는 일반적으로 z/OS 또는 z/VM (및 ACP?)의 미들웨어에 의해 확장 스토리지의 데이터에 액세스하기 위해 명시적으로 호출된다. 일부 사용 사례는 다음과 같다.
1990년대 중반까지 중앙 스토리지와 확장 스토리지는 프로세서의 물리적으로 다른 메모리 영역이었다. 1990년대 중반부터 중앙 스토리지와 확장 스토리지는 단순히 기본 프로세서 메모리에 대한 할당 선택이었다.
이러한 선택은 특정 예상 사용 사례를 기반으로 이루어졌다.
예를 들어, 하이퍼배치 기능(하이퍼 공간에 액세스하기 위해 MVPG 명령어를 사용함)에는 확장 스토리지가 필요하다.
위에 언급된 하이퍼 공간 및 페이징 사례 외에도 확장 스토리지를 사용하는 다른 용도가 있다.
z/OS는 확장 스토리지에 대한 지원을 제거했다. z/OS의 모든 메모리는 이제 중앙 스토리지이다. z/VM 6.4는 확장 스토리지의 모든 사용에 대한 지원을 중단하라는 방향성 선언을 이행한다.
IBM은 MVPG를 "단일 페이지를 이동하며 페이지 이동이 완료될 때까지 중앙 프로세서는 다른 명령어를 실행할 수 없습니다."라고 설명했다.
Z/아키텍처 운영체제 지원
MVPG 메인프레임 명령어 (MoVe PaGe, opcode X'B254')는 MVCL (MoVe Character Long) 명령어와 비교되었으며, 둘 다 단일 명령어로 주 메모리 내에서 256바이트 이상을 이동할 수 있다. 이 명령어들은 원자성의 정의를 준수하지 않지만, 문서화된 타이밍 및 비중첩 제한 내에서 단일 명령어로 사용될 수 있다.:Note 8, page 7-27
주 메모리 내에서 256바이트 이상을 이동해야 하는 필요성은 역사적으로 소프트웨어 (MVC 루프), 1970년 System/370 발표와 함께 도입된 MVCL, 그리고 1989년 IBM이 특허를 내고 발표한 MVPG를 통해 해결되었으며, 각각 장점이 있다.
1992년에 도입된 ADMF (비동기 데이터 이동기 기능)는 단일 페이지로 제한되는 MVPG (페이지 이동) 명령어의 기능을 넘어 중앙 스토리지와 확장 스토리지 사이에서 페이지 그룹을 이동할 수 있다.
IOSADMF라는 매크로 명령어는 "ADMF의 직접적이고 저수준 사용"을 피하는 API로 묘사되었으며, 하이퍼 공간에서 데이터를 읽거나 쓸 수 있다. 하이퍼 공간은 DSPSERV CREATE를 사용하여 생성된다.
재진입성을 제공하기 위해 IOSADMF는 "List form" 및 "Execute form"과 함께 사용된다.
Z/아키텍처 비IBM 구현
플랫폼 솔루션즈 주식회사(PSI)는 이전에 z/아키텍처와 호환되는 아이테니엄 기반 서버를 판매했다. IBM은 2008년 7월에 PSI를 인수했으며, PSI 시스템은 더 이상 제공되지 않는다. FLEX-ES, zPDT 및 Hercules emulator도 z/아키텍처를 구현한다. 히타치 메인프레임은 최신 버전의 VOS3 운영 체제를 실행하며, 몇 가지 64비트 명령어를 포함한 ESA/390과 히타치 고유의 CPU 명령어를 구현한다. 히타치는 2002년 출시된 z900-G2/z800 CPU에 대해 IBM과 공식적으로 협력했지만, 히타치의 기기는 z/아키텍처와 호환되지 않는다.
Z/아키텍처 각주
z
《z/Architecture Principles of Operation》 (PDF) Fourteen판. IBM. May 2022. SA22-7832-13. 2024년 6월 28일에 확인함.
IBM 시스템/360 아키텍처
IBM 시스템/360 아키텍처(IBM System/360 architecture)는 명령어 집합 아키텍처를 포함하지만 이에 국한되지 않는 S/360 메인프레임 컴퓨터 라인 전체의 모델 독립적인 아키텍처이다. 아키텍처의 요소들은 IBM 시스템/360 동작 원리 및 IBM 시스템/360 I/O 인터페이스 채널-제어 장치 원본 장비 제조업체 정보 매뉴얼에 문서화되어 있다.
IBM 시스템/360 아키텍처 특징
시스템/360 아키텍처는 다음 기능을 제공한다:
모든 시스템/360 모델(아래 참조, 모델 20 제외)에 존재하는 고정 소수점 이진 산술 및 논리 명령어를 포함하는 표준 명령어 집합.
십진수 산술 명령어를 추가하는 상용 명령어 집합은 일부 모델에서 선택 사항이며, 부동소수점 명령어를 추가하는 과학 명령어 집합도 마찬가지이다. 범용 명령어 집합은 위의 모든 것을 포함하며 저장 보호 명령어도 포함하며 일부 모델에서는 표준이다.
모델 44는 데이터 획득 및 실시간 처리를 위한 몇 가지 고유한 명령어를 제공하며 저장 대 저장 명령어는 없다. 그러나 IBM은 누락된 명령어를 범프 저장소에서 실행하고 시뮬레이션하는 상업용 명령어 집합 기능을 제공했다.
모델 20은 표준 명령어 집합의 간소화된 버전을 제공하며, 하프워드(16비트) 명령어만 있는 8개의 범용 레지스터로 제한되며, 상업용 명령어 집합과 입출력용 고유 명령어가 포함되어 있다.
모델 67에는 32비트 주소 및 "동적 주소 변환"을 처리하는 일부 명령어가 포함되어 있으며, 가상 메모리를 제공하는 추가 특권 명령어도 포함되어 있다.
IBM 시스템/360 아키텍처 메모리
시스템/360의 메모리('저장')는 8비트 바이트 단위로 주소 지정된다. 다양한 명령어는 '하프워드'(2바이트), '풀워드'(4바이트), '더블워드'(8바이트), '쿼드 워드'(16바이트) 및 2048바이트 저장 블록과 같은 더 큰 단위에서 작동하며, 단위의 가장 왼쪽(가장 낮은 주소)을 지정한다. 하프워드, 풀워드, 더블워드 또는 쿼드워드 내에서 낮은 번호의 바이트는 높은 번호의 바이트보다 더 중요하다. 이는 때때로 빅 엔디언으로 불린다. 이러한 단위의 많은 용도는 해당 경계에 정렬되어야 한다. 이 문서에서 한정되지 않은 용어 '워드'는 '풀워드'를 의미한다.
시스템/360의 원래 아키텍처는 최대 224 = 16,777,216바이트의 메모리를 제공했다. 후기 모델 67은 아키텍처를 확장하여 최대 232 = 4,294,967,296바이트의 가상 메모리를 허용했다.
IBM 시스템/360 아키텍처 주소 지정
시스템/360은 유니백 III의 주소 지정 방식과 유사한 잘린 주소 지정을 사용한다. 즉, 명령어는 완전한 주소를 포함하지 않고, 대신 베이스 레지스터와 베이스 레지스터의 주소로부터의 양수 오프셋을 지정한다. 시스템/360의 경우 베이스 주소는 15개 범용 레지스터 중 하나에 포함된다. 시프트와 같은 일부 명령어에서는 주소가 아닌 32비트 값에 대해 동일한 계산이 수행된다.
IBM 시스템/360 아키텍처 데이터 형식
S/360 아키텍처는 문자, 정수, 십진 정수 및 16진수 부동 소수점 숫자에 대한 형식을 정의한다. 문자 및 정수 명령어는 필수이지만, 십진수 및 부동 소수점 명령어는 십진수 산술 및 부동소수점 기능의 일부이다.
팩 십진수 숫자는 1에서 16개의 8비트 바이트로 저장되며, 홀수 개의 십진수 숫자와 4비트 부호가 뒤따른다. 16진수 A, C, E, F의 부호 값은 양수이고, 16진수 B, D의 부호 값은 음수이다. 16진수 A-F의 숫자 값과 0-9의 부호 값은 유효하지 않지만, PACK 및 UNPK 명령어는 유효성을 검사하지 않는다.
부동 소수점 숫자는 구형 모델에서 풀워드 또는 더블워드 값으로만 저장된다. 360/85 및 360/195에서는 쿼드워드로 저장되는 확장 정밀도 부동 소수점 숫자도 있다. 세 가지 형식 모두에서 비트 0은 부호이고 비트 0-7은 특성(지수, 64로 편향됨)이다. 비트 8-31(8-63)은 16진수 소수 부분이다. 확장 정밀도의 경우, 하위 더블워드는 자체 부호와 특성을 가지며, 이는 입력 시 무시되고 출력 시 생성된다.
IBM 시스템/360 아키텍처 명령어 형식
S/360의 명령어는 2, 4 또는 6바이트 길이를 가지며, 0바이트에 연산 코드가 있다. 명령어는 다음 형식 중 하나를 가진다:
명령어는 메모리에서 2바이트 경계에 있어야 한다. 따라서 명령어 주소의 최하위 비트는 항상 0이다.
IBM 시스템/360 아키텍처 프로그램 상태 워드 (PSW)
프로그램 상태 워드 (PSW)(pp. 71–72)는 현재 실행 중인 프로그램에 대한 다양한 제어 정보를 담고 있다. 64비트 PSW는 (다른 것들 중에서도) 현재 실행 중인 명령어의 주소, 조건 코드 및 인터럽트 마스크를 설명한다.
프로그램 상태 워드 로드 (LPSW)는 프로그램 모드, 보호 키 및 다음에 실행될 명령어의 주소를 포함하여 프로그램 상태 워드(PSW)를 로드하는 특권 명령어이다. LPSW는 종종 인터럽트 클래스와 관련된 "이전" PSW를 로드하여 인터럽트에서 "반환"하는 데 사용된다. 다른 특권 명령어(예: SSM, STNSM, STOSM, SPKA 등)는 인터럽트를 발생시키거나 PSW를 로드하지 않고 PSW의 하위 집합을 조작하는 데 사용할 수 있으며, 하나의 비특권 명령어(SPM)는 프로그램 마스크를 조작하는 데 사용할 수 있다.
IBM 시스템/360 아키텍처 인터럽트 시스템
아키텍처(pp. 77–83)는 5가지 종류의 인터럽트를 정의한다. 인터럽트는 프로그램 상태를 자동으로 변경하는 메커니즘이며, 동기 및 비동기 이벤트 모두에 사용된다.
S/360의 각 인터럽트 클래스에는 두 개의 저장 필드가 할당된다. 이전 PSW 더블워드와 새 PSW 더블워드이다. 프로세서는 인터럽트 코드가 삽입된 PSW를 이전 PSW 위치에 저장한 다음 새 PSW 위치에서 PSW를 로드한다. 이는 일반적으로 명령어 주소를 교체하여 분기를 발생시키고, (선택적으로) PSW 내의 다른 필드를 설정하거나 재설정하여 모드 변경을 발생시킨다.
S/360 아키텍처는 각 인터럽트 클래스에 우선 순위를 정의하지만, 이는 두 인터럽트가 동시에 발생할 때만 관련이 있다. 인터럽트 루틴은 초기 인터럽트의 다른 발생을 포함하여 다른 활성화된 인터럽트에 의해 중단될 수 있다. 이러한 이유로 "1단계" 인터럽트 핸들러의 경우 머신 체크 마스크 비트를 제외한 모든 마스크 비트를 0으로 지정하는 것이 일반적이다. "2단계" 인터럽트 핸들러는 일반적으로 스택형 인터럽트(동일한 인터럽트 클래스의 인터럽트가 여러 번 발생하는 경우)를 위해 설계된다.
IBM 시스템/360 아키텍처 인터럽트 시스템
I/O 인터럽트는 채널 프로그램이 완료될 때, PCI 비트가 설정된 CCW를 가져온 후, 그리고 장치, 제어 장치 또는 채널에 의해 감지된 비동기 이벤트(예: 기계적 이동 완료)에 대해 발생한다. 시스템은 장치 주소를 인터럽트 코드에 저장하고 채널 상태를 위치 64 ('40'X)의 CSW에 저장한다.
프로그램 인터럽트(pp. 16,79–80.1)는 명령어가 15개의 예외 중 하나를 만났을 때 발생한다. 그러나 예외에 해당하는 프로그램 마스크 비트가 0이면 해당 예외에 대한 인터럽트는 발생하지 않는다.
360/65,(p. 12) 360/67(p. 46) 및 360/85(p. 12)에서는 보호 예외 및 주소 지정 예외 인터럽트가 부정확할 수 있으며, 이 경우 명령어 길이 코드 0을 저장한다.
인터럽트 코드는 다음 중 하나일 수 있다.
IBM 시스템/360 아키텍처 인터럽트 시스템
관리자 호출 인터럽트는 관리자 호출 명령어의 결과로 발생한다. 시스템은 SVC 명령어의 비트 8-15를 인터럽트 코드로 저장한다.
외부 인터럽트는 특정 비동기 이벤트의 결과로 발생한다. 외부 이전 PSW의 비트 16-24는 0으로 설정되고, 비트 24-31 중 하나 이상이 1로 설정된다.
머신 체크 인터럽트는 채널 또는 CPU와 관련된 다른 종류의 인터럽트로 보고될 수 없는 특이한 상태를 보고하기 위해 발생한다. 머신 체크를 유발하는 가장 중요한 조건은 레지스터나 저장 장치에서 발견되는 패리티 오류와 같은 하드웨어 오류이지만, 일부 모델에서는 덜 심각한 상태를 보고하는 데 사용될 수 있다. 인터럽트 코드와 '80'x(128진수) 스캔아웃 영역에 저장된 데이터는 모델에 따라 다르다.
IBM 시스템/360 아키텍처 입출력
이 문서는 CPU 관점에서 I/O를 설명한다. 채널 케이블 또는 커넥터는 별도의 문서인 버스 앤 태그에서 다루며, 요약은 다른 곳에 있고 자세한 내용은 IBM 문헌 및 FIPS PUB 60-2에서 찾을 수 있다.
I/O는 개념적으로 별도의 프로세서인 채널에 의해 수행된다. 채널은 자체 명령어 집합을 가지며, CPU에서 실행되는 프로그램과는 독립적으로 메모리에 접근한다. 소형 모델(360/50까지)에서는 단일 마이크로코드 엔진이 CPU 프로그램과 채널 프로그램을 모두 실행한다. 대형 모델에서는 채널이 별도의 캐비닛에 있으며 자체 메모리 인터페이스를 갖는다. 채널은 여러 서브채널을 포함할 수 있으며, 각 서브채널은 개별 채널 프로그램의 상태를 포함한다. 채널 프로그램을 동시에 가질 수 없는 여러 장치와 관련된 서브채널을 공유라고 하며, 단일 장치를 나타내는 서브채널을 비공유라고 한다.
S/360에는 세 가지 유형의 채널이 있다:
IBM 시스템/360 아키텍처 입출력
블록 멀티플렉서 채널은 여러 채널 프로그램을 동시에 실행할 수 있지만, 한 번에 하나만 활성화될 수 있다. 제어 장치는 채널 명령 완료 시 일시 중단을 요청할 수 있으며 나중에 재개를 요청할 수 있다. 이는 데이터 전송 완료 후 기계적 지연이 있는 장치(예: 이동 헤드 DASD의 탐색)를 위한 것이다. 블록 멀티플렉서 채널은 시스템/360 아키텍처에 늦게 추가되었다. 초기 시스템에는 바이트 멀티플렉서 채널과 선택기 채널만 있었다. 블록 멀티플렉서 채널은 모델 85 및 195에서만 선택적 기능이다. 블록 멀티플렉서 채널은 후기 시스템/370 컴퓨터에서도 사용할 수 있다.
개념적으로 주변 장비는 '제어 장치'를 통해 S/360에 연결되며, 제어 장치는 다시 채널을 통해 연결된다. 그러나 아키텍처는 제어 장치가 물리적으로 분리되어야 한다고 요구하지 않으며, 실제로는 제어 장치가 제어하는 장치와 통합되는 경우도 있다. 마찬가지로 아키텍처는 채널이 프로세서와 물리적으로 분리되어야 한다고 요구하지 않으며, 소형 S/360 모델(360/50까지)은 프로세서에서 사이클을 훔치는 통합 채널을 가지고 있다.
IBM 시스템/360 아키텍처 입출력
주변 장치는 16비트 주소로 주소 지정된다.(p. 89) 'cua' 또는 'cuu'로 불리며, 이 문서에서는 'cuu'라는 용어를 사용한다. 상위 8비트는 0에서 6까지의 채널을 식별하고, 하위 8비트는 해당 채널의 장치를 식별한다. 장치는 여러 'cuu' 주소를 가질 수 있다.
제어 장치에는 주소 "캡처" 범위가 할당된다. 예를 들어, CU는 20-2F 또는 40-7F 범위를 할당받을 수 있다. 이는 여러 제어 장치를 채널에 연결하고 우선순위를 지정하는 데 도움이 된다. 예를 들어, 채널에는 20-2F, 50-5F, 80-8F에 세 개의 디스크 제어 장치가 있을 수 있다. 캡처된 모든 주소에 할당된 물리적 장치가 있을 필요는 없다. 각 제어 장치는 채널에서 높은 우선순위 또는 낮은 우선순위로 표시된다.
IBM 시스템/360 아키텍처 입출력
장치 선택은 채널에서 각 제어 장치로 물리적으로 연결된 순서대로 진행된다. 체인 끝에서 선택 프로세스는 채널 방향으로 역순으로 계속된다. 선택이 채널로 돌아가면 어떤 제어 장치도 명령을 수락하지 않았으므로 SIO는 조건 코드 3을 반환한다. 높은 우선순위로 표시된 제어 장치는 나가는 CUU가 범위 내에 있는지 확인한다. 그렇다면 I/O가 처리된다. 그렇지 않다면 선택은 다음 나가는 CU로 전달된다. 낮은 우선순위로 표시된 제어 장치는 들어오는 (반환하는) CUU가 범위 내에 있는지 확인한다. 그렇다면 I/O가 처리된다. 그렇지 않다면 선택은 다음 들어오는 CU(또는 채널)로 전달된다. 세 개의 제어 장치를 채널에 연결하는 것은 물리적으로 -A-B-C일 수 있으며, 모두 높은 우선순위로 표시된 경우 우선순위는 ABC가 된다. 모두 낮은 우선순위로 표시된 경우 우선순위는 CBA가 된다. B가 높은 우선순위로 표시되고 AC가 낮은 우선순위로 표시된 경우 순서는 BCA가 된다. 이러한 추론을 확장하면 N개의 컨트롤러 중 첫 번째는 우선순위 1(높음) 또는 2N-1(낮음)이 되고, 두 번째는 우선순위 2 또는 2N-2, 세 번째는 우선순위 3 또는 2N-3 등이 된다. 마지막으로 물리적으로 연결된 것은 항상 우선순위 N이 된다.
IBM 시스템/360 아키텍처 입출력
I/O에 예약된 세 개의 저장 필드가 있다. 더블워드 I/O 이전 PSW, 더블워드 I/O 새 PSW 및 풀워드 '채널 주소 워드' (CAW)이다. I/O를 수행하려면 일반적으로 다음이 필요하다.
채널 프로그램은 일련의 '채널 제어 워드' (CCW)로 구성되며 서로 연결되어 있다(아래 참조). 일반적으로 채널은 연속적인 더블워드에서 CCW를 가져오지만, 제어 장치는 채널이 CCW를 건너뛰도록 지시할 수 있으며 '채널 내 전송' (TIC) CCW는 채널이 새 위치에서 CCW를 가져오기 시작하도록 지시할 수 있다.
채널 명령을 완료하는 몇 가지 정의된 방법이 있다. 이 중 일부는 채널이 CCW를 계속 가져올 수 있도록 허용하는 반면, 다른 일부는 채널 프로그램을 종료한다. 일반적으로 CCW에 체인 명령 비트가 설정되어 있지 않고 TIC가 아니면 명령이 완료될 때 채널은 I/O 작업을 종료하고 I/O 인터럽트를 발생시킨다. 제어 장치의 특정 상태 비트는 체인을 억제한다.
IBM 시스템/360 아키텍처 입출력
명령이 완료되는 가장 일반적인 방법은 체인 데이터가 설정되지 않았을 때 카운트가 소진되는 경우와 제어 장치가 더 이상 데이터 전송을 하지 말아야 함을 알리는 경우이다. Suppress-Length-Indication (SLI)이 설정되지 않고 이 중 하나가 다른 하나 없이 발생하면 체인이 허용되지 않는다. 체인을 억제하는 가장 일반적인 상황은 단위 예외 및 단위 검사이다. 그러나 단위 검사와 상태 수정자의 조합은 체인을 억제하지 않는다. 오히려 채널이 명령 재시도를 수행하여 동일한 CCW를 재처리하게 한다.
I/O 작업 완료 시 CPU로 전송되는 인터럽트 신호 외에도, 채널은 작업 종료 없이 채널 프로그램이 실행 중일 때 CPU에 프로그램 제어 인터럽트(PCI)를 보낼 수 있으며, I/O 완료 인터럽트 후에 지연된 장치 종료 인터럽트를 보낼 수 있다.
이러한 조건은 채널에 의해 감지되어 CSW에 표시된다.
IBM 시스템/360 아키텍처 입출력
프로그램 제어 인터럽트는 채널이 PCI 비트가 설정된 CCW를 가져왔음을 나타낸다. 채널은 계속 처리하며, 이 인터럽트는 단순히 채널의 진행 상황을 CPU에 알린다. 프로그램 제어 인터럽트의 사용 예는 내용 감시의 "프로그램 가져오기" 기능에서 찾을 수 있다. 이를 통해 제어 프로그램은 제어/재배치 레코드가 읽혔음을 통보받는다. 이 레코드가 메인 저장소에 완전히 읽혔는지 확인하기 위해 제어 프로그램에 남아있는 몇 안 되는 "비활성화된 비트 스핀" 중 하나가 시작된다. 스핀이 만족되면 제어/재배치 레코드가 메인 저장소에 완전히 들어왔고 바로 이전 텍스트 레코드가 재배치될 수 있음을 나타낸다. 재배치 후 NOP CCW는 TIC로 변경되고 채널 프로그램은 계속된다. 이런 방식으로 전체 로드 모듈이 하나의 EXCP를 사용하여, 그리고 가능하면 디스크 드라이브의 한 번의 회전만으로 읽고 재배치될 수 있다. PCI는 또한 통신 처리 액세스 방식 버퍼 관리에도 적용된다.
IBM 시스템/360 아키텍처 입출력
이러한 조건은 제어 장치 또는 장치에 의해 채널에 제시된다. 어떤 경우에는 채널에 의해 처리되고 다른 경우에는 CSW에 표시된다. 제어 장치에 의해 감지된 조건과 장치에 의해 감지된 조건 사이에는 구분이 없다.
주의는 진행 중인 채널 프로그램과 관련 없는 특이한 상태를 나타낸다. 이는 종종 입력을 요청하는 것과 같은 어떤 종류의 조작자 동작을 나타내며, 이 경우 CPU는 추가 정보를 추론할 수 있는 읽기 유형 명령, 가장 일반적으로 감지 명령(04h)을 발행하여 응답한다. 주의는 특수 조건이며, 특정 운영 체제 지원이 필요하고, 운영 체제는 반드시 항목 수가 제한된 특수 주의 테이블을 가지고 있다.
상태 수정자 (SM)는 다음 세 가지 특이한 조건 중 하나를 나타낸다.
지원하지 않는 장치에 테스트 I/O 명령을 발행했다.
바쁨 상태는 장치 대신 제어 장치를 참조한다.
장치가 CCW를 건너뛰어야 하는 상태를 감지했다. 상태 수정자가 가능한 명령이 있는 CCW는 일반적으로 명령 체인을 지정하며, 이 경우 SM은 채널에 의해 처리되며 인터럽트를 발생시키지 않는다.
SM이 발생하는 일반적인 채널 프로그램은 다음과 같다.
IBM 시스템/360 아키텍처 입출력
여기서 TIC는 장치가 SM을 발생시켜 성공적인 검색을 나타낼 때까지 채널이 검색을 다시 가져오도록 한다.
풀워드 '채널 주소 워드'(p. 99) (CAW)는 4비트 저장 보호 키와 시작할 채널 프로그램의 24비트 주소를 포함한다.
'채널 명령 워드'는 다음을 포함하는 더블워드이다.
하위 2 또는 4비트는 채널이 수행하는 6가지 유형의 작업을 결정한다.(pp. 100,105) 인코딩은 다음과 같다.
위 표에서 상위 6 또는 4비트, 즉 수정자 비트 M의 의미는 연결된 I/O 장치 유형에 따라 다르다. 예를 들어, DASD CKD CCW를 참조하라. 8개 비트 모두 관련 제어 장치(또는 그 기능적 등가물)로 전송되어 해석된다.
제어는 장치나 제어 장치의 상태를 변경하는 데 사용되며, 종종 되감기, 탐색과 같은 기계적 움직임과 관련된다.
감지는 장치 상태를 설명하는 데이터를 읽는 데 사용된다. 가장 중요한 경우는 명령이 단위 검사로 종료될 때 특정 원인은 감지를 수행하고 반환된 데이터를 검사해야만 확인할 수 있다는 것이다. 수정자 비트가 모두 0인 감지 명령은 항상 유효하다.
아키텍처의 주목할 만한 편차는 DASD가 제어를 사용하는 대신 예약 및 해제에 Sense 명령 코드를 사용한다는 점이다.
CCW의 플래그는 실행 및 종료 방식에 영향을 미친다.
'채널 상태 워드' (CSW)(pp. 113–121)는 I/O 인터럽트와 관련된 데이터를 제공한다.
S/360에는 4개의 I/O 명령어가 있다: Start I/O (SIO), Test I/O (TIO), Halt I/O (HIO) 및 Test Channel (TCH). 이 네 가지 모두 특권 명령어이므로 문제 상태에서 사용하면 특권 연산 프로그램 인터럽트를 발생시킨다. B1 (베이스) 및 D1 (변위) 필드는 cuu (채널 및 장치 번호)를 계산하는 데 사용되며, 명령어의 비트 8-15는 사용되지 않으며 S/370과의 호환성을 위해 0이어야 한다.
SIO는 CAW에 있는 저장 보호 키를 사용하여 CAW가 가리키는 채널 프로그램을 시작하려고 시도한다.
TIO는 채널과 장치의 상태를 테스트한다. 또한 CSW를 저장할 수도 있으며, 이 경우 조건 코드 1로 완료된다.
HIO는 활성 채널 프로그램을 종료하려고 시도한다. 또한 CSW를 저장할 수도 있으며, 이 경우 조건 코드 1로 완료된다.
TCH는 채널의 상태를 테스트한다. 활성 채널 프로그램의 상태에 영향을 미치지 않으며 CSW를 저장하지 않는다.
IBM 시스템/360 아키텍처 운영자 제어
시스템/360 아키텍처는 여러 공통 기능의 존재를 명시했지만, 구현 수단을 명시하지 않았다. 이를 통해 IBM은 다른 프로세서에서 기능 및 값 선택에 다이얼, 키보드, 푸시버튼, 롤러, CRT의 이미지 또는 텍스트와 같은 다양한 물리적 수단을 사용할 수 있었다. '키' 또는 '스위치'에 대한 모든 언급은 예를 들어 라이트펜 선택, 동등한 키보드 시퀀스에 적용되는 것으로 읽어야 한다.
IPL 기능의 일부로 운영자는 12비트 장치 주소를 지정하는 수단을 갖는다. 일반적으로 운영자 제어 도면에서와 같이 세 개의 다이얼로 지정된다. 운영자가 '로드' 기능을 선택하면 시스템은 '시스템 재설정'을 수행하고, 선택된 장치에 Read IPL 채널 명령을 보내 위치 0-23으로 24바이트를 읽어들이고, 채널이 위치 8에서 'CCW'를 가져오기 시작하도록 한다. 그 효과는 채널이 위치 0에서 24의 길이, 0의 주소, 명령 체인 + 길이 표시 억제를 포함하는 플래그를 가진 CCW를 가져온 것과 같다. 작업 완료 시 시스템은 위치 2의 하프워드에 I/O 주소를 저장하고 위치 0에서 PSW를 로드한다.
IBM 시스템/360 아키텍처 운영자 제어
초기 프로그램 로딩은 일반적으로 테이프, 카드 판독기 또는 디스크 드라이브에서 수행된다. 일반적으로 운영 체제는 디스크 드라이브에서 로드되었으며, 테이프나 카드에서 IPL은 진단용으로 또는 새 컴퓨터에 운영 체제를 설치할 때만 사용되었다.
IBM 시스템/360 아키텍처 선택적 기능
일부 모델, 예를 들어 S/360-85,에서는 일부 문제 상태 명령어에 대한 정렬 요구 사항이 완화되었다. 이 기능을 끄는 메커니즘은 없으며, 해당 명령어에서 프로그램 검사 유형 6(정렬)을 받는 데 의존하는 프로그램은 수정해야 한다.
십진수 산술 기능은 팩 십진수 데이터에서 작동하는 명령어를 제공한다. 팩 십진수 숫자는 1-31개의 십진수 숫자 뒤에 4비트 부호가 온다. PACK 및 UNPACK을 제외한 모든 십진수 산술 명령어는 숫자가 0-9 범위를 벗어나거나 부호가 A-F 범위를 벗어날 경우 데이터 예외를 발생시킨다.
'직접 제어' 기능은 6개의 외부 신호선과 저장소로/부터의 8비트 데이터 경로를 제공한다.
부동 소수점 산술 기능은 4개의 64비트 부동 소수점 레지스터와 32비트 및 64비트 16진 부동 소수점 숫자에서 작동하는 명령어를 제공한다. 360/85 및 360/195는 128비트 확장 정밀도 부동 소수점 숫자도 지원한다.
IBM 시스템/360 아키텍처 선택적 기능
인터벌 타이머 기능(p. 17.1)이 설치된 경우, 프로세서는 위치 80 ('50'X)의 워드를 일정한 간격으로 감소시킨다. 아키텍처는 간격을 지정하지 않지만, 1초당 300회 비트 23에서 1을 뺀 것처럼 보이도록 값을 빼야 한다고 요구한다. 소형 모델은 AC 전원 공급 장치와 동일한 주파수(50Hz 또는 60Hz)로 감소시켰지만, 대형 모델은 고해상도 타이머 기능을 가지고 있었다. 타이머가 0이 되면 프로세서는 외부 인터럽트를 발생시킨다.
'다중 시스템 작동'은 직접 제어, 직접 주소 재배치(프리픽싱)와 같은 다중 프로세서 시스템을 지원하는 기능 세트이다.
저장소 보호 기능(pp. 17-17.1)이 설치된 경우, 모든 2,048바이트 저장 블록에는 4비트 저장 키가 연결되며, CPU 또는 I/O 채널이 해당 블록의 주소에 저장할 때 해당 키가 확인된다. CPU 또는 채널 키가 0이면 확인이 비활성화된다. 0이 아닌 CPU 또는 채널 키는 일치하는 키가 있는 블록에만 데이터를 저장할 수 있도록 허용한다.
IBM 시스템/360 아키텍처 선택적 기능
저장소 보호는 결함 있는 애플리케이션이 운영 체제 또는 다른 애플리케이션에 속한 저장소를 덮어쓰는 것을 방지하는 데 사용되었다. 이를 통해 생산과 함께 테스트를 수행할 수 있었다. 키의 길이가 4비트에 불과했기 때문에 동시에 실행할 수 있는 다른 애플리케이션의 최대 수는 15개였다.
일부 모델에서 사용할 수 있는 추가 옵션은 페치 보호였다. 이를 통해 운영 체제는 블록이 저장 뿐만 아니라 페치로부터도 보호되도록 지정할 수 있었다.
IBM 시스템/360 아키텍처 편차 및 확장
시스템/360 모델 20은 근본적으로 다르므로 S/360으로 간주해서는 안 된다.
시스템/360 모델 44에는 특정 명령어가 없지만, 숨겨진 메모리에서 누락된 명령어를 시뮬레이션할 수 있는 기능이 있어 표준 S/360 운영 체제 및 애플리케이션을 사용할 수 있었다.
일부 모델은 에뮬레이션 명령어, 페이징 등 아키텍처를 확장한 기능을 가지고 있으며, 일부 모델은 아키텍처에서 사소한 편차를 보인다. 예를 들면 다음과 같다.
일부 편차는 S/370 아키텍처 기능의 프로토타입 역할을 했다.
IBM 시스템/360 아키텍처 각주
S360
《IBM System/360 Principles of Operation》. Systems Reference Library Eigh판. IBM. September 1968. A22-6821-7.
오라클 호출 인터페이스
컴퓨팅에서 오라클 호출 인터페이스(Oracle Call Interface, OCI)는 C 언어 소프트웨어 API 집합으로 오라클 데이터베이스에 대한 인터페이스를 제공한다.
OCI는 시스템 시작 및 종료와 같은 특정 데이터베이스 관리 작업을 수행할 뿐만 아니라 PL/SQL 또는 SQL을 사용하여 데이터를 쿼리, 액세스 및 조작하기 위한 절차적 API를 제공한다. 오라클의 문서화되지 않은 사용자 프로그래밍 인터페이스(UPI)를 기반으로 하는 OCI 라이브러리는 애플리케이션과 저수준 데이터베이스 네트워크 프로토콜 간의 "통역자" 역할을 한다.
오라클 호출 인터페이스 역사
오라클은 1988년 오라클 데이터베이스 버전 6에서 OCI(HLI, 호스트 언어 인터페이스라는 이름으로)를 처음 출시했다. HLI(및 이후 OCI)가 UPI의 래퍼로 작동했기 때문에 원래 명명 규칙은 기반이 된 UPI 호출과 매우 유사했다. 예를 들어, 롤백 문: UPI의 호출 upirol은 OCI에서 orol이 되었다.
이후 1997년에 출시된 오라클8에서 OCI 호출은 더 설명적인 이름을 얻었다. orol은 OCITransRollback이 되었다. 2007년에 출시된 11g를 포함하여 모든 OCI 버전에서 후속 개선이 이루어졌다. 오라클 (기업)은 OCI가 "오라클 데이터베이스의 모든 SQL 문이 OCI로 실행될 만큼 신뢰할 수 있다"고 주장한다.
오라클 호출 인터페이스 구현
OCI는 오라클 외에도 여러 다른 공급업체에서 OCI API와 호환되는 자체 라이브러리를 구현할 정도로 인기가 많다. 현재 ANTs 데이터 서버(ADS), EnterpriseDB, Linter SQL RDBMS용 OCI 호환 라이브러리가 존재한다.
오라클 호출 인터페이스 OCI 기반 라이브러리
OCI를 기반으로 하는 여러 라이브러리는 다음과 같다:
OCI API의 복잡성으로 인해 다음과 같은 사용하기 더 쉬운 여러 OCI 래퍼 라이브러리도 존재한다.
손상통제수술
손상통제수술은 신체 기관을 바로잡는 최종적인 수술 한 번을 진행하기보다는 일단 환자를 살리는 데 초점을 두는 수술을 일컫는다. 주로 세 단계를 포함하는데 1. 초기 개복(Initial laparotomy)을 통해 급한 부분을 수술하기 2. 봉합을 하지 않은 상태로 중환자실에서 회복하기 3. 회복된 후 최종적인 수술을 진행하기다. 손상통제수술은 죽음의 외상 3요소(대사성 산증, 저체온증, 응고 장애)를 처치한다.
옥승철
옥승철(1988년 10월 24일 ~ )은 대한민국 서울특별시 출생의 미술가이다. 회화, 조각 등 전통적 매체뿐만 아니라 현실과 가상, 미술과 비미술의 경계를 넘나들며 작업한다.
옥승철 생애
1988년 서울특별시에서 태어나 중앙대학교 서양화과를 졸업했다. 밴드 ADOY의 앨범 커버를 디자인하기도 했다.
옥승철 스타일
옥승철은 디지털 이미지와 전통 회화 기법을 결합하여 독창적인 작품 세계를 구축한다. 특히 애니메이션과 만화 캐릭터의 클로즈업 이미지를 재조합하여 새로운 얼굴을 만들어내는 것이 그의 주요 작업 방식이다. 컴퓨터를 활용해 이미지를 재구성하고 이를 캔버스에 옮겨 담는 과정은 고해상도 출력물처럼 매끈하고 정교한 결과물을 만들어낸다. 옥승철은 포스트 디지털 시대의 관점에서 원본성의 문제를 다루며, 디지털 이미지를 원본 삼아 회화, 조각 등 전통 매체뿐 아니라 현실과 가상, 미술과 비미술의 경계를 넘나들며 작업한다.
옥승철 전시
옥승철은 국내외에서 활발하게 전시 활동을 하고 있다. 주요 개인전으로는 갤러리 기체에서 열린 《UN ORIGINAL》(2018), 《JPEG SUPPLY》(2020), 《Trophy》(2023) 등이 있으며, 아트선재센터에서 《2022 아트선재 프로젝트 #2: 크리에이트 아웃라인즈》(2022)를 개최했다. 2024년에는 일본 도쿄 파르코 뮤지엄(PARCO MUSEUM)에서 《플라나리아》, 스페인 발렌시아 투스데이 투 프라이데이(TUESDAY TO FRIDAY)에서 《CAMOUFLAGE》 개인전을 열었다. 2025년 8월 15일부터 10월 26일까지 롯데뮤지엄에서 첫 대규모 개인전 《옥승철: 프로토타입(PROTOTYPE)》이 개최될 예정이다.
블록 파티 뮤직 앤 아트 페스티벌
블록 파티 뮤직 앤 아트 페스티벌(영어: Block Party Music and Art Festival)은 매년 대한민국 서울특별시 해방촌 일대에서 열리는 록 페스티벌이다. 해방촌의 다양한 라이브 장소와 술집, 음식점에서 진행된다.
블록 파티는 2022년에 시작되었으며, 음악 공연 이외에도 드래그 쇼, 스탠드업 코미디, 레슬링, 퍼포먼스 아트, 마술 등의 프로그램이 있다. 2023년에는 10개의 장소가, 2024년에는 12개의 장소가 페스티벌과 함께 했다.
페스티벌의 기획자 제이미 핀(Jamie Finn)은 2024년을 마지막 페스티벌이라고 공지했으며, 2025년에는 부산에서 4개의 장소와 함께 한 비슷한 형태의 디베이저 페스티벌(Debaser Festival)을 개최하기도 했다. 그러나 주최측은 공지를 번복하며 2025년에도 블록 파티가 진행될 것임을 알렸다.
아멜-마르두크
아멜-마르두크(Amel-Marduk, 바빌론 쐐기 문자: , "마르두크의 사람"이라는 뜻), 아윌-마르두크 또는 에윌-므로닥 (고대 히브리어: אֱוִיל מְרֹדַךְ ʾĔwīl Mərōḏaḵ)은 기원전 562년부터 기원전 560년에 폐위되어 살해될 때까지 통치했던 신바빌로니아 제국의 세 번째 황제였다. 네부카드네자르 2세(r. 기원전 605~562년)의 후계자였다. 현존하는 쐐기 문자 자료가 적어 아멜-마르두크의 통치와 왕으로서의 행적은 거의 알려져 있지 않다.
아멜-마르두크는 원래 나부-슘-우킨이라는 이름이었으며, 태자이자 후계자로 지명되었을 당시 네부카드네자르의 살아있는 최연장자 아들도 아니었다. 아멜-마르두크가 아버지에 의해 후계자로 지명된 이유는 불분명한데, 특히 둘 사이에 불화가 있었으며 심지어 아멜-마르두크가 아버지가 살아있을 때 왕위를 차지하려 시도했을 가능성도 있기 때문이다. 음모 이후, 아멜-마르두크는 포로로 잡힌 유다의 왕 여호야긴과 함께 투옥되었을 가능성이 있다. 나부-슘-우킨은 석방되면서 자신의 이름을 아멜-마르두크로 바꾸었는데, 아마도 신 마르두크에 대한 존경심 때문이었을 것이다.
아멜-마르두크
아멜-마르두크는 여호야긴을 투옥하고 37년 뒤에 석방한 것으로 유명하다. 이외에도 바빌론과 아마도 다른 곳에서도 일부 건축 작업을 수행한 것으로 알려져 있지만, 그 범위는 불분명하다. 바빌론 사람들은 그의 통치를 싫어했던 것으로 보이며, 그의 통치 이후의 바빌론 문헌들은 그를 무능하다고 묘사한다. 기원전 560년에 매형인 네리그리사르에게 폐위되고 살해당했으며, 네리그리사르는 이후 왕으로 통치했다.
아멜-마르두크 배경
아멜-마르두크는 아버지인 네부카드네자르 2세(r. 기원전 605~562년)의 후계자였다. 네부카드네자르의 계승은 어려움이 많았고, 왕의 말년은 정치적 불안정에 시달렸던 것으로 보인다. 네부카드네자르가 이미 40년간 통치한 후 그의 통치 말기에 작성된 한 비문에서 왕은 자신이 태어나기 전부터 신들에 의해 왕으로 선택되었다고 주장한다. 이러한 방식으로 신성한 정당성을 강조하는 것은 보통 찬탈자들이나 의도된 후계자와 정치적 문제가 있을 때만 이루어졌다. 네부카드네자르가 수십 년 동안 왕이었고, 그의 전임자의 정당한 상속자였다는 점을 고려하면 첫 번째 옵션은 가능성이 낮다.
아멜-마르두크 배경
아멜-마르두크는 아버지의 통치 기간 동안 후계자로 선택되었으며, 기원전 566년에 태자로 기록되어 있다. 아멜-마르두크는 네부카드네자르의 장남이 아니었다. 네부카드네자르의 다른 아들인 마르두크-나딘-아히는 네부카드네자르의 통치 3년차(기원전 602/601년)에 자신의 영지를 책임지는 성인으로 기록되어 있다. 아멜-마르두크가 훨씬 늦게 기록된 점을 고려하면, 마르두크-나딘-아히가 네부카드네자르의 장남이자 정당한 후계자였을 가능성이 높으며, 이는 마르두크-나딘-아히가 기원전 563년까지 살아있었다는 기록이 남아 있기 때문에 아멜-마르두크가 선택된 이유를 설명한다. 게다가 네부카드네자르와 아멜-마르두크 사이의 불화 증거는 그가 후계자로 선택된 것이 더욱 있을 법하지 않게 만든다. 한 문서에서 네부카드네자르와 아멜-마르두크는 모두 어떤 음모에 연루되어 있으며, 둘 중 한 명은 신전과 백성에 대한 나쁜 행동으로 고발되었다.
아멜-마르두크 배경
그들은 [네부]카드네자르에 대해 생각했다 [. . .] 그의 생명은 그들에 의해 소중히 여겨지지 않았다 [. . . 바빌론] 백성들은 아멜-마르두크에게 말하기를, [. . .] . . . "[[[에사길라]]]와 바빌론의 보물에 대해 [. . ."] 그들은 위대한 신들의 도시들을 언급했다 [. . .] 그의 마음은 아들과 딸에 대해 용납하지 않을 것이다 [. . .] 가족과 부족은 [아니다 . . .] 그의 마음속에. 가득 찬 모든 것 [. . .] 그의 생각은 [에사길라와 바빌론의] 안녕에 대한 것이 아니었다 [. . .], 그는 경청하는 귀로 거룩한 문으로 갔다 [. . .] 주님들의 주님께 기도했다 [. . .] 그는 마르두크에게 비통하게 울부짖었다, 신들은 [..] 그의 기도를 듣고 [. . .].
이 비문에는 성소의 모독과 주민 착취에 대한 비난이 담겨 있지만, 누구에게 향하는지는 불분명하다. 이는 바빌론 왕의 두 가지 주요 책임에서 실패한 것이다. 고발된 사람은 나중에 바빌론의 국가 신인 마르두크에게 울고 기도했다고 진술된다.
아멜-마르두크 배경
네부카드네자르 통치 말기의 또 다른 문서에는 투옥된 네부카드네자르의 아들인 나부-슘-우킨( Nabû-šum-ukīn)의 기도가 담겨 있는데, 그는 자신에 대한 음모 때문에 투옥되었다고 진술한다. 기원후 5세기에서 7세기의 미드라시 문서인 레위기 랍바에 따르면, 아멜-마르두크는 바빌론 관리들 중 일부가 네부카드네자르가 자리를 비운 동안 그를 왕으로 선포했기 때문에 아버지에 의해 포로로 잡힌 유다 왕 여호야긴 (여호아하스라고도 알려짐)과 함께 투옥되었다. 아시리아 학자 어빙 핀켈은 1999년에 나부-슘-우킨이 아멜-마르두크와 동일인물이며, 그는 자신이 기도했던 신에 대한 존경심으로 석방되자 "마르두크의 사람"으로 이름을 바꾸었다고 주장했다. 핀켈의 결론은 다른 학자들에게 설득력 있는 것으로 받아들여졌으며, 이전 문헌도 같은 사건과 관련될 가능성을 설명한다. 12세기에 작성되었을 가능성이 있는 히브리어 역사서인 예라흐미엘 연대기는 아멜-마르두크가 네부카드네자르의 장남이었으나, 그의 아버지가 '젊은 네부카드네자르'(다른 어떤 자료에서도 증명되지 않은 가상의 인물)를 선호하여 그를 제쳐두었고, 그리하여 젊은 네부카드네자르가 죽을 때까지 여호야긴과 함께 투옥되었다가 그 후 아멜-마르두크가 왕이 되었다고 잘못 기술하고 있다.
이용 가능한 증거를 고려할 때, 네부카드네자르는 아멜-마르두크를 부적합한 후계자로 보고 다른 아들로 대체하려 했을 가능성이 있다. 아멜-마르두크가 그럼에도 불구하고 왕이 된 이유는 명확하지 않다. 그럼에도 불구하고, 아멜-마르두크의 행정 업무는 그가 왕이 되기 전, 아버지의 통치 마지막 몇 주 또는 몇 달 동안 네부카드네자르가 병으로 죽어갈 때 시작되었을 가능성이 있다. 네부카드네자르 통치 시기의 마지막으로 알려진 우루크 출신 태블릿은 아멜-마르두크의 첫 번째로 알려진 시파르 출신 태블릿과 같은 날인 10월 7일로 날짜가 표시되어 있다.