버로우즈 대규모 시스템

Burroughs Large Systems Group은 ^{[NB 1]}음절이 조밀한 스택 머신 명령어 세트를 사용하여 48비트 대형 메인프레임 제품군을 생산했습니다.이 제품군의 첫 번째 기계는 1961년 B5000으로 싱글패스 컴파일러를 사용하여 ALGOL 60 프로그램을 매우 잘 컴파일하도록 최적화되었습니다.B5000은 B5500(드럼이 아닌 디스크)과 B5700(클러스터로 실행되는 최대 4개의 시스템)으로 진화했습니다.그 후의 주요 재설계에는 B6500/B6700 라인과 그 후속 제품, 그리고 별도의 B8500 라인이 포함됩니다.

1970년대에 Burroughs Corporation은 하이엔드, 미드레인지 및 엔트리 레벨 비즈니스 컴퓨터 시스템을 위한 매우 다른 제품군 아키텍처를 가진 세 개의 부서로 조직되었습니다.각 부서의 제품군은 특정 프로그래밍 언어에 컴퓨터의 명령어 세트를 최적화하는 방법에 대한 다양한 개념에서 발전했습니다."Burroughs Large Systems"는 COBOL에 최적화된 중형 시스템(B2000, B3000, B4000) 또는 유연한 아키텍처의 소형 시스템(B1000)과는 대조적으로 이러한 대형 시스템 제품군을 모두 함께 지칭했습니다.

배경

1880년대에 설립된 Burroughs는 컴퓨팅 분야에서 가장 오래된 지속적으로 운영되는 회사였습니다(엘리엇 브라더스는 Burroughs 이전에 설립되었지만 19세기에는 컴퓨팅 장치를 만들지 않았습니다).1950년대 후반까지 컴퓨터 장비는 여전히 센시매틱과 같은 전자 기계 회계 기계에 국한되어 있었습니다.대규모 컴퓨터를 생산하기 시작한 전통적인 라이벌인 IBM과 NCR, 또는 최근 설립된 Univac과는 전혀 경쟁할 수 없었습니다.1956년, 그들은 ElectroData Corporation을 인수하고 디자인을 B205로 브랜드를 변경했습니다.

Burroughs의 첫 번째 내부 개발 기계인 B5000은 1961년에 설계되었으며, Burroughs는 당시 사용 가능한 가장 진보된 컴퓨팅 아이디어를 바탕으로 완전히 다른 디자인의 전략으로 시장에서의 늦은 진입을 해결하고자 했습니다.B5000 아키텍처는 사용되지 않았지만, B6500(이후 B6700 및 B7700)에 영감을 주었습니다.이 아키텍처를^{[citation needed]} 사용하는 컴퓨터는 B6700과 함께 처음 도입된 MCP 운영 체제의 진화된 호환 버전을 실행하는 Unisys ClearPath Libra 서버로 여전히 생산 중이었습니다.세 번째이자 가장 큰 라인인 B8500은 ^[1][2]상업적인 성공을 거두지 못했습니다.독자적인 CMOS 프로세서 설계 외에도 Unisys는 Intel Xeon 프로세서를 사용하며 Libra 서버에서 MCP, Microsoft Windows 및 Linux 운영 체제를 실행합니다. 맞춤형 칩의 사용은 점차 사라졌으며 2018년까지 Libra 서버는 엄격하게 몇 년 동안 Intel 제품이 되었습니다.

B5000, B5500, B5700

첫 번째 시리즈의 첫 번째 멤버인 B5000은 ^[3]1961년 로버트(밥) 바튼(Bob)이 이끄는 팀에 의해 처음 설계되었습니다.특이한 건축물을 가지고 있었습니다.컴퓨터 과학자 존 매시(John Mashey)가 가장 존경하는 건축물 중 하나로 꼽았습니다."저는 항상 이것이 제가 본 하드웨어/소프트웨어 결합 설계 중 가장 혁신적인 사례 중 하나이며,^[4] 그 시대를 훨씬 앞서가는 것이라고 생각했습니다."B5000은 B5500^[5](드럼 스토리지 대신 디스크를 사용함)과 B5700(여러 CPU를 공유 디스크 중심으로 클러스터링할 수 있음)이 뒤를 이었습니다.B5700의 후속 모델은 없었던 반면, B5000 라인은 B6500의 디자인에 큰 영향을 끼쳤고, 버로우즈는 마스터 컨트롤 프로그램(MCP)을 해당 기계에 이식했습니다.

특징들

• 하드웨어는 소프트웨어 요구사항을 지원하도록 설계되었습니다.
• 고급 프로그래밍 언어만을 지원하도록 설계된 하드웨어
• 단순화 명령어 집합
• 어셈블리 언어나 어셈블러가 없습니다. 모든 시스템 소프트웨어는 ESPOL이라는 이름의 ALGOL 60 확장 버전으로 작성되었습니다.그러나, ESPOL은 건축의 각 음절에 대한 문장을 가지고 있었습니다.
• 부분적으로 데이터 중심의 태그 지정 및 설명자 기반 설계
• 프로그래머가 접근 가능한 레지스터가 거의 없음
• 명시적 피연산자가 아닌 모든 연산이 스택을 사용하는 스택 시스템.이 접근법은 이제는 인기가 없어졌습니다.
• 모든 인터럽트 및 프로시저 호출은 스택을 사용합니다.
• 코볼 등 다른 언어 지원
• 강력한 문자열 조작
• 모든 코드는 자동으로 재돌입합니다. 프로그래머들은 단순한 프리미티브 두 가지만 사용하는 것보다 어떤 언어의 코드도 프로세서에 퍼지게 하기 위해 더 이상 아무것도 할 필요가 없습니다.
• 운영체제(MCP, Master Control Program) 지원
• 비대칭(마스터/슬레이브) 멀티프로세싱 지원
• 데이터의 무단 액세스 또는 운영^{[NB 2]} 중단을 금지하는 보안 아키텍처 시도
• 소프트웨어 개발 및 테스트를 지원하는 오류 조기 탐지
• 페란티 아틀라스 이전의 상용 구현 가상 메모리입니다.
• 첫 번째 세그먼트 메모리 모델

시스템설계

당시 B5000은 소프트웨어의 요구를 고려하여 아키텍처와 명령어 세트를 설계했다는 점에서 이례적이었습니다.이는 프로세서와 명령어 세트가 설계된 후 소프트웨어 담당자에게 넘겨지는 당시의 컴퓨터 시스템 설계에서 크게 벗어난 것입니다.

워드 모드의 B5000, B5500 및 B5700은 메인 프로그램(SALF 꺼짐) 또는 서브루틴(SALF 켜짐) 실행 여부에 따라 두 가지 다른 어드레싱 모드가 있습니다.주 프로그램의 경우, Operand Call 또는 Descriptor Call 음절의 T 필드는 PRT(Program Reference Table)와 상대적입니다.서브루틴의 경우, 어드레싱 유형은 B5x00 Relative Addressing에서와 같이 T의 높은 3비트와 MSFF(Mark Stack Flip Flop)에 따라 달라집니다.

B5x00 상대 주소^[6] 지정

SALF[a]	T0 A38	T1 A39	T2 A40	MSFF[b]	기초	내용물	색인 기호	색인 비트[c]	맥스. 색인
쉬는	-	-	-	-	R	PRT주소	+	T0-9 A 38-47	1023
ON	쉬는	-	-	-	R	PRT주소	+	T1-9 A 39-47	511
ON	ON	쉬는	-	쉬는	F	스택의 마지막[d] RCW 또는 MSCW[e] 주소	+	T2-9 A 40-47	255
ON	ON	쉬는	-	ON	(R+7)[f]	PRT+7에서 MSCW에서[e] F 레지스터	+	T2-9 A 40-47	255
ON	ON	ON	쉬는	-	다[g]	현재지시어 주소	+	T3-9 A 41-47	127
ON	ON	ON	ON	쉬는	F	스택의 마지막[d] RCW 또는 MSCW[e] 주소	-	T3-9 A 41-47	127
ON	ON	ON	ON	ON	(R+7)[f]	PRT+7에서 MSCW에서[e] F 레지스터	-	T3-9 A 41-47	127
주의: ^ SALF 서브루틴 레벨 플립플롭 ^ MSFF 마크스택 플립플롭 ^ OPDC(Operand Call) 및 DESC(Descriptor Call) 음절의 경우 상대 주소는 음절의 비트 0-9(T register)입니다.Store operator(CID, CND, ISD, ISN, STD, STN)의 경우 Flag 비트가 설정된 경우 A 레지스터(스택 상단)에 절대 주소가 포함되고 Flag 비트가 꺼져 있는 경우 상대 주소가 포함됩니다. ^ a b RCW 리턴 컨트롤 워드 ^ a b c d MSCW 마크 스택 컨트롤 워드 ^ a b PRT+7에서 MSCW에서 F 레지스터 ^ C(현재 명령어)-R에 상대적으로 강제됨(PRT)-스토어, 프로그램 및 I/O 릴리스 연산자에 대한 상대적임

언어 지원

B5000은 고급 언어만을 지원하도록 설계되었습니다.이 시기는 그러한 언어들이 포트란과 코볼로 막 두각을 나타내던 시기였습니다. 포트란과 코볼은 현대 소프트웨어 기술에 있어서 일부 사람들에 의해 더 약한 언어로 간주되었기 때문에, 더 새롭고 대부분 시도되지 않은 언어인 ALGOL-60이 채택되었습니다.B5000을 위해 선택된 ALGOL 방언은 C가 처음 설계하고 구현한 엘리엇 ALGOL이었습니다. A. R. Hoare on the Elliott 503.이것은 (ALGOL이 무시했던) I/O 명령과 강력한 문자열 처리 명령으로 ALGOL의 실질적인 확장이었습니다.호어의 유명한 튜링상 강의는 이 주제였습니다.

따라서 B5000은 매우 강력한 언어를 기반으로 합니다.Donald Knuth는 여름 휴가 3개월 동안 초기 Burroughs 머신에 ALGOL 58을 구현한 적이 있으며, 주로 B5000 설계에 컨설턴트로 참여했습니다.많은 사람들이 ALGOL을 삭제했는데, 높은 수준의 언어는 어셈블러와 같은 힘을 가질 수 없다고 잘못 믿어서 ALGOL의 시스템 프로그래밍 언어로서의 가능성을 깨닫지 못했습니다.

Burroughs ALGOL 컴파일러는 매우 빨랐습니다. 이것은 네덜란드 과학자 Edsger Dijkstra가 B5000 Pasadena 공장에서 컴파일할 프로그램을 제출했을 때 깊은 인상을 주었습니다.그의 카드 덱은 거의 즉시 작성되었고 그는 즉시 그의 대학인 네덜란드 아인트호벤 공과대학을 위한 몇 대의 기계를 원했습니다.컴파일러는 몇 가지 이유로 빨랐지만, 가장 큰 이유는 원패스 컴파일러였기 때문입니다.초기 컴퓨터에는 소스 코드를 저장할 메모리가 충분하지 않았기 때문에 컴파일러(그리고 심지어 어셈블러)는 보통 소스 코드를 두 번 이상 읽어야 했습니다.Burroughs ALGOL 구문은 공용어와 달리 각 변수(또는 다른 개체)가 사용되기 전에 선언되어야 하므로 데이터를 한 번만 읽는 ALGOL 컴파일러 작성이 가능합니다.이 개념은 이론적 의미가 깊지만 매우 빠른 컴파일도 가능합니다.Burroughs 대형 시스템은 천공된 카드에서 소스 코드를 읽을 수 있는 속도만큼 빠르게 컴파일할 수 있었으며 업계에서 가장 빠른 카드 판독기를 보유하고 있었습니다.

강력한 Burroughs COBOL 컴파일러 또한 원패스 컴파일러였으며 마찬가지로 빠릅니다.1000 카드/분 단위의 판독기가 코드를 읽을 수 있는 속도만큼 빠르게 컴파일된 4000 카드 코볼 프로그램.그 프로그램은 카드가 리더기를 통과하자마자 사용할 준비가 되었습니다.

B6500, B6700/B7700 및 후속 제품

B6500^[7](1969년 납품^[8][9])과 B7500은^{[citation needed]} 버로우즈 시스템의 유일한 제품군에서 현재까지 생존한 최초의 컴퓨터였습니다.그들은 B5000에서 영감을 얻었지만, 완전히 새로운 아키텍처를 가지고 있었습니다.가장 중요한 차이점 중에는

• B6500은 12비트 음절의 고정 길이 명령 대신 8비트 음절의 가변 길이 명령이 있었습니다.
• B6500은 48비트 단어 대신 51비트를^{[NB 3]} 가지고 있었고, 3비트를 태그로 사용했습니다.
• B6500은 SMP(Symmetric Multiprocessing) 기능을 갖추고 있었습니다.
• B6500은 사가로(Saguaro) 스택을 가지고 있었습니다.
• B6500은 페이징 어레이를 가지고 있었습니다.
• B6500은 중첩된 서브루틴이 외부 블록의 변수에 접근할 수 있도록 디스플레이 레지스터, D1~D32를 가지고 있었습니다.
• B6500은 자기 박막 ^[8]메모리를 가진 단일 집적 회로를 사용했습니다.

B6700과 B7700의 다른 고객들 중에는 ^[10]1971년 뉴질랜드의 5개 대학이 있었습니다.

B8500

B8500^[1][2] 라인은 B5000에서 영감을 받은 군사용 컴퓨터인 D825에서 ^[11]유래했습니다.

B8500은 1960년대에 B5500과 D825 디자인을 병합하기 위한 시도로 디자인되었습니다.이 시스템은 자기 박막 메모리를 가진 단일 집적 회로를 사용했습니다.이 아키텍처는 B5500과 같은 48비트 워드, 스택 및 디스크립터를 사용했지만 상향 ^[1]호환성이 있다고 광고되지는 않았습니다.B8500은 안정적으로 작동할 수 없었고, 1970년 이후 프로젝트가 취소되어 시스템이 ^[2]완성되지 못했습니다.

역사

이 섹션은 확장이 필요합니다.추가하면 도움이 됩니다. (2008년 6월)

다음의 논의에서는 B5000 및 B8500 라인의 기능과 개념을 B6500 라인과 불필요하게 혼동하더라도 기계 명칭인 B5000, A 시리즈 및 ClearPath/MCP를 서로 교환하여 사용합니다.

가상 메모리의 중심 개념은 페란티 아틀라스와 라이스 인스티튜트 컴퓨터의 디자인에서 나타났고, 디스크립터와 태그가 달린 아키텍처의 중심 개념은 1950년대 후반 라이스 인스티튜트^[12] 컴퓨터의 디자인에서 나타났습니다.그러나 이 디자인들이 버로우즈에 직접적인 영향을 주었다고 해도, B5000, B6500, B8500의 아키텍처는 Atlas와 Rice 기계의 아키텍처와는 매우 달랐습니다.

Burroughs 대형 시스템 중 최초의 것은 B5000이었습니다.1961년에 설계된 이 컴퓨터는 2세대 컴퓨터로 이산 트랜지스터 로직과 마그네틱 코어 메모리를 사용했으며, B5500과 B5700이 그 뒤를 이었습니다.B5000 아키텍처를 대체한 최초의 기계는 B6500과 B7500이었습니다.B6500과 B7500의 후속 기계는 하드웨어 개발 동향을 따라 향후 25년 동안 새로운 논리로 아키텍처를 재구현했습니다. B6500, B7500, B6700, B7700, B6800, B7800, B5900,^{[NB 4]} B7900, 그리고 마지막으로 Burroughs A 시리즈도 출시되었습니다.Burroughs가 Sperry Corporation을 인수하여 Unisys로 사명을 변경한 합병 후, 회사는 MCP CMOS ASIC을 기반으로 한 새로운 기계를 계속 개발했습니다.이 기계들은 천칭자리 100부터 천칭자리 500까지였으며, 2005년에 천칭자리 590이 발표되었습니다.590을 포함한 이후의 리브라스 또한 인텔 Xeon 프로세서를 포함하고 있으며 MCP CMOS 프로세서 뿐만 아니라 에뮬레이션으로 Burroughs 대형 시스템 아키텍처를 실행할 수 있습니다.유니시스가 새로운 MCP CMOS ASIC의 개발을 계속할지는 불투명합니다.

버로우즈 (1961-1986)
B5000	1961	초기 시스템, 2세대 (트랜지스터) 컴퓨터
B5500	1964	속도[2][13] 3배 향상
B6500	1969	3세대 컴퓨터(집적 회로), 최대 4개 프로세서
B5700	1971	B5500의[disputed – discuss] 새 이름
B6700	1971	B6500의[disputed – discuss] 새 이름/버그 수정
B7700	1972	하나 또는 두 개의 파티션에서 최대 8개의 요청자(I/O 또는 Central 프로세서)를 처리할 수 있습니다.
B6800	1977?	반도체 메모리, NUMA 아키텍처
B7800	1977?	하나 또는 두 개의 파티션에서 최대 8개의 요청기(I/O 또는 Central 프로세서)를 더 빠르게 처리하는 반도체 메모리.
B6900	1979?	반도체 메모리, NUMA 아키텍처.로컬 메모리와 공통 글로벌 메모리에 바인딩된 최대 4개의 B6900 CPU(tm)
B5900	1981	반도체 메모리, NUMA 아키텍처.로컬 메모리와 공통 글로벌 메모리 II에 바인딩된 최대 4개의 B5900 CPU(tm)
B7900	1982?	반도체 메모리, 더 빠른 속도, 코드 및 데이터 캐시, NUMA 아키텍처, 1-2개의 HDU(I/O), 1-2개의 AP, 1-4개의 CPU, NUMA 메모리를 소프트하게 구현하여 CPU를 메모리 공간에서 메모리 공간으로 이동할 수 있게 했습니다.
A9/A10	1984	B6000 클래스, 미드레인지 최초의 파이프라인 프로세서, 단일 CPU(A10 이중), eMode Beta 최초 지원(메모리 어드레싱 확장)
A12/A15	1985	B7000 클래스, 맞춤 설계 Motorola ECL MCA1에 재구현, MCA2 게이트 어레이, 단일 CPU 단일 HDU(A12) 1–4 CPU, 1–2 HDU(A15)
유니시스 (1986 ~ 현재)
마이크로 A	1989	싱글칩[14][15][16] SCAMP 프로세서를 탑재한 데스크톱 "메인프레임".
경로 지우기 HMP NX 4000	1996?	?[17][18]
Clearpath HMP NX	1996?	?[17][18]
Clearpath HMP LX 5000	1998	Burroughs Large 시스템을 에뮬레이션에서만 구현(Xeon 프로세서)[19]
천칭자리 100	2002?	??
천칭자리 200	200?	??
천칭자리 300	200?	??
천칭자리 400	200?	??
천칭자리 500	2005?	예: 천칭자리 595[20]
천칭자리 600	2006?	??
천칭자리 700	2010	예: 천칭자리[21] 750

주 하드웨어 라인

하드웨어 및 소프트웨어 설계, 개발 및 제조는 캘리포니아 오렌지 카운티와 필라델피아 외곽의 두 주요 지역으로 나뉘었습니다.B5000과 B5500을 개발한 최초의 Large Systems Plant는 캘리포니아 패서디나에 위치해 있었으나, City of Industry, California로 이전하여 B6500을 개발했습니다.오렌지 카운티의 위치는 캘리포니아 미션 비에호 공장에 기반을 두고 있지만 때로는 근처 어바인과 레이크 포레스트에 있는 시설도 포함되어 있으며, 더 작은 B6x00 라인을 담당하고 있는 반면 펜실베이니아주 트레디프린에 기반을 둔 이스트 코스트 사업부는 더 큰 B7x00 라인을 담당했습니다.두 줄의 모든 기계는 완전히 객체 호환이 가능했습니다. 즉, 한 줄에서 컴파일된 프로그램을 다른 줄에서 실행할 수 있습니다.최신 모델과 대형 모델에는 구형 모델과 저속 모델에서는 지원되지 않는 명령어가 있었지만 하드웨어에서 인식할 수 없는 명령어가 발생하면 운영 체제 기능을 호출하여 이를 해석했습니다.다른 차이점으로는 프로세스 전환 및 I/O 처리 방식, 유지보수 및 냉간 시동 기능 등이 있습니다.더 큰 시스템에는 하드웨어 프로세스 스케줄링, 더 유능한 입출력 모듈, 더 고기능성 유지보수 프로세서 등이 포함되었습니다.Bxx00 모델이 A 시리즈 모델로 교체되었을 때, 차이점은 그대로 유지되었지만 더 이상 모델 번호로 쉽게 식별할 수 없었습니다.

알골

버로우즈 알골

패러다임	다중 패러다임: 절차적, 명령적, 구조적
가족	알골
설계자 :	존 매클린톡 외
디벨로퍼	버로우즈
첫 등장	1962; 61년전 (1962)
플랫폼	버로우즈 대규모 시스템
OS	버로우즈 MCP
영향을 받음
알골60
영향받은
ESPOL, MCP, NEWP

Burroughs 대형 시스템은 ALGOL에서 파생된 스택 아키텍처를 구현합니다.B5000은 최초의 스택 기반 시스템이었습니다.

B5000은 ALGOL을 지원하기 위해 특별히 설계되었지만, 이것은 시작점에 불과했습니다.코볼(COBOL)과 같은 다른 비즈니스 지향 언어들도 잘 지원되었는데, 특히 빠른 컴파일러 개발을 위해 포함된 강력한 스트링 연산자들이 특히 지원했습니다.

B5000에서 사용되는 ALGOL은 확장된 ALGOL 서브셋입니다.강력한 문자열 조작 명령을 포함하지만 특정 ALGOL 구성 요소, 특히 지정되지 않은 형식 매개 변수는 제외합니다.DEFINE 메커니즘은 C에서 찾을 수 있는 #defines와 유사한 용도로 사용되지만 전처리기가 아닌 언어에 완전히 통합됩니다.EVENT 데이터 유형은 프로세스 간 조정을 용이하게 하고 ON FAULT 블록은 프로그램 장애 처리를 가능하게 합니다.

ALGOL의 사용자 수준에는 운영 체제 및 기타 시스템 소프트웨어에 필요한 안전하지 않은 구성 요소가 많이 포함되어 있지 않습니다.두 가지 수준의 언어 확장은 추가적인 구성 요소를 제공합니다: MCP와 밀접하게 관련된 소프트웨어를 작성하기 위한 ESPOL과 NEWP, 특정 종류의 시스템 소프트웨어에 대한 보다 구체적인 확장을 제공하기 위한 DCALGOL과 DMALGOL.

ESPOL 및 NEWP

원래 B5000 MCP 운영 체제는 ESPOL(Executive Systems Programming Oriented Language)이라는 확장된 ALGOL의 확장으로 작성되었습니다.이것은 70년대 중후반에 NEWP라는 언어로 대체되었습니다.NEWP는 아마도 "새로운 프로그래밍 언어"를 의미했을 것이지만, 전설들은 그 이름을 둘러싸고 있습니다.당시 버로우즈에서 흔히 볼 수 있는 (아마도 비과학적인) 이야기는 그 이야기가 "노 이그제큐티브 워시룸 특권"에서 나왔다는 것을 암시합니다.또 다른 이야기는 1976년경 버로우즈의 존 맥클린톡(뉴프 개발 소프트웨어 엔지니어)이 "뉴프(NEWP)"라는 언어를 "아직 이름이 있느냐"는 질문을 받고 "뉴프(NEWP)"라고 이름 지었다는 것입니다.NEWP 역시 부분 집합 ALGOL 확장자였지만, ESPOL보다 더 안전했고, ALGOL의 일부 사용되지 않는 복잡성을 제거했습니다. 실제로, 그러한 명령어를 허용하도록 블록을 특별히 표시하지 않는 한, 모든 안전하지 않은 구문은 NEWP 컴파일러에 의해 거부됩니다.블록의 이러한 마킹은 다단계 보호 메커니즘을 제공합니다.

안전하지 않은 구성을 포함하는 NEWP 프로그램은 처음에는 실행할 수 없습니다.시스템의 보안 관리자는 이러한 프로그램을 "축복"하여 실행 가능하도록 만들 수 있지만 일반 사용자는 이를 수행할 수 없습니다. (일반적으로 루트 권한을 가지고 있는 "특권 사용자"조차도 사이트에서 선택한 구성에 따라 이를 수행할 수 없을 수 있습니다.)NEWP는 일반적인 프로그램을 작성하는 데 사용될 수 있고 대규모 소프트웨어 프로젝트를 위해 설계된 많은 기능을 가지고 있지만, ALGOL이 하는 모든 것을 지원하지는 않습니다.

NEWP에는 명명된 인터페이스(함수 및 데이터), 인터페이스 그룹, 모듈 및 슈퍼 모듈을 포함한 운영 체제와 같은 대규모 소프트웨어 프로젝트를 가능하게 하는 다수의 기능이 있습니다.모듈은 데이터와 기능을 함께 그룹화하여 모듈 내에서 글로벌 데이터에 쉽게 액세스할 수 있습니다.인터페이스를 통해 모듈은 기능과 데이터를 가져오고 내보낼 수 있습니다.슈퍼모듈은 모듈을 그룹화할 수 있게 해줍니다.

IMT2000 3GPP - DCALGOL 및 메시지제어시스템

원래 구현에서 시스템은 원격 장치에서/원격 장치로 메시지의 입/출력을 처리하기 위해 부착된 DCP(특수 데이터 통신 프로세서)를 사용했습니다.이 컴퓨터는 기존의 레지스터 아키텍처와 수천 개의 원격 터미널을 처리할 수 있는 하드웨어 I/O 기능을 갖춘 24비트 미니 컴퓨터였습니다.DCP와 B6500은 메모리 내의 메시지, 즉 오늘날의 용어로 패킷을 통해 통신하였고, MCS는 그러한 메시지의 B6500측 처리를 수행하였습니다.초기 몇 년 동안 DCP는 어셈블러(Dacoma)를 가지고 있었는데, DCP progen이라고 불리는 응용 프로그램은 B6500 ALGOL로 작성되었습니다. 나중에 NDL (Network Definition Language) 컴파일러는 DCP 코드와 NDF (Network Definition File)을 생성했습니다.최종적으로, 추가적인 업데이트는 모델 4 및 5 DCP와 함께 사용된 NDLII 언어 및 컴파일러의 개발로 이어졌습니다.DCP 명령어 종류별로 ALGOL 함수가 하나씩 있었는데, 그 함수를 호출하면 해당 DCP 명령어 비트가 출력으로 나오게 됩니다.DCP 프로그램은 각 어셈블리어 문장에 대해 하나씩 이러한 함수에 대한 긴 호출 목록으로 구성된 ALGOL 프로그램이었습니다.기본적으로 ALGOL은 매크로 어셈블러의 매크로 패스와 같은 역할을 했습니다.첫 번째 패스는 ALGOL 컴파일러였고, 두 번째 패스는 (B6500에서) 결과 프로그램을 실행하는 것이었고, 그 후 DCP를 위한 바이너리를 내보내는 것이었습니다.

1980년대 초부터 DCP 기술은 메인프레임 시스템에 LAN 기반 연결을 제공하는 ICP(Integrated Communications Processor)로 대체되었습니다.원격 장치와 원격 서버/메인프레임은 CP2000s라고 불리는 자유로운 독립 장치를 통해 네트워크에 연결되었습니다.CP2000s는 BNAV2(Burroughs Network Architecture Version 2) 네트워킹 기술을 사용하여 노드가 연결된 분산 네트워크에서 네트워크 노드 지원을 제공하도록 설계되었습니다.BNAV2는 IBM SNA 제품과 동등한 기능을 가진 Burroughs 제품으로 PUT2 및 PUT5 전송 모드 모두에서 IBM 환경과의 상호 작용을 지원했습니다.외부 데이터 통신 하드웨어의 변경은 기존 MCS(Message Control System, 이하 논의) 소프트웨어의 변경을 요구하지 않았습니다.

입력 시, 메시지는 내부 버스를 통해 DCP에서 관련 MCP 데이터콤 컨트롤(DCC) DCP 프로세스 스택으로 전달되었습니다.시스템에 구성된 각 DCP에 대해 하나의 DCC 프로세스가 시작되었습니다.그러면 DCP 프로세스 스택은 인바운드 메시지가 특정 소스 디바이스로부터의 트래픽을 처리하기 위해 식별된 MCS로의 전달을 위해 대기하고 대상 디바이스로의 전달을 위해 DCP에 응답을 반환하도록 합니다.처리 측면에서 볼 때, DCP 또는 ICP/CP2000 조합의 5가지 스타일 중 어느 것이든 다양한 유형의 게이트웨이 하드웨어를 처리하기 위해 MCS 소프트웨어를 변경할 필요는 없었습니다.

메시지 전달 서비스 이외에도, MCS는 운영 체제 코드(NEWP)와 사용자 프로그램(ALGOL 또는 COBOL, FORTRAN 및 나중에는 JAVA를 포함한 다른 응용 프로그램 언어) 사이의 중간 수준의 보안입니다.MCS는 미들웨어 프로그램으로 간주될 수 있으며 DCALGOL(Data Communications ALGOL)로 작성됩니다.위에 기술된 바와 같이, MCS는 데이터콤 제어 스택(DCC)에 의해 유지되는 대기열로부터 메시지를 수신하고, 이 메시지들을 처리하기 위해 적절한 애플리케이션/기능에 전달하였습니다.온라인 프로그램 개발 환경으로 개발된 CANDE(Command AND Edit)는 기존 MCS 중 하나였습니다.뉴질랜드의 Otago 대학은 IBM이 IBM 360 시리즈 시스템에서 실행되는 CALL/360이라는 원격 시분할/프로그램 개발 서비스를 제공하던 시기에 SCREMIL/6700이라고 부르는 CANDE와 동등한 수준의 스키니 프로그램 개발 환경을 개발했습니다.COMS라는 또 다른 MCS는 1984년경에 도입되어 고성능 트랜잭션 처리 제어 시스템으로 개발되었습니다.GEMCOS(Generalized Message CONControl System)를 포함한 이전의 트랜잭션 처리 환경과 TPMCS(Transaction Processing MCS)라는 호주의 Burroughs 자회사가 개발한 MCS가 있었습니다.트랜잭션 처리 MCS는 온라인 프로덕션 환경에 애플리케이션 데이터를 전달하고 원격 사용자/장치/시스템에 대한 응답을 반환하는 것을 지원했습니다.

MCS는 주목할 만한 소프트웨어 항목으로, 단일 MCS 스택을 여러 사용자가 공유할 수 있으므로 사용자별 프로세스를 실행할 필요 없이 사용자 세션을 제어하고 사용자 상태를 추적할 수 있습니다.MCS 레벨에서도 로드 밸런싱을 수행할 수 있습니다.예를 들어 스택당 30명의 사용자를 처리하고 싶다고 하면, 31~60명의 사용자가 있는 경우에는 61~90명의 사용자, 3개의 스택 등 2개의 스택이 있습니다.이것은 사용자가 시스템에 연결할 때마다 다른 사용자 프로세스를 시작할 필요가 없고 새로운 스택을 만들 필요가 없기 때문에 서버에서 B5000 머신의 성능을 크게 향상시킵니다.따라서, MCS로 사용자(상태가 필요하든 그렇지 않든)를 효율적으로 서비스할 수 있습니다. MCS는 또한 대규모 트랜잭션 처리의 백본을 제공합니다.

1988년 경 TCP/IP의 구현은 주로 CP2000 분산 통신 프로세서를 프로토콜 호스트로 사용하는 미국 정부 고객을 위해 개발되었습니다.2~3년 후, TCP/IP 구현은 성능과 기능이 크게 향상된 호스트/서버 기반으로 다시 작성되었습니다.동일한 일반 시간대에 주로 CP2000에서 OSI 프로토콜 스택의 구현이 이루어졌지만, 대규모 지원 인프라스트럭처가 메인 시스템에 구현되었습니다.X.400 메일 호스팅 및 X.500 디렉토리 서비스를 포함하여 OSI 표준으로 정의된 모든 애플리케이션이 구현되었습니다.

DMALGOL 및 데이터베이스

ALGOL의 또 다른 변형은 데이터 관리 ALGOL(Data Management ALGOL)입니다.DMALGOL은 DASDL(Data Access and Structure Definition Language) 컴파일러가 만든 데이터베이스 설명 파일에서 DMSII 데이터베이스 소프트웨어를 컴파일하기 위해 확장된 ALGOL입니다.데이터베이스 설계자와 관리자는 데이터베이스 설명을 컴파일하여 지정된 테이블과 인덱스에 맞게 맞춤화된 DMALGOL 코드를 생성합니다.관리자가 직접 DMALGOL을 작성할 필요는 없습니다.일반적인 사용자 수준의 프로그램은 주로 ALGOL과 COBOL로 작성된 코드를 데이터베이스 명령과 트랜잭션 처리 명령으로 확장하여 데이터베이스 액세스를 획득합니다.DMALGOL의 가장 주목할 만한 특징은 테이블과 인덱스를 처리하기 위한 코드를 생성하는 전처리 메커니즘입니다.

DMALGOL 전처리는 변수와 루프를 포함하며 컴파일 시간 변수를 기반으로 이름을 생성할 수 있습니다.이를 통해 루프가 없는 전처리 설비를 통해 수행할 수 있는 수준을 훨씬 뛰어넘는 맞춤화가 가능합니다.

DMALGOL은 DMSII 데이터베이스에 대한 맞춤형 액세스 루틴을 제공하는 데 사용됩니다.데이터베이스가 DASDL(Data Access and Structure Definition Language)을 사용하여 정의된 후, 스키마는 전처리기에 의해 맞춤형 DMALGOL 액세스 루틴으로 변환된 후 컴파일됩니다.이는 다른 DBMS 구현과 달리 런타임에 데이터베이스별 if/then/else 코드가 필요 없는 경우가 많다는 것을 의미합니다.1970년대에는 코드 설치 공간과 실행 시간을 줄이기 위해 이 "맞춤형"이 매우 광범위하게 사용되었습니다.나중에는 메모리와 속도에 대한 낮은 수준의 미세 조정이 덜 중요해졌기 때문이기도 하고, 부분적으로는 전처리를 제거하면 코딩이 더 간단해져 더 중요한 최적화가 가능했기 때문이기도 합니다.

응용 프로그램에서 데이터베이스의 접근을 지원하기 위한 ALGOL의 응용 프로그램 버전은 BDMSALGOL이며, 데이터베이스 접근 및 기록 조작을 위해 "FIND", "LOCK", "STORE", "GET", "PUT"와 같은 동사를 포함합니다.또한 여러 프로세스가 동일한 구조에 접근하여 업데이트할 때 교착상태를 해결하기 위해 동사 "BEGINTRANSATION"과 "ENDTRANSATION"도 구현되었습니다.

버로우즈의 로이 국은 DMSII의 주요 개발자 중 한 명이었습니다.

나중에는 컴파일러 코드 크기에 대한 우려가 덜한 상태에서 대부분의 전처리 구문을 ALGOL의 사용자 수준에서 사용할 수 있게 되었습니다. 안전하지 않은 구문과 데이터베이스 설명 파일의 직접 처리만 DMALGOL로 제한됩니다.

스택 아키텍처

많은 초기 시스템과 언어에서 프로그래머들은 종종 그들의 루틴을 너무 작게 만들지 말라는 말을 들었습니다.스택을 유지하기 위해 여러 작업을 수행해야 했기 때문에 절차 호출 및 반환 비용이 많이 들었습니다.B5000은 스택 머신(Stack Machine)으로 설계되었으며, 문자열과 객체를 포함한 배열을 제외한 모든 프로그램 데이터가 스택에 저장되었습니다.이는 스택 운영이 효율성을 위해 최적화되었다는 것을 의미했습니다.스택 지향 머신으로서 프로그래머 주소 지정 가능한 레지스터가 없습니다.

B5000 및 B6500 라인에서도 멀티태스킹이 매우 효율적입니다.프로세스 스위치를 수행하기 위한 구체적인 지침이 있습니다.

B5000,B5500,B5700

P1(IP1) 시작 및 P2(IP2)^{[5]: 6–30} 시작

B6500, B7500 및 그 후속 제품

MVST(스택 ^{[7]: 8–19 [22]}이동).

각 스택 및 관련^{[NB 5]} PRT(Program Reference Table)는 프로세스(태스크 또는 스레드)를 나타내며, 리소스 요청 시(사전 멀티태스킹으로 인해 작업이 중단된 경우 프로세서가 실행될 때까지 대기하는 것을 포함) 작업이 차단될 수 있습니다.사용자 프로그램은 IP1,^{[NB 5]} IP2^{[NB 5]} 또는 MVST를 ^{[NB 6]}발행할 수 없으며 운영 체제에서 이 작업이 수행되는 곳은 한 곳뿐입니다.

프로세스 스위치는 이와 같은 작업을 진행합니다. 즉, 프로세스는 즉시 사용할 수 없는 리소스를 요청하거나, 현재 메모리에 없는 블록에서 파일의 레코드를 읽거나, 시스템 타이머가 인터럽트를 트리거한 경우일 수 있습니다.운영 체제 코드가 입력되고 사용자 스택 위에서 실행됩니다.사용자 프로세스 타이머를 끕니다.현재 프로세스는 요청 중인 리소스에 대한 적절한 대기열에 배치되거나 사전 컨텍스트 스위치인 경우 프로세서를 대기하는 준비 대기열에 배치됩니다.운영 체제는 준비 큐에서 첫 번째 프로세스를 결정하고 명령 move_stack을 호출하여 준비 큐의 맨 앞에 있는 프로세스를 활성화합니다.

스택 속도 및 성능

스택 성능은 레지스터 기반 아키텍처에 비해 느린 것으로 간주되었으며, 예를 들어, 시스템/^[23]360의 경우 그러한 아키텍처가 고려되었으나 거부되었습니다.시스템 속도를 높이는 한 가지 방법은 데이터를 프로세서에 최대한 가깝게 유지하는 것입니다.B5000 스택에서는 두 개의 레지스터 A와 B에 스택의 상위 두 위치를 할당하여 수행했습니다.대부분의 작업은 두 개의 스택 상단 위치에서 수행됩니다.B5000을 지난 더 빠른 기계에서는 더 많은 스택이 프로세서 근처의 레지스터나 캐시에 보관될 수 있습니다.

따라서 현재 B5000 시스템의 후속 제품 설계자는 최신 기술이 무엇이든 최적화할 수 있으며 프로그래머는 코드를 조정하여 더 빠르게 실행할 필요가 없으므로 소프트웨어 투자를 보호할 수 있습니다.일부 프로그램은 많은 프로세서 업그레이드를 통해 수년간 실행되는 것으로 알려져 있습니다.이러한 속도 향상은 레지스터 기반 ^{[citation needed]}시스템에서만 제한됩니다.

RISC 설계자들이 추진한 속도의 또 다른 점은 모든 것이 하나의 칩에 있을 경우 프로세서 속도가 상당히 빠르다는 것입니다.1970년대에 B5000과 같은 복잡한 아키텍처가 하나의 칩에 장착하기에는 너무 많은 트랜지스터를 필요로 했을 때 이는 유효했습니다.그러나 현재는 그렇지 않으며 모든 B5000 후속 머신은 캐시 및 명령 파이프라인과 같은 성능 지원 기술뿐만 아니라 단일 칩에 적합합니다.

실제로 B5000 후속 제품군의 A 시리즈 제품군에는 1980년대 말 최초의 단일 칩 메인프레임인 Micro-A가 포함되어 있었습니다.이 "메인프레임" 칩(Single-Chip A-Series Mainframe Processor용 SCAMP)은 Intel 기반 플러그인 PC 보드에 탑재되었습니다.

프로그램이 스택에 매핑되는 방법

여기 프로그램이 스택 구조에 매핑되는 방법의 예가 있습니다.

       시작 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------— ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------integeri, j, k; realf, g; arraya [0:9]; procedurep (realp1, p2); valuep1; — p1은 값으로 통과하고 p2는 암시적으로 참조로 통과합니다. 시작 -- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
                                    r2 := p1 * 5; p2 := r2; — g를 r2p1 := r2의 값으로 설정합니다. — p1을 r2로 설정하지만 f는 설정하지 않습니다 — p1의 f의 원래 값을 덮어쓰므로 — 코딩 오류일 수 있습니다.따라서 ALGOL의 후계자들 중 몇몇은 값 매개 변수는 읽기 전용이어야 한다고 주장하지만 대부분은 읽지 않는다. ifr2 > 10은 시작한다. 여기서 선언된 변수는 이 어휘 레벨을 4로 만든다;
— 변수를 선언하면 이를 블록으로 만들어 일부 스택 빌딩 코드를 호출합니다.일반적으로 여기서는 변수를 선언하지 않습니다. 이 경우에는 블록이 아닌 복합문이 됩니다. ...<== 샘플 스택이 여기 어딘가에서 실행되고 있습니다.end; end; ......p(f,g); end.

각 스택 프레임은 현재 실행 환경에서의 어휘 수준에 해당합니다.보다시피 어휘 수준은 프로그램의 정적 텍스트 네스팅이지 동적 호출 네스팅이 아닙니다.싱글패스 컴파일러용으로 설계된 언어인 ALGOL의 가시성 규칙은 코드의 해당 부분에서 현재 위치 이전에 선언된 변수만 볼 수 있음을 의미하므로 순방향 선언에 대한 요구 사항입니다.엔클로저 블록에 선언된 모든 변수를 볼 수 있습니다.또 다른 경우는 내부 블록에 동일한 이름의 변수가 선언될 수 있으며 이러한 변수는 액세스할 수 없는 외부 변수를 효과적으로 숨깁니다.

어휘적 네스팅은 정적이고, 재귀가 있는 실행 네스팅과 관련이 없으며, 따라서 5단계 이상의 깊이로 네스팅된 프로시저를 찾는 것은 매우 드물며, 그러한 프로그램이 제대로 구성되지 않을 것이라는 주장이 제기될 수 있습니다.B5000 시스템은 최대 32단계의 네스팅을 허용합니다.생성 방법이 프로시저 내에서 자주 중첩 프로시저를 생성할 경우 알골 소스를 출력(일부 특수한 문제를 해결하도록 맞춤화)으로 생성한 일부 시스템에서는 어려움이 발생할 수 있습니다.

절차들

절차는 일반, 호출, 처리 및 실행의 네 가지 방법으로 호출할 수 있습니다.

일반 호출은 호출된 프로시저가 돌아올 때까지 호출 루틴을 일시 중단함으로써 모든 언어가 루틴을 호출하는 일반 방식으로 프로시저를 호출합니다.

호출 메커니즘은 코루틴으로 프로시저를 호출합니다.코루틴은 시작 프로세스와 동일한 어휘 수준으로 자체 스택에서 작동하는 동기화 엔티티로 설정된 파트너 작업입니다.제어는 시작 프로세스와 코루틴 사이에 CONTINUE 명령을 통해 명시적으로 전달됩니다.

프로세스 메커니즘은 처리된 프로시저의 어휘 수준에서 시작하는 별도의 스택이 있는 비동기 작업으로 프로시저를 호출합니다.비동기 작업으로서 코루틴과 달리 작업 간에 제어가 전달되는 정확한 시기에 대한 제어는 없습니다.처리된 절차는 여전히 엔클로저 환경에 액세스할 수 있으며 이는 매우 효율적인 IPC(Inter Process Communication) 메커니즘입니다.이제 두 개 이상의 작업이 공통 변수에 액세스할 수 있으므로 경주 조건을 방지하기 위해 작업을 동기화해야 합니다. 이 작업은 EVENT 데이터 유형에 의해 처리되며 프로세스는 다른 협력 프로세스에 의해 발생할 때까지 하나 이상의 이벤트에 대해 대기할 수 있습니다.EVENT는 또한 PROCure 및 LIBERATE 기능을 통해 상호 제외 동기화를 허용합니다.어떤 이유로든 자식 태스크가 종료되면 호출 태스크를 계속할 수 있지만, 부모 프로세스가 종료되면 모든 자식 프로세스가 자동으로 종료됩니다.프로세서가 둘 이상 있는 시스템에서는 프로세스가 동시에 실행될 수 있습니다.이 EVENT 메커니즘은 멀티태스킹과 더불어 멀티프로세싱을 위한 기본적인 활성화 장치입니다.

실행 호출 유형

마지막 호출 유형이 실행됩니다.이것은 프로시저를 독립적인 작업으로 실행하며, 이 작업은 원래 프로세스가 종료된 후에도 계속 진행할 수 있습니다.이러한 이유로 자식 프로세스는 부모 환경의 변수에 액세스할 수 없으며 호출된 프로시저에 전달되는 모든 매개 변수는 값별 호출이어야 합니다.

따라서 Burroughs Extended ALGOL에는 Ada와 같은 최신 언어의 다중 처리 및 동기화 기능이 일부 포함되어 있었습니다.하드웨어에 내장된 비동기 프로세스에 대한 지원을 활용했습니다.

인라인 프로시저

마지막 가능성은 NEWP에서 절차가 인라인(INLINE)으로 선언될 수 있다는 것입니다. 즉, 컴파일러가 이에 대한 참조를 볼 때 절차에 대한 코드가 인라인으로 생성되어 절차 호출의 오버헤드를 절약할 수 있습니다. 이는 작은 코드 조각에 대해 가장 잘 수행됩니다.인라인 함수는 C #defines와 같은 매개 변수화된 매크로와 유사하지만 매크로에서 사용할 수 있는 매개 변수에 대한 문제가 발생하지 않습니다.

비동기 호출

예제 프로그램에서는 일반 호출만 사용되므로 모든 정보가 단일 스택에 저장됩니다.비동기 호출의 경우 각 비동기 프로세스에 대해 별도의 스택이 시작되어 프로세스가 데이터를 공유하지만 비동기적으로 실행됩니다.

레지스터를 표시

스택 하드웨어 최적화는 D(또는 "디스플레이") 레지스터의 제공입니다.이 레지스터들은 각 스택 프레임의 시작을 가리키는 레지스터들입니다.이러한 레지스터는 절차가 들어가고 나올 때 자동으로 업데이트되며 MCP 이외의 소프트웨어에서는 액세스할 수 없습니다.32개의 D 레지스터가 있는데, 이것은 연산을 32단계의 어휘 네스팅으로 제한합니다.

어휘 수준 5(D[5])에서 어휘 수준 2(D[2]) 전역 변수에 접근하는 방법을 고려합니다.변수가 어휘 수준 2의 밑부분에서 6단어 떨어진다고 가정합니다.따라서 주소 커플 (2, 6)로 표시됩니다.만약 우리가 D 레지스터를 가지고 있지 않다면, 우리는 D[4] 환경을 포함하는 프레임을 가리키는 D[5] 프레임의 아래 부분의 컨트롤 워드를 보아야 합니다.그런 다음 이 환경의 기초에 있는 제어 단어를 보고 D[3] 환경을 찾고 필요한 어휘 수준으로 모든 링크를 다시 따라갈 때까지 이 방식으로 계속합니다.이 경로는 여기까지 도달하기 위해 호출된 절차를 통해 되돌아오는 경로와 동일하지 않습니다.(아키텍처는 데이터 스택과 호출 스택을 동일한 구조로 유지하지만 제어 단어를 사용하여 구분합니다.)

보다시피 변수에 접근하는 것만으로는 상당히 비효율적입니다.D 레지스터의 경우, D[2] 레지스터는 어휘 레벨 2 환경의 기초 부분을 가리키며, 변수의 주소를 생성하기 위해 우리가 해야 할 일은 스택 프레임 베이스에서 D 레지스터의 프레임 베이스 주소로 오프셋을 추가하는 것입니다.(위와 같은 방식으로 스택을 검색할 수 있는 효율적인 링크드 리스트 검색 연산자 LLLU가 있지만, D 레지스터 방식은 여전히 더 빨라질 것입니다.)D 레지스터를 사용하면 외부 및 전역 환경의 엔티티에 대한 액세스가 로컬 변수 액세스만큼 효율적입니다.

D 태그 데이터 — 주소 커플, 주석 레지스터

0 n (4, 1) 정수 n (프로시저가 아닌 블록으로의 진입에 따라 다름) --------------------------- D[4]==> 3 MSCW (4, 0) D[3]에 대한 링크를 포함하는 Mark Stack Control Word.=======================    0 r2 (3, 5) 실수 r2 ----------------------------------------- 0 r1 (3, 4) 실수 r1 --------------------------- 1 p2 (3, 3) Gat (2, 6) --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------,0) D[2]에 대한 링크를 포함하는 Mark Stack Control Word.=======================    1 a (2, 7) 배열 a ======>[열 단어 메모리 블록] ----------------------------------------------------------------- 0 0 f (2, 5) 실수 f --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------, 2) 정수 i --------------------------------------------------- 3 RCW (2, 1) 반환 컨트롤 워드 ------------------------------- D[2]==> 3 MSCW (2, 0) 이전 스택 프레임에 대한 링크를 포함하는 Mark Stack Control Word.=======================  — 스택 맨 아래쪽

프로시저 p를 코루틴 또는 프로세스 명령으로 호출했다면 D[3] 환경은 별도의 D[3] 기반 스택이 되었을 것입니다.이는 비동기 프로세스가 ALGOL 프로그램 코드에 암시된 대로 여전히 D[2] 환경에 액세스할 수 있음을 의미합니다.여기서 한 단계 더 나아가, 완전히 다른 프로그램이 다른 프로그램의 코드를 호출하여 자신의 프로세스 스택 위에 다른 프로세스의 D[2] 환경을 가리키는 D[3] 스택 프레임을 생성할 수 있습니다.코드 실행 환경의 전체 주소 공간이 순식간에 변경되어 자체 프로세스 스택의 D[2] 환경을 직접 주소 지정할 수 없고 대신 다른 프로세스 스택의 D[2] 환경을 직접 주소 지정할 수 있습니다.라이브러리 호출은 이렇게 구현됩니다.이러한 교차 스택 호출 시 호출 코드와 호출 코드는 서로 다른 소스 언어로 작성된 프로그램에서 비롯될 수 있으며 서로 다른 컴파일러에 의해 컴파일될 수도 있습니다.

D[1] 및 D[0] 환경은 현재 프로세스의 스택에서 발생하지 않습니다.D[1] 환경은 동일한 코드를 실행하는 모든 프로세스가 공유하는 코드 세그먼트 사전입니다.D[0] 환경은 운영 체제에서 내보낸 엔티티를 나타냅니다.

스택 프레임은 실제로 프로세스 스택에 존재할 필요도 없습니다.이 기능은 파일 I/O 최적화를 위해 초기에 사용되었으며 FIB(파일 정보 블록)는 I/O 작업 중에 D[1]의 디스플레이 레지스터에 링크되었습니다.90년대 초에 이 기능은 STRUCTOR BLOCK(구조 블록)으로 언어 기능으로 구현되었고, 라이브러리 기술과 결합하여 CONNECTION BLOCK(연결 블록)으로 구현되었습니다.표시 레지스터 주소 범위에 데이터 구조를 연결하는 기능은 객체 방향을 구현했습니다.따라서 B6500은 이 용어가 사용되기 훨씬 전부터 실제로 물체 방향의 형태를 사용했습니다.

다른 시스템에서는 컴파일러가 비슷한 방식으로 심볼 테이블을 구축할 수 있지만 결국 저장 요구 사항을 수집하고 기계 코드를 작성하여 16비트 또는 32비트 또는 64비트의 플랫 메모리 주소를 사용할 수 있습니다.이러한 주소에는 잘못된 주소에 쓸 경우 손상될 수 있도록 모든 내용이 포함되어 있을 수 있습니다.대신에, 2부 주소 체계는 하드웨어에 의해 구현되었습니다.각 어휘 수준에서 변수는 수준 스택의 아래쪽에서 위쪽으로 이동하여 배치되었으며, 일반적으로 한 단어를 차지했습니다. 두 배의 정밀도 또는 복잡한 변수가 두 단어를 차지했습니다.배열은 이 영역에 저장되지 않았으며 배열에 대한 한 단어 설명자만 저장되었습니다.따라서 각 어휘 수준에서 총 스토리지 요구량은 크지 않았습니다. 극단적인 경우에는 수십, 수백, 수천 개, 32비트 이상이 필요한 수는 분명 아닙니다.실제로 이는 피연산자를 스택에 로드하는 VALC 명령(value call)의 형태로 반영되었습니다.이 op-code는 2비트 길이였고 나머지 바이트 비트는 14비트 주소 지정 필드를 제공하기 위해 다음 바이트와 연결되었습니다.실행 중인 코드는 어느 정도의 어휘 수준일 것입니다. 예를 들어 6: 이것은 단지 0에서 6까지의 어휘 수준만이 유효하다는 것을 의미하고, 따라서 원하는 어휘 수준을 지정하는 데 단지 3비트가 필요합니다.따라서 VALC 작업의 주소 부분은 이 목적을 위해 3비트만 예약하고 나머지는 그 이하 수준의 엔티티를 참조할 수 있습니다.깊이 중첩된 프로시저(따라서 높은 어휘 수준에서)는 개체를 식별하는 데 사용할 수 있는 비트 수가 적을 것입니다. 레벨 16의 경우 레벨 0-31 중 하나를 지정하려면 5비트가 필요하므로 9비트는 어휘 수준의 처음 512개 개체만 식별할 수 있습니다.32비트 주소 지정 공간에서 리터럴 메모리 주소로 엔티티를 주소 지정하는 것보다 훨씬 더 압축적입니다.또한 ADD, MULT 등에 대한 opcodes와 같은 VALCopcode 로드 데이터만 어드레싱하지 않았으며 스택의 상위 요소에 대해 전적으로 작업했습니다.

훨씬 더 중요한 것은 이 방법이 플랫 어드레싱을 사용하는 시스템에서 발생할 수 있는 많은 오류가 기계 코드 수준에서도 단순히 말할 수 없기 때문에 발생할 수 없다는 것을 의미한다는 것입니다.다른 작업에서 사용 중인 메모리를 손상시킬 방법이 없는 작업은 주소를 개발할 방법이 없기 때문입니다.지정된 D-register로부터의 오프셋은 스택 프레임 바운드와 비교하여 하드웨어가 검사합니다. 로그 값은 트랩됩니다.마찬가지로 작업 내에서 어레이 디스크립터는 어레이의 경계에 대한 정보를 포함하고 있으므로 모든 인덱싱 작업이 하드웨어에 의해 확인되었습니다. 즉, 각 어레이는 고유한 주소 공간을 형성합니다.어떤 경우든 모든 메모리 워드의 태깅은 두 번째 보호 수준을 제공했습니다. 잘못된 값 할당은 포인터나 배열 설명자 등을 포함하지 않고 데이터를 보관하는 위치에만 적용될 수 있으며 기계 코드를 보관하는 위치에는 적용되지 않습니다.

배열 저장소

배열은 다른 변수와 메모리에 연속적으로 저장되지 않았고, 각 배열에는 디스크립터를 통해 위치한 고유의 주소 공간이 부여되었습니다.액세스 메커니즘은 스택에서 인덱스 변수를 계산하고(따라서 14비트가 아니라 전체 정수 범위 전위를 갖는) 이를 배열의 주소 공간으로 오프셋으로 사용하여 하드웨어에서 제공하는 바인딩 검사를 수행하는 것이었습니다.기본적으로 배열의 길이가 1,024단어를 초과할 경우 배열은 세그먼트화되고 인덱스는 세그먼트 인덱스로 변환되고 오프셋은 인덱스된 세그먼트로 변환됩니다.그러나 선언에 배열을 LONG으로 지정하여 분할을 방지하는 옵션이 있었습니다.ALGOL의 경우, 다차원 배열은 그러한 주소 지정의 여러 수준을 사용할 것입니다.A[i,j]를 참조하기 위해 첫 번째 인덱스는 디스크립터 배열, A의 각 행에 대해 하나의 디스크립터로 구성되며, 그 다음 행은 단일 차원 배열의 경우 j로 인덱싱되며, 더 높은 차원의 경우 j로 인덱싱됩니다.배열의 모든 인덱스의 알려진 경계에 대해 하드웨어를 검사하면 잘못된 인덱싱을 방지할 수 있습니다.

그러나 FORTRAN은 모든 다차원 배열을 동일한 크기의 단일 차원 배열과 동일한 것으로 간주하며, 다차원 배열의 경우 단순 정수 산술을 사용하여 해당 단일 시퀀스에서 요소 A[i,j,k]가 발견될 수 있는 오프셋을 계산합니다.충분히 크다면 분할될 수도 있는 단일 차원 등가 배열은 ALGOL의 단일 차원 배열과 동일한 방식으로 액세스될 것입니다. 이 배열 외부에서 액세스하는 것은 방지되지만, 하나의 인덱스에 대해 잘못된 값이 다른 인덱스에 대해 적절하게 잘못된 값과 결합되면 si의 경계 위반을 초래하지 않을 수 있습니다.ngle sequence 배열. 즉, 인덱스가 개별적으로 확인되지 않았습니다.

어레이의 스토리지가 다른 항목에 대한 스토리지에 의해 각 면에 경계가 설정되지 않았기 때문에 시스템이 어레이의 "크기를 조정"하는 것은 쉬웠지만 컴파일러가 모든 참조에 동일한 개수의 치수를 요구했기 때문에 치수를 변경하는 것은 불가능했습니다.ALGOL의 경우, 이를 통해 일반적인 고정 직사각형(또는 고차원) 어레이가 아닌 "래그드" 어레이를 개발할)" 어레이를 개발할 수 있었습니다.따라서 2차원에서 누더기 배열에는 크기가 다른 행이 있습니다.예를 들어, 대부분 0인 값의 큰 어레이 A[100,100]가 주어졌을 때, SA[100,0]으로 선언된 희소 어레이 표현은 각 행이 해당 행을 따라 A의 0이 아닌 값만을 유지할 수 있는 정확하게 충분한 요소를 갖도록 크기가 조정될 수 있습니다.

1024단어보다 큰 어레이는 일반적으로 세그먼트화되었지만 작은 어레이는 실제 메모리가 부족한 시스템에서는 선언된 스크래치 패드 어레이의 크기를 1,000개에서 1개로 늘렸기 때문에,050은 메모리에 사용 중인 더 작은 개별 세그먼트만 필요하기 때문에 프로그램이 훨씬 적은 "쓰레싱"으로 실행된다는 것을 의미할 수 있습니다.어레이 세그먼트의 실제 스토리지는 해당 세그먼트의 요소에 액세스하는 경우에만 런타임에 할당되며, 생성된 세그먼트의 모든 요소는 0으로 초기화됩니다.따라서 처음에 배열을 0으로 초기화하지 않는 것은 일반적으로 현명하지 못한 누락으로 인해 권장되었습니다.

배열 동등성도 지원됩니다.ARY 선언은 모든 비트 패턴을 저장하는 데 사용할 수 있는 48 비트 데이터 워드의 할당을 요구했지만 일반적인 운영 방식은 할당된 각 워드를 REAL 피연산자로 간주하는 것이었습니다.다음의 선언:

어레이 A [0:99]

메모리의 REAL 데이터 공간 유형 100개의 워드 할당을 요청했습니다.프로그래머는 또한 다음과 같은 동등성 선언에 의해 메모리가 문자 지향 데이터로 지칭될 수 있음을 지정할 수 있습니다.

EBCDIC 어레이 EA [0] = A [*];

또는 동등성 선언을 통해 16진수 데이터로서:

HEX ARY HA [0] = A [*];

또는 동등성 선언을 통해 ASCII 데이터로서:

ASCII ARY AA[0] = A[*];

동등성 없이 데이터 유형별 어레이를 요청할 수 있는 기능도 지원됩니다.

EBCDIC ARY MY_EA [0:99]

시스템에서 100자 배열을 할당하도록 요청했습니다.아키텍처가 단어 기반이므로 할당된 실제 공간은 다음 전체 단어 경계로 반올림된 요청 문자 수이다.

컴파일 시 생성된 Data Descriptor(데이터 디스크립터)는 배열이 의도된 데이터 유형 사용량을 나타냅니다.배열 동등성 선언이 특정 사용 유형이 생성되었음을 나타내는 복사 설명자로 만들어졌지만 원래 또는 MOM을 가리키는 경우.따라서 메모리의 정확한 위치를 인덱싱하는 것은 항상 보장되었습니다.

Boolean 배열도 지원되며 비트 벡터로 사용할 수 있습니다.INTEGER 배열도 요청할 수 있습니다.

바로 앞의 논의는 ALGOL 구문 구현을 사용하여 ARY 선언을 설명하지만 COBOL과 FORTRAN에서는 동일한 기능을 지원합니다.

적층 구조의 장점

스택 구조의 한 가지 좋은 점은 프로그램이 실패하면 스택 덤프가 실행되고 프로그래머가 실행 중인 프로그램의 상태가 정확히 무엇인지 쉽게 알아낼 수 있다는 것입니다.이를 다른 시스템의 코어 덤프 및 교환 패키지와 비교합니다.

스택 구조에 대한 또 다른 점은 프로그램이 암묵적으로 재귀적이라는 것입니다.FORTRAN은 재귀를 지원하지 않을 것으로 예상되었으며, ALGOL이 어떻게 구현될 것인지에 대한 사람들의 이해를 방해하는 장애물 중 하나는 재귀를 구현하는 방법이었습니다.B5000에서는 이것이 문제가 되지 않았습니다. 사실 프로그램이 재귀적으로 작동하지 않도록 하는 방법과 반대의 문제가 있었습니다.결국 그들은 신경쓰지 않았습니다.Burroughs FORTRAN 컴파일러는 (다른 모든 FORTRAN 컴파일러들이 그러하듯이) 재귀적 호출을 허용했지만, 다른 많은 컴퓨터들과 달리 스택 기반 시스템에서는 이러한 호출의 반환도 성공했습니다.이것은 중앙 서브루틴이 다시 돌아오지 않고 반복적으로 서로를 호출하는 수학적 표현식의 공식적인 조작 시스템과 마찬가지로 이상한 효과를 가질 수 있습니다: 큰 작업은 스택 오버플로에 의해 종료되었습니다!

따라서 Burroughs FORTRAN은 다른 현대 ^{[citation needed]}구현 FORTRAN보다 오류 확인이 더 뛰어났습니다. 예를 들어 서브루틴 및 함수의 경우 ALGOL 스타일 컴파일러의 일반적인 경우와 마찬가지로 정확한 개수의 파라미터로 호출되었는지 확인했습니다.다른 컴퓨터에서는 이러한 불일치가 충돌의 일반적인 원인이었습니다.배열 경계 검사와 마찬가지로, 다른 시스템에서 수년간 사용되어 온 프로그램은 버로우즈 시스템에서 실행될 때 종종 실패합니다.실제로 Burroughs는 객체 지향 Simula(ALGOL의 상위 집합)를 포함한 우수한 컴파일러 및 언어 구현으로 유명해졌습니다. APL의 설계자인 Iverson은 Burroughs의 APL 구현이 그가 ^{[citation needed]}본 것 중 최고였다고 선언했습니다.LISP의 언어 설계자인 John McCarthy는 LISP가 수정 가능한^{[citation needed]} 코드를 기반으로 했기 때문에 B5000의^{[citation needed]} 수정 불가능한 코드를 좋아하지 않았지만 대부분의 LISP 구현은 해석적인 환경에서 실행될 것입니다.

여러 프로세스에 필요한 스토리지는 필요에 따라 시스템의 메모리 풀에서 나왔습니다.작업을 실행할 메모리 파티션을 미리 구성하기 위해 경쟁 시스템과 마찬가지로 Burroughs 시스템에서 SYSGEN을 수행할 필요가 없었습니다.

태깅 아키텍처

B5000의 가장 정의로운 점은 위에서 다룬 스택 머신이라는 점입니다.그러나 이 아키텍처의 다른 두 가지 중요한 특징은 태그 기반 및 설명자 기반이라는 것입니다.

원래 B5000에서는 각 컨트롤 또는 숫자^{[NB 7]} 단어의 플래그 비트가 따로 설정되어 해당 단어를 컨트롤 단어 또는 숫자 단어로 식별할 수 있었습니다.이것은 부분적으로 프로그램이 스택의 제어 단어를 손상시키는 것을 막기 위한 보안 메커니즘이었습니다.

나중에, B6500이 설계되었을 때, 1비트 제어 단어/숫자 구별이 강력한 아이디어라는 것을 알게 되었고, 이것은 48비트 단어에서 3비트 밖에서 태그로 확장되었습니다.데이터 비트는 비트 0-47이고 태그는 비트 48-50입니다.비트 48은 읽기 전용 비트이므로 홀수 태그는 사용자 수준 프로그램에서 쓸 수 없는 제어 단어를 나타냅니다.코드 워드에는 태그 3이 붙었습니다.다음은 태그 및 기능 목록입니다.

태그	단어 종류	묘사
0	데이터.	모든 종류의 사용자 및 시스템 데이터(텍스트 데이터 및 단일 정밀도 숫자)
2	더블	Double Precision 데이터
4	SIW	단계 색인 단어(루프에 사용)
6		초기화되지 않은 데이터
	SCW	소프트웨어 컨트롤 워드(스택 축소에 사용)
1	IRW	간접 참조어
	SIRW	박제된 간접 참조어
3	코드	프로그램코드워드
	MSCW	스택 컨트롤 워드 표시
	RCW	리턴 컨트롤 워드
	TOSCW	맨 위에 쌓기 제어 단어
	SD	세그먼트 설명자
5	디스크립터	데이터 블록 설명자
7	PCW	프로그램 컨트롤 워드

내부적으로, 일부 기계는 60비트 워드를 가지고 있었는데, 여분의 비트는 해밍 코드 오류 정정 필드와 같은 공학적 목적으로 사용되었지만, 프로그래머들은 이것을 결코 보지 못했습니다.

현재 이 기계들의 화신인 Unisys ClearPath는 태그를 4비트 태그로 더 확장했습니다.4개의 비트 태그를 지정한 마이크로코드 레벨을 레벨 감마(Gamma)라고 합니다.

짝수 태그된 단어는 사용자 프로그램이 사용자 상태로 수정할 수 있는 사용자 데이터입니다.홀수 태그가 붙은 단어는 하드웨어에서 직접 생성되고 사용되며 프로그램의 실행 상태를 나타냅니다.이 단어들은 특정 명령어 또는 하드웨어에 의해 생성되고 사용되므로, 시스템 단어 형식이 변경되었을 수 있지만 동일한 코드 스트림이 동일한 결과를 생성하므로 하드웨어 구현 간에 이 단어들의 정확한 형식이 변경될 수 있고 사용자 프로그램을 다시 컴파일할 필요가 없습니다.

태그 1 단어는 온스택 데이터 주소를 나타냅니다.일반 IRW는 현재 스택의 데이터에 대한 주소 커플을 저장합니다.SIRW는 주소에 스택 번호를 포함시켜 스택의 데이터를 참조합니다.그 중에서도 SIRW는 CALL 및 PROCESS 문에 응답하여 생성된 것과 같은 개별 프로세스 스택 간의 주소 지정을 제공하는 데 사용됩니다.

태그 5 단어는 다음 섹션에서 자세히 설명하는 설명자입니다.태그 5 단어는 오프스택 데이터 주소를 나타냅니다.

태그 7은 절차 진입점을 설명하는 프로그램 컨트롤 워드입니다.하드웨어 연산자가 PCW를 치면 절차가 들어갑니다.ENT 연산자가 명시적으로 프로시저(값 반환이 아닌 루틴)를 입력합니다.함수(값 반환 루틴)는 값 호출(VALC)과 같은 연산자에 의해 암묵적으로 입력됩니다.글로벌 루틴은 D[1] 환경의 코드 세그먼트 사전에 저장된 PCW를 가리키는 SIRW로서 D[2] 환경에 저장됩니다.D[1] 환경은 이 코드를 공유하는 모든 프로세스에서 참조할 수 있기 때문에 현재 스택에 저장되지 않습니다.따라서 코드가 다시 입력되고 공유됩니다.

태그 3은 스택에서 발생하지 않는 코드 워드 자체를 나타냅니다.태그 3은 스택 제어 단어 MSCW, RCW, TOSCW에도 사용됩니다.

디스크립터 기반 아키텍처

왼쪽 그림은 Burroughs Large System 아키텍처가 기본적으로 객체 지향 프로그래밍을 위한 하드웨어 아키텍처였음을 보여줍니다. 기존 아키텍처에는 여전히 존재하지 않는 것입니다.

명령어세트

Burroughs 대형 시스템에는 세 가지의 구별된 명령어 세트가 있습니다.세 가지 모두 단어에 골고루 맞는 짧은 음절에 기초를 두고 있습니다.

B5000, B5500 및 B5700

B5000, B5500, B5700의 프로그램은 4개에서 1개의 단어로 12비트 음절로 구성되어 있습니다.이 아키텍처에는 워드 모드와 캐릭터 모드의 두 가지 모드가 있으며, 각각은 음절의 레퍼토리가 따로 있습니다.프로세서는 Control State(제어 상태) 또는 Normal State(정상 상태) 중 하나일 수 있으며 특정 음절은 Control State(제어 상태)에서만 허용됩니다.아키텍처는 레지스터나 저장소를 직접 어드레싱하는 것을 제공하지 않습니다. 모든 참조는 1024 워드의 프로그램 참조 테이블, 현재 코드 세그먼트, 스택 내의 표시된 위치 또는 스택의 상위 두 위치를 보유하는 A 및 B 레지스터를 통합니다.버로우는 0(높은 비트)에서 11(낮은 비트)까지의 음절로 비트 수를 계산합니다.

B6500 및 그 후속 제품

프로그램은 8비트 음절로 구성되어 있으며, Name Call, Value Call 또는 1-12음절 길이의 연산자를 구성할 수 있습니다.연산자는 200개 미만으로 모두 8비트 음절에 들어맞습니다.이러한 연산자의 대부분은 태그에 의해 주어진 것처럼 작용되는 데이터의 종류에 따라 다형성됩니다.강력한 문자열 스캔, 전송 및 편집 연산자를 무시하면 기본 집합은 약 120개의 연산자에 불과합니다.MVST, HALT 등 운영체제에 예약된 연산자를 제거하면 사용자 수준의 프로그램에서 일반적으로 사용하는 연산자 집합은 100개 미만입니다.Name Call 및 Value Call 음절은 주소 쌍을 포함하며, Operator 음절은 주소를 사용하지 않거나 스택에서 제어 단어와 설명자를 사용합니다.

다중 프로세서

또한 B5000 라인은 두 개의 프로세서를 고속 버스에서 마스터와 슬레이브로 연결한 선구자이기도 합니다.B6000, B7000 및 B8000 라인에서는 프로세서가 대칭이었습니다.B7000 라인은 적어도 하나의 I/O 모듈이면 최대 8개의 프로세서를 가질 수 있습니다.RDLK(ReaD with LocK)는 프로세서 간의 동기화 수준이 매우 낮은 방식입니다.RDLK는 단일 주기로 동작합니다.일반적으로 사용자 프로그램에서 사용하는 상위 레벨 메커니즘은 EVENT 데이터 유형입니다.EVENT 데이터 형식에 시스템 오버헤드가 있습니다.이러한 오버헤드를 방지하기 위해 Dahm locks(Burroughs 소프트웨어 전문가인 Dave Dahm의 이름을 딴 Dahm locks)라는 특별한 잠금 기술을 사용할 수 있습니다.Dahmlocks는 코드 레벨에서 RDLK 연산자를 생성하는 READLOCK ALGOL 언어 문을 사용했습니다.

주목할 만한 연산자는 다음과 같습니다.

HEYU — 다른 프로세서에 인터럽트 전송
RDLK — 저수준 세마포어 연산자: A 레지스터에 주어진 메모리 위치를 A 레지스터에 로드하고 해당 메모리 위치에 있는 B 레지스터의 값을 단일 무정전 사이클로 배치합니다.알골 컴파일러는 명시적인 임시 값 없이 단일 단어 데이터에 대한 "스왑" 연산을 가능하게 하는 특수 함수를 통해 이 연산자를 호출하기 위한 코드를 생성했습니다.x:=RDLK(x,y);
WHOI — 프로세서 식별
IDLE — 인터럽트가 수신될 때까지 유휴 상태임

두 프로세서가 동시에 '헤이유(HEYU)' 명령을 전송하는 경우가 드물어 '치명적 포용'으로 알려진 잠금 상태가 발생할 수 있습니다.

B5000의 영향

B5000의 직접적인 영향은 B6500의 직접적인 후손인 메인프레임의 현재 유니시스 클리어패스(Unisys ClearPath) 범위에서 확인할 수 있는데, 메인프레임은 B5000의 영향을 받았으며 40년 동안 지속적인 개발이 이루어졌음에도 불구하고 여전히 MCP 운영체제를 보유하고 있습니다.B6500 아키텍처는 x86 명령어 집합을 네이티브 명령어 집합으로 실행하는 인텔 Xeon 프로세서에서 구축된 기계에 구현되었으며, 해당 프로세서에서 실행되는 코드는 B5000 명령어 집합을 에뮬레이트하기 때문에 현재 이 아키텍처는 에모드(에뮬레이션 모드의 경우)라고 불립니다.그 기계들에는 엔모드(네이티브 모드)도 있을 예정이었지만, 이것이^{[citation needed]} 떨어졌기 때문에 종종 B6500 후속 기계들을 "모드 기계"라고 부르는 소리를 들을 수 있습니다.

B5000 기계는 고급 언어로만 프로그래밍되었으며, 어셈블러는 없습니다.

B5000 스택 아키텍처는 프로그래밍 언어 Forth의 디자이너 Chuck Moore에게 영감을 주었습니다. 그는 MIT에서 B5500을 접하게 되었습니다.Forth - The Early Years에서 Moore는 Forth의 DUP, DROP 및 SWAP가 해당 B5500 지침(DUPL, DLET, EXCH)에서 나온 것이라고 언급하며 그 영향에 대해 설명했습니다.

스택 기반 아키텍처와 태그 메모리를 갖춘 B5000 머신은 메인프레임과 슈퍼컴퓨터의 소련 엘브루스 시리즈에도 큰 영향을 미쳤습니다.이 시리즈의 첫 두 세대는 상위 언어로만 프로그래밍된 태그 메모리와 스택 기반 CPU를 특징으로 합니다.그들을 위한 일종의 어셈블리 언어인 El-76이 존재했지만, 그것은 ALGOL 68을 다소 변형한 것이었고 구조화된 프로그래밍과 1급 절차를 지원했습니다.그러나 이후 세대의 시리즈는 이 아키텍처에서 EPIC와 같은 VLIW CPU로 전환되었습니다.

HP 3000 비즈니스 시스템의 Hewlett-Packard 설계자들은 B5500을 사용했으며 하드웨어와 소프트웨어에 큰 감명을 받았습니다. 그들은 유사한 소프트웨어로 16비트 미니 컴퓨터를 만드는 것을 목표로 삼았습니다.다른 여러 HP 부서에서는 유사한 미니 컴퓨터 또는 마이크로프로세서 스택 머신을 만들었습니다.Bob Barton의 역폴란드 표기법(RPN)에 대한 연구는 9100A를 시작으로 HP 계산기, 특히 HP-35 및 그 이후의 계산기로도 발전했습니다.

1970년대 후반과 1980년대 초반에 Tandem Computers가 설계한 NonStop 시스템도 16비트 스택 머신으로, 초기 Tandem 엔지니어 중 일부가 이전에 HP와 함께 있었기 때문에 HP 3000 연결을 통해 간접적으로 B5000의 영향을 받았습니다.1990년경에 이 시스템들은 MIPS RISC 아키텍처로 마이그레이션되었지만 객체 코드 변환이나 직접 에뮬레이션을 통해 스택 머신 바이너리 실행을 계속 지원했습니다.2000년 이후 얼마 동안 이 시스템들은 Itanium 아키텍처로 마이그레이션되어 레거시 스택 머신 바이너리를 계속 실행했습니다.

밥 바튼은 앨런 케이에게도 매우 영향력이 있었습니다.Kay는 또한 B5000의 데이터 기반 태그 부착 아키텍처에 깊은 인상을 받았으며, 이는 객체 지향 프로그래밍 및 스몰토크의 ^{[citation needed]}발전 과정에서 그의 사고에 영향을 미쳤습니다.

B5000 아키텍처의 또 다른 측면은 하드웨어에서 직접 실행되는 안전한 아키텍처라는 점이었습니다.이 기술은 오늘날의 가상^{[citation needed]} 시스템에서 안전한 환경을 제공하려는 시도를 하고 있습니다.이러한 제품 중 주목할 만한 것은 애플리케이션이 실행되는 안전한 샌드박스를 제공하는 Java JVM입니다.

모드 이전에 존재했던 하드웨어-아키텍처 바인딩의 가치는 MCP가 유일한 제어 프로그램일 정도로 x86 기반 머신에 상당히 보존될 것이지만, 해당 머신이 제공하는 지원은 B6500 명령어 세트가 네이티브 명령어 세트인 머신에 제공되는 지원보다 여전히 떨어집니다.x86 명령어 세트의 32비트 구현 이전에 실제로 존재했던 잘 알려지지 않은 인텔 프로세서 아키텍처인 Intel iAPX 432는 본질적으로 객체 지향 아키텍처였기 때문에 동등한 물리적 기반을 제공했을 것입니다.

참고 항목

• 버로우즈 미디엄 시스템
• 버로우즈 소규모 시스템
• CANDE
• 네트워크 정의 언어(NDL)
• 워크플로우 언어(WFL)
• 팔각 부동점

메모들

참고문헌

이 기사는 검증을 위해 추가적인 인용이 필요합니다. 신뢰할 수 있는 자료에 인용문을 추가하여 이 기사를 개선하는 데 도움을 주시기 바랍니다. 출처가 밝혀지지 않은 자료에 이의를 제기하여 제거할 수 있습니다.출처 찾기: "Burroughs Large Systems" – 뉴스·신문·도서·학자·JSTOR (2009년 11월) (이 템플릿 메시지를 제거하는 방법 및 시기 알아보기)

• 확장된 알골 프라이머 (3권), 도날드 J. 그레고리
• 컴퓨터 건축: 구조화된 접근법, R. Doran, Academy Press (1979)
• 컴퓨터 쌓기: The New Wave, Philip J. Koopman, 다음 사이트에서 만나보세요: [1]
• B5500, B6500, B6700, B6800, B6900, B7700 설명서: bitsavers.org

추가열람

• Barton, Robert S. "디지털 컴퓨터의 기능적 설계에 대한 새로운 접근" 서부 공동 컴퓨터 회의의 절차.ACM (1961).
• 버로우즈 B 5000 구술 역사, 찰스 배비지 연구소, 미네소타 대학교Burroughs 5000 컴퓨터 시리즈는 AFIPS and Burroughs Corporation이 후원한 1985년 컨퍼런스에서 1957년부터 1960년대까지 개발 및 마케팅을 담당한 사람들에 의해 논의되었습니다.
• Gray, George (March 1999). "Some Burroughs Transistor Computers". Unisys History Newsletter. 3 (1). Archived from the original on October 1, 2016.
• Gray, George (October 1999). "Burroughs Third-Generation Computers". Unisys History Newsletter. 3 (5). Archived from the original on September 26, 2017.
• Hauck, E.A., Dent, Ben A. "Burroughs B6500/B7500 Stack Mechanism", SJCC(1968) 페이지 245-251.
• 맥키먼, 윌리엄 M. "언어 지향 컴퓨터 디자인", 가을 공동 컴퓨터 회의, (1967) pp. 413-417
• Organick, Elliot I. "컴퓨터 시스템 조직 B5700/B6700 시리즈", Academy Press (1973).
• Waychoff, Richard, "B5000과 그곳에 있었던 사람들의 이야기", 1979년 9월 27일 [2]
• 다들 그래, 잭."Burroughs B5900 및 E-Mode A 브리지 투 21세기 컴퓨팅", 2018년 개정.
• 마틴, 이안. "시대를 앞서가는 것: 1960년대 영국, 버로우즈 및 실시간 은행업", 기술 역사 학회 연례 회의, 2010년 9월 20일-3일, 미국 타코마.

외부 링크

• 이안 조이너의 버로우즈 페이지
• Burroughs B5900과 E-Mode: 21세기 컴퓨팅의 다리 - Jack Allweiss
• (웹 아카이브:) Ralph Kliemk on the B7800 on the Monash University
• 버지니아 대학교 컴퓨터 박물관의 "얼리 버로우즈 머신".
• "컴퓨터 시스템 조직", ACM 모노그래프 시리즈.
• B8500 매뉴얼 색인
• B5500 에뮬레이션 프로젝트는 Burroughs B5500 컴퓨터 시스템을 위한 기능적 에뮬레이터를 만드는 프로젝트입니다.
• "Burroughs B6500 필름 & 녹취록"