Burroughs büyük sistemler - Burroughs large systems

Bu makalenin ton veya stil, ansiklopedik ton Wikipedia'da kullanıldı. Wikipedia'ya bakın daha iyi makaleler yazma rehberi öneriler için. (Ağustos 2020) (Bu şablon mesajını nasıl ve ne zaman kaldıracağınızı öğrenin)

Burroughs Büyük Sistemler Grubu büyük bir aile üretti 48 bit anabilgisayarlar kullanma yığın makinesi yoğun komut setleri heceler.^{[NB 1]} Ailenin ilk makinesi 1961'de B5000'di. Derleme için optimize edildi ALGOL 60 tek geçişli derleyiciler kullanarak son derece iyi programlar. B5500'e dönüştü. Sonraki büyük yeniden tasarımlar arasında B6500 / B6700 serisi ve halefleri ile ayrı B8500 hattı yer alıyor.

1970'lerde Burroughs Corporation üst düzey, orta düzey ve giriş düzeyi iş bilgisayar sistemleri için çok farklı ürün grubu mimarilerine sahip üç bölüm halinde organize edildi. Her bölümün ürün grubu, bir bilgisayarın talimat setinin belirli programlama dilleri için nasıl optimize edileceğine dair farklı bir konseptten gelişti. "Burroughs Large Systems", tüm bu büyük sistem ürün gruplarına birlikte atıfta bulunurken, COBOL optimize edilmiş Orta Sistemler (B2000, B3000 ve B4000) veya esnek mimari Küçük Sistemler (B1000).

Arka fon

1880'lerde kurulan Burroughs, bilgi işlem alanında sürekli çalışan en eski şirkettir (Elliott Kardeşler Burroughs'tan önce kuruldu, ancak 19. yüzyılda bilgi işlem cihazları üretmedi). 1950'lerin sonlarında, bilgisayar ekipmanı hala elektromekanik ekipmanla sınırlıydı. muhasebe makineleri benzeri Sensimatic. Geleneksel rakipleriyle rekabet edecek hiçbir şeyi yoktu IBM ve NCR, daha büyük ölçekli bilgisayarlar üretmeye başlayan veya yeni kurulan Univac. 1956'da 3. taraf bir şirket satın aldılar ve tasarımını B205 olarak yeniden adlandırdılar.

Burroughs'un ilk dahili olarak geliştirilen makinesi olan B5000, 1961'de tasarlandı ve Burroughs, o zamanki en gelişmiş bilgi işlem fikirlerine dayalı tamamen farklı bir tasarım stratejisiyle pazara geç girişini ele almaya çalıştı. B5000 mimarisi ölürken, B6500'e (ve ardından B6700 ve B7700'e) ilham verdi. Bu mimariyi kullanan bilgisayarlar^{[kaynak belirtilmeli ]} olarak hala üretimde Unisys ClearPath Libra sunucularının gelişmiş ancak uyumlu bir sürümünü çalıştıran MCP işletim sistemi ilk olarak B6700 ile tanıtıldı. Üçüncü ve en büyük seri olan B8500,^[1][2] ticari başarısı yoktu. Tescilli bir CMOS işlemci tasarımı, Unisys ayrıca Intel Xeon işlemciler ve çalıştırmalar MCP, Microsoft Windows ve Linux Libra sunucularındaki işletim sistemleri; özel yongaların kullanımı kademeli olarak ortadan kaldırıldı ve 2018 yılına kadar Libra sunucuları birkaç yıldır kesinlikle Intel emtia oldu.

B5000

İlk serinin ilk üyesi olan B5000,^[3] 1961'den başlayarak, liderliğinde bir ekip tarafından tasarlandı Robert (Bob) Barton. Zamanının çok ötesinde eşsiz bir makineydi. Etkili bilgi işlem bilimcisi tarafından listelenmiştir John Mashey en hayran olduğu mimarilerden biri olarak. "Her zaman gördüğüm birleşik donanım / yazılım tasarımının en yenilikçi örneklerinden biri olduğunu ve zamanının çok ötesinde olduğunu düşündüm."^[4] B5000'in yerini B5500 aldı^[5] (tambur depolama yerine diskleri kullanan) ve B5700 (birden fazla CPU'nun paylaşılan disk etrafında kümelenmesine izin veren). B5700'ün halefi olmamasına rağmen, B5000 serisi B6500'ün tasarımını büyük ölçüde etkiledi ve Burroughs, Master Kontrol Programı (MCP) o makineye.

Benzersiz özellikler

• Tüm kod otomatik olarak giriş (ACM Monograf gösterilerinden şekil 4.5 kısaca neden): programcıların, herhangi bir dilde herhangi bir koda sahip olmak için işlemcilere yayılması için yalnızca gösterilen iki basit ilkeyi kullanmaktan daha fazla bir şey yapmaları gerekmez. Bu belki de kanoniktir, ancak bu mimarinin bu önemli ayırt edici özelliklerinin tek faydası değildir:
  • Kısmen veriye dayalı etiketli ve tanımlayıcı tabanlı tasarım
  • Donanım, yazılım gereksinimlerini desteklemek için tasarlanmıştır
  • Özel olarak desteklemek için tasarlanmış donanım üst düzey programlama dilleri
  • Hayır Assembly dili veya assembler; geniş bir yelpazede yazılmış tüm sistem yazılımı ALGOL 60. Ancak, ESPOL mimarideki hecelerin her biri için ifadeler vardı.
  • Birkaç programcı tarafından erişilebilen kayıt
  • Basitleştirilmiş komut seti
  • Yığın makinesi tüm işlemlerin açık işlenenler yerine yığını kullandığı
  • Tüm kesintiler ve prosedür çağrıları yığını kullanır
  • Üst düzey destek işletim sistemi (MCP, Master Kontrol Programı )
• İçin destek asimetrik (köle başı) çoklu işlem
• Gibi diğer diller için destek COBOL
• Güçlü dizi manipülasyonu
• Verilere yetkisiz erişimi veya işlemlerin kesintiye uğramasını yasaklayan güvenli bir mimari girişimi^{[NB 2]}
• Yazılımın geliştirilmesini ve test edilmesini destekleyen erken hata tespiti
• Sanal belleğin ilk ticari uygulaması^{[NB 3]}
  İlk bölümlenmiş bellek modeli
• Halefler hala var Unisys ClearPath / MCP makineleri
• Günümüzün bilgi işlem tekniklerinin çoğunu etkiledi

Aşağıdaki tartışmada, B5000 ve B8500 hatlarının özelliklerini ve konseptlerini B6500 serisi ile gereksiz yere birleştirmesine rağmen, makine tanımlamaları, B5000, A Serisi ve ClearPath / MCP birbirinin yerine kullanılmaktadır.

Benzersiz sistem tasarımı

B5000, mimarinin ve talimat setinin yazılım ihtiyaçları dikkate alınarak tasarlandığı dönemde devrim niteliğindeydi. Bu, bir işlemcinin ve onun talimat setinin tasarlanacağı ve ardından yazılım çalışanlarına teslim edileceği zamanın bilgisayar sistemi tasarımından büyük bir sapmaydı ve hala da öyle. Diğer bir deyişle, diğer birçok yönerge kümesi, örneğin IBM System / 360 o dönemin komut seti ve daha sonraki komut seti tasarımları x86, TBÖ, ve KOL komut seti mimarileri, orijinal Burroughs sistemleri gibi bütünsel tasarımlardan ziyade, esasen geleneksel komut seti tabanlı mimarilerdir.

Kelime Modundaki B5000, B5500 ve B5700, bir ana programı (SALF kapalı) veya bir alt rutini (SALF açık) yürütmesine bağlı olarak iki farklı adresleme moduna sahiptir. Bir ana program için, bir Operand Çağrısı veya Tanımlayıcı Çağrısı hecesinin T alanı Program Referans Tablosu (PRT) ile ilişkilidir. Alt yordamlar için, adresleme türü, gösterildiği gibi yüksek üç T bitine ve Mark Stack FlipFlop'a (MSFF) bağlıdır. B5x00 Bağıl Adresleme.

Dil desteği

B5000, özellikle yüksek seviyeli dilleri desteklemek için tasarlanmıştır. Bu, bu tür dillerin sadece ön plana çıktığı bir zamandı. FORTRAN ve daha sonra COBOL. FORTRAN ve COBOL, modern yazılım tekniklerine gelince, bazıları tarafından daha zayıf diller olarak kabul edildi, bu nedenle daha yeni, çoğunlukla denenmemiş bir dil benimsendi, ALGOL-60. B5000 için seçilen ALGOL lehçesi Elliott ALGOL, ilk olarak tarafından tasarlandı ve uygulandı C.A.R. Hoare bir Elliott 503. Bu, G / Ç talimatları (ALGOL'un görmezden geldiği) ve güçlü dizi işleme talimatlarıyla birlikte ALGOL'un pratik bir uzantısıydı. Turing Ödülü ders bu konudaydı.

Böylece B5000 çok güçlü bir dile dayanıyordu. Diğer satıcıların çoğu yalnızca bir ALGOL derleyicisini uygulamayı hayal edebilirdi^{[şüpheli – tartışmak]} ve sektördeki çoğu, ALGOL'u uygulanamaz olduğu için reddetti.^{[kaynak belirtilmeli ]} Ancak adında parlak genç bir öğrenci Donald Knuth önceden uygulanmıştı ALGOL 58 Yaz tatilinin üç ayı boyunca daha önceki bir Burroughs makinesinde ve çevresel olarak B5000 tasarımında danışman olarak yer aldı. Birçoğu, yanlışlıkla yüksek seviyeli dillerin assembler ile aynı güce sahip olamayacağına inanan ve bu nedenle ALGOL'un bir sistem programlama dili olarak potansiyelini fark edemeyen ALGOL'u yazdı.

Burroughs ALGOL derleyicisi çok hızlıydı - bu Hollandalı bilim adamını etkiledi Edsger Dijkstra B5000 Pasadena fabrikasında derlenmek üzere bir program sunduğunda. Kart destesi neredeyse anında derlendi ve hemen üniversitesi için birkaç makine istedi, Eindhoven Teknoloji Üniversitesi Hollanda'da. Derleyici birkaç nedenden ötürü hızlıydı, ancak birincil nedeni, tek geçişli derleyici. İlk bilgisayarların kaynak kodunu depolamak için yeterli belleği yoktu, bu nedenle derleyicilerin (ve hatta derleyicilerin) genellikle kaynak kodunu birden fazla kez okuması gerekiyordu. Burroughs ALGOL sözdizimi, resmi dilden farklı olarak, her değişkenin (veya diğer nesnenin) kullanılmadan önce bildirilmesini gerektirir, bu nedenle verileri yalnızca bir kez okuyan bir ALGOL derleyicisi yazmak mümkündür. Bu kavramın derin teorik çıkarımları vardır, ancak aynı zamanda çok hızlı derlemeye de izin verir. Burroughs'un büyük sistemleri, kaynak kodunu okuyabildiği kadar hızlı derleyebilir. delikli kartlar ve sektördeki en hızlı kart okuyucularına sahipler.

Güçlü Burroughs COBOL derleyicisi aynı zamanda tek geçişli bir derleyiciydi ve eşit derecede hızlıydı. 1000 kart / dakika okuyucuların kodu okuyabildiği kadar hızlı derlenen 4000 kartlı bir COBOL programı. Kartlar okuyucudan geçer geçmez program kullanıma hazırdı.

Şekil 4.5 Referanslardaki ACM Monografından. Elliot Organick 1973.

B6500 ve B7500

B6500^[7] (1969'da teslimat^[8][9]) ve B7500, Burroughs sistemlerinin günümüze kadar ayakta kalan tek serisindeki ilk bilgisayarlardı. B5000'den ilham alırken, tamamen yeni bir mimariye sahiplerdi. En önemli farklar arasında şunlar vardı:

• B6500, değişken uzunluklu talimatlara sahipti. 8 bitlik hece ile sabit uzunlukta talimatlar yerine 12 bitlik hece.
• B6500, 51 bitlik bir^{[NB 4]} 48 bitlik bir kelime yerine ve 3 biti bir etiket
• B6500 vardı Simetrik Çoklu İşlem (SMP)
• B6500'de bir Saguaro yığını
• B6500 sayfalı dizilere sahipti
• B6500 vardı Ekran Kayıtları, D1 - D32 iç içe geçmiş alt rutinlerin dış bloklardaki değişkenlere erişmesine izin vermek için.
• B6500 monolitik kullandı Entegre devreler manyetik ile ince film hafızası.^[8]

B6700 ve B7700

Diğer müşteriler arasında 1971'de beş Yeni Zelanda üniversitesi vardı.^[10]

B8500

B8500^[1][2] çizgi D825'ten türemiştir,^[11] B5000'den ilham alan bir askeri bilgisayar.

B8500, 1960'larda B5500 ve D825 tasarımlarını birleştirme girişimi olarak tasarlandı. Sistem monolitik kullandı Entegre devreler manyetik ile ince film hafızası. Mimari, 48 bitlik bir kelime, yığın ve B5500 gibi tanımlayıcılar kullandı, ancak yukarı doğru uyumlu olduğu ilan edilmedi.^[1] B8500 hiçbir zaman güvenilir bir şekilde çalıştırılamadı ve proje 1970'den sonra iptal edildi ve hiçbir zaman tamamlanmış bir sistem teslim etmedi.^[2]

Tarih

Bu bölüm genişlemeye ihtiyacı var. Yardımcı olabilirsiniz ona eklemek. (Haziran 2008)

Aşağıdaki tartışmada, B5000 ve B8500 hatlarının özelliklerini ve konseptlerini B6500 serisi ile gereksiz yere birleştirmesine rağmen, makine tanımlamaları, B5000, A Serisi ve ClearPath / MCP birbirinin yerine kullanılmaktadır.

Ana konsept sanal bellek tasarımlarında yer aldı Ferranti Atlas ve Rice Institute Bilgisayar ve tanımlayıcıların ve etiketli mimarinin temel kavramları, Rice Enstitüsü Bilgisayarının tasarımında ortaya çıktı.^[12] 1950'lerin sonlarında. Ancak, bu tasarımların Burroughs üzerinde doğrudan bir etkisi olsa bile, B5000, B6500 ve B8500'ün mimarileri Atlas ve Rice makinesinin mimarilerinden çok farklıydı; onlar da birbirlerinden çok farklılar.

Burroughs büyük sistemlerinden ilki B5000 idi. 1961'de tasarlanan bu ikinci nesil bilgisayardı ayrık transistör mantık ve manyetik çekirdek hafızası. B5000 mimarisinin yerini alan ilk makineler B6500 ve B7500 idi. Halefi makineler, B5500, B6500, B5700, B6700, B7700, B6800, B7800 ve son olarak Burroughs A serisi ile önümüzdeki 25 yıl içinde mimarileri yeni mantıkta yeniden uygulamak için donanım geliştirme eğilimlerini takip etti. Burroughs'un satın aldığı bir birleşmeden sonra Sperry Corporation ve adını değiştirdi Unisys şirket, temel alınarak yeni makineler geliştirmeye devam etti. MCP CMOS ASIC. Bu makineler, Libra 500 boyunca Libra 100 idi ve Libra 590, 2005'te duyuruldu. 590 da dahil olmak üzere daha sonraki Teraziler, Intel Xeon işlemcileri de içerir ve Burroughs'un büyük sistem mimarisini öykünmede ve MCP CMOS işlemcilerde çalıştırabilir . Unisys'in yeni MCP CMOS ASIC'leri geliştirmeye devam edip etmeyeceği belli değil.

Birincil donanım hatları

Donanım ve yazılım tasarımı, geliştirme ve üretim, Orange County, Kaliforniya ve eteklerinde Philadelphia. B5000 ve B5500'ü geliştiren ilk Büyük Sistemler Fabrikası, Pasadena, Kaliforniya ama taşındı City of Industry, California, B6500'ü geliştirdiği yer. Orange County bölgesi Mission Viejo, Kaliforniya ancak bazen yakındaki tesisler dahil Irvine ve Göl Ormanı, daha küçük B6x00 hattından sorumluyken, Doğu Kıyısı operasyonları Tredyffrin, Pensilvanya, daha büyük B7x00 serisini ele aldı. Her iki hattaki tüm makineler tamamen nesne uyumluydu, yani biri üzerinde derlenen bir program diğerinde yürütülebilirdi. Daha yeni ve daha büyük modeller, daha eski ve daha yavaş modellerde desteklenmeyen talimatlara sahipti, ancak donanım, tanınmayan bir talimatla karşılaştığında, onu yorumlayan bir işletim sistemi işlevini çağırdı. Diğer farklılıklar arasında süreç değiştirme ve G / Ç'nin nasıl işlendiği ve bakım ve soğuk çalıştırma işlevi yer alır. Daha büyük sistemler, donanım süreci planlamasını ve daha yetenekli giriş / çıkış modüllerini ve daha yüksek düzeyde işlevsel bakım işlemcilerini içeriyordu. Bxx00 modelleri A Serisi modellerle değiştirildiğinde, farklılıklar korundu ancak artık model numarasıyla kolayca tanımlanamıyordu.

Algol

Burroughs büyük sistemleri ALGOL türevi bir yığın mimarisi. B5000, yığın tabanlı ilk sistemdi.

B5000, ALGOL'u desteklemek için özel olarak tasarlanmış olsa da, bu yalnızca bir başlangıç ​​noktasıydı. COBOL gibi diğer iş odaklı diller de, özellikle hızlı derleyicilerin geliştirilmesi için dahil edilen güçlü dizgi operatörleri tarafından iyi desteklendi.

B5000'de kullanılan ALGOL, genişletilmiş bir ALGOL alt kümesidir. Güçlü dizi işleme talimatlarını içerir, ancak belirli ALGOL yapılarını, özellikle belirtilmemiş biçimsel parametreleri hariç tutar. DEFINE mekanizması, benzer bir amaca hizmet eder. #defines C'de bulunur, ancak bir önişlemci olmaktan çok dile tam olarak entegre edilmiştir. EVENT veri türü, süreçler arasındaki koordinasyonu kolaylaştırır ve ON FAULT blokları program hatalarının ele alınmasını sağlar.

ALGOL'un kullanıcı seviyesi, işletim sistemi ve diğer sistem yazılımı tarafından ihtiyaç duyulan güvensiz yapıların çoğunu içermez. İki seviyeli dil genişletme ek yapıları sağlar: MCP ve yakından ilgili yazılımları yazmak için ESPOL ve NEWP ve belirli sistem yazılımı türleri için daha spesifik uzantılar sağlamak için DCALGOL ve DMALGOL.

ESPOL ve NEWP

Başlangıçta, B5000 MCP işletim sistemi, genişletilmiş ALGOL'un bir uzantısı olarak yazılmıştır. ESPOL (Yönetici Sistemleri Programlamaya Yönelik Dil). Bu, 70'lerin ortalarında ve sonlarında adı verilen bir dil ile değiştirildi. YENİ P. NEWP muhtemelen "Yeni Programlama dili" anlamına gelse de, adı efsaneler çevreliyor. Burroughs içinde yer alan yaygın (belki de uydurma) bir hikaye, hikayenin "Yönetici Tuvalet Ayrıcalıkları Yok. " Başka bir hikaye de, 1976 dolaylarında, Burroughs'tan John McClintock (NEWP'yi geliştiren yazılım mühendisi) diline "NEWP" adını verdiği sorulduğunda, yine "bunun bir adı var mı": "nyoooop" cevabını vererek bunu bir isim. NEWP de bir ALGOL alt kümesiydi, ancak ESPOL'den daha güvenliydi ve ALGOL'un az kullanılan bazı karmaşıklıklarını düşürdü. Aslında, tüm güvenli olmayan yapılar, bir blok bu talimatlara izin verecek şekilde özel olarak işaretlenmedikçe NEWP derleyicisi tarafından reddedilir. Bu tür blok işaretlemesi, çok seviyeli bir koruma mekanizması sağlar.

Güvenli olmayan yapılar içeren NEWP programları başlangıçta yürütülemez. Bir sistemin güvenlik yöneticisi bu tür programları "kutsayabilir" ve çalıştırılabilir hale getirebilir, ancak normal kullanıcılar bunu yapamaz. (Normalde kök ayrıcalığına sahip olan "ayrıcalıklı kullanıcılar" bile site tarafından seçilen yapılandırmaya bağlı olarak bunu yapamayabilir.) NEWP genel programlar yazmak için kullanılabilir ve büyük yazılım projeleri için tasarlanmış bir dizi özelliğe sahiptir. , ALGOL'un yaptığı her şeyi desteklemiyor.

NEWP, adlandırılmış arabirimler (işlevler ve veriler), arabirim grupları, modüller ve süper modüller dahil olmak üzere işletim sistemi gibi büyük ölçekli yazılım projelerini etkinleştirmek için bir dizi tesise sahiptir. Modüller, verileri ve işlevleri birlikte gruplandırarak, modül içinde genel olarak verilere kolay erişim sağlar. Arayüzler, bir modülün fonksiyonları ve verileri içe ve dışa aktarmasına izin verir. Süper modüller, modüllerin gruplanmasına izin verir.

DCALGOL ve Mesaj Kontrol Sistemleri (MCS)

İşletim sistemi kodu (NEWP'de) ve kullanıcı programları (ALGOL'de) arasındaki ikinci orta düzey güvenlik, ara yazılım DCALGOL ile yazılmış programlar (veri iletişimleri ALGOL). Bu, mesajları giriş kuyruklarından kaldıran ve sistemdeki diğer işlemlerin işlemesi için kuyruklara yerleştiren mesaj alımı ve dağıtımı için kullanılır. COMS gibi ara yazılımlar (1984'te tanıtıldı), ağın her yerinden mesajlar alır ve bu mesajları belirli işleme süreçlerine veya CANDE gibi bir MCS'ye (Mesaj Kontrol Sistemi) gönderir ("Command VE Edit, "program geliştirme ortamı).

MCS'ler kayda değer yazılım öğeleridir - kullanıcı oturumlarını kontrol ederler ve tek bir MCS yığını birçok kullanıcı tarafından paylaşılabildiğinden, kullanıcı başına işlemleri çalıştırmak zorunda kalmadan kullanıcı durumunun izlenmesini sağlarlar. Yük dengeleme, MCS düzeyinde de gerçekleştirilebilir. Örneğin, yığın başına 30 kullanıcıyı işlemek istediğinizi söyleyerek, bu durumda 31 ila 60 kullanıcınız varsa, iki yığın, 61 ila 90 kullanıcı, üç yığın vb. Var. Bu, B5000 makinelerine bir makinede büyük bir performans avantajı sağlar. sunucu, çünkü başka bir kullanıcı işlemini başlatmanız gerekmez ve böylece bir kullanıcı sisteme her eklendiğinde yeni bir yığın oluşturmanız gerekir. Böylece, MCS'ler ile kullanıcılara verimli bir şekilde hizmet verebilirsiniz (duruma gerek duysunlar veya olmasınlar). MCS'ler ayrıca büyük ölçekli işlem işlemenin omurgasını sağlar.

MCS, harici bir yardımcı işlemci olan DCP (Datacomm Control Processor) ile konuştu. Bu, geleneksel yazmaç mimarisine ve binlerce uzak terminali işleyebilen donanım I / O özelliğine sahip 24 bitlik bir mini bilgisayardı. DCP ve B6500, hafızadaki mesajlarla, esasen bugünün paketleriyle iletişim kurdu ve MCS, bu mesajların B6500 tarafı işlemesini gerçekleştirdi. İlk yıllarda DCP'nin B6500 ALGOL ile yazılmış DCPProgen adlı bir uygulama programı olan bir assembler (Dacoma) vardı. Daha sonra NDL (Ağ Tanımlama Dili) derleyicisi DCP kodunu ve NDF'yi (ağ tanımlama dosyası) oluşturdu. Her DCP talimatı türü için bir ALGOL fonksiyonu vardı ve eğer bu fonksiyonu çağırdıysanız, o zaman ilgili DCP komut bitleri çıkışa gönderilecektir. Bir DCP programı, her bir assembly dili deyimi için bir tane olmak üzere, bu işlevlerle ilgili uzun bir çağrı listesinden başka hiçbir şey içermeyen bir ALGOL programıdır. Esasen ALGOL, bir makro birleştiricinin makro geçişi gibi davrandı. İlk geçiş ALGOL derleyicisiydi; ikinci geçiş, sonuçtaki programı (B6500'de) çalıştırıyordu ve bu da daha sonra DCP için ikili dosyayı yayacaktı.

DMALGOL ve veritabanları

ALGOL'un bir başka çeşidi de DMALGOL (Veri Yönetimi ALGOL). DMALGOL, DMSII veritabanı yazılımını DASDL (Veri Erişimi ve Yapı Tanımlama Dili) derleyicisi tarafından oluşturulan veritabanı tanımlama dosyalarından derlemek için genişletilmiştir. Veritabanı tasarımcıları ve yöneticileri, belirtilen tablolar ve dizinler için özelleştirilmiş DMALGOL kodu oluşturmak için veritabanı açıklamalarını derler. Yöneticilerin hiçbir zaman DMALGOL'u kendilerinin yazması gerekmez. Normal kullanıcı seviyesindeki programlar, veritabanı talimatları ve işlem işleme direktifleri ile genişletilmiş uygulama dillerinde, özellikle ALGOL ve COBOL'de yazılmış kodu kullanarak veritabanı erişimi elde eder. DMALGOL'un en dikkate değer özelliği, tabloları ve endeksleri işlemek için kod üretmek için ön işleme mekanizmalarıdır.

DMALGOL ön işleme, değişkenleri ve döngüleri içerir ve derleme zamanı değişkenlerine dayalı adlar oluşturabilir. Bu, döngüleri olmayan ön işleme tesisleri tarafından yapılabileceklerin çok ötesine geçmeyi sağlar.

DMALGOL, aşağıdakiler için özel erişim rutinleri sağlamak için kullanılır: DMSII veritabanları. Veri Erişim ve Yapı Tanımlama Dili (DASDL) kullanılarak bir veritabanı tanımlandıktan sonra, şema ön işlemci tarafından özel DMALGOL erişim rutinlerine çevrilir ve ardından derlenir.Bu, diğer DBMS uygulamalarından farklı olarak, genellikle veritabanına ihtiyaç olmadığı anlamına gelir. -specific if / then / else kodu çalışma zamanında. 1970'lerde, bu "uyarlama" kod ayak izini ve yürütme süresini azaltmak için çok yaygın bir şekilde kullanıldı. Daha sonraki yıllarda çok daha az kullanıldı, çünkü kısmen bellek ve hız için düşük seviyeli ince ayar daha az kritik hale geldi ve kısmen de ön işlemenin kaldırılması kodlamayı daha basit hale getirdi ve böylece daha önemli optimizasyonları mümkün kıldı. DMALGOL, "bul", "kilitle", "sakla" gibi fiilleri içeriyordu. Ayrıca, birden çok işlem aynı yapılara erişildiğinde ve bunları güncellediğinde kilitlenme durumunu çözen "starttransaction" ve "endtransaction" fiilleri dahil edildi.

Burroughs'tan Roy Guck, DMSII.

Daha sonraki yıllarda, derleyici kod boyutu daha az endişe verici olduğundan, ön işleme yapılarının çoğu ALGOL'un kullanıcı düzeyinde kullanıma sunuldu. Yalnızca güvenli olmayan yapılar ve veritabanı açıklama dosyasının doğrudan işlenmesi DMALGOL ile sınırlı kalır.

Yığın mimarisi

Birçok eski sistem ve dilde, programcılara rutinlerini çok küçük yapmamaları söylendi. Prosedür çağrıları ve geri dönüşleri pahalıydı çünkü yığını korumak için bir dizi işlemin gerçekleştirilmesi gerekiyordu. B5000 bir yığın makinesi olarak tasarlandı - diziler (dizeleri ve nesneleri içeren) dışındaki tüm program verileri yığın üzerinde tutuldu. Bu, yığın işlemlerinin verimlilik için optimize edildiği anlamına geliyordu. Yığın yönelimli bir makine olarak, programlayıcı adreslenebilir yazmaçları yoktur.

Çoklu görev B5000 ve B6500 hatlarında da çok verimlidir. İşlem geçişlerini gerçekleştirmek için belirli talimatlar vardır:

B5000, B5500, B5700

P1'i (IP1) başlatın ve P2'yi (IP2) başlatın^[5]:6–30

B6500, B7500 ve halefleri

MVST (yığını taşıma).^{[7]:8–19[19]}

Her yığın ve ilişkili^{[NB 5]} Program Referans Tablosu (PRT) bir işlemi (görev veya iş parçacığı) temsil eder ve görevler kaynak isteklerini beklerken engellenebilir (bu, önleme amaçlı çoklu görev nedeniyle kesintiye uğramışsa bir işlemcinin çalışmasını beklemeyi içerir). Kullanıcı programları bir IP1 veremez,^{[NB 5]} IP2^{[NB 5]} veya MVST,^{[NB 6]} ve işletim sisteminde bunun yapıldığı tek bir yer vardır.

Bu nedenle, bir işlem anahtarı şu şekilde ilerler - bir işlem, hemen kullanılamayan bir kaynak talep eder, belki şu anda bellekte olmayan bir bloktan bir dosyanın bir kaydının okunması veya sistem zamanlayıcısı bir kesintiyi tetiklemiştir. İşletim sistemi kodu girilir ve kullanıcı yığınının üstünde çalıştırılır. Kullanıcı işlem zamanlayıcılarını kapatır. Geçerli işlem, talep edilen kaynak için uygun kuyruğa veya bu bir önleyici bağlam anahtarı ise işlemciyi bekleyen hazır kuyruğa yerleştirilir. İşletim sistemi, hazır kuyruğundaki ilk işlemi belirler ve işlemi hazır kuyruğunun başındaki işlemi etkin kılan move_stack komutunu çağırır.

Yığın hızı ve performansı

B5000 mimarisinin eleştirmenlerinden bazıları, kayıt tabanlı mimarilere kıyasla yığın mimarisinin doğası gereği yavaş olduğuna inanıyordu. Sistem hızının püf noktası, verileri işlemciye mümkün olduğunca yakın tutmaktır. B5000 yığınında, bu, yığının en üst iki konumu A ve B adlı iki yazmacıya atanarak yapıldı. Çoğu işlem, bu iki yığının üst konumu üzerinde gerçekleştirilir. B5000'i geçen daha hızlı makinelerde, yığınların çoğu işlemcinin yakınında kayıtlarda veya önbellekte tutulabilir.

Böylece, B5000 sistemlerinin mevcut haleflerinin tasarımcıları en son teknik ne olursa olsun optimize edebilirler ve programcıların kodlarını daha hızlı çalışması için ayarlamaları gerekmez - yeniden derlemeleri bile gerekmez, böylece yazılım yatırımını korurlar. Bazı programların, birçok işlemci yükseltmesinden sonra yıllardır çalıştığı bilinmektedir. Bu hızlanma, kayıt tabanlı makinelerde sınırlıdır.^{[kaynak belirtilmeli ]}

RISC tasarımcıları tarafından öne sürülen hızın bir başka noktası da, her şey tek bir yongadaysa işlemci hızının önemli ölçüde daha hızlı olmasıdır. B5000 gibi daha karmaşık mimarilerin tek bir yongaya sığmak için çok fazla transistör gerektirdiği 1970'lerde geçerli bir noktaydı. Ancak, bugün durum böyle değil ve her B5000 halefi makinesi artık tek bir yongaya ve ayrıca önbellekler ve talimat ardışık düzenleri gibi performans destek tekniklerine uyuyor.

Aslında, B5000'in haleflerinin A Serisi serisi, ilk tek çipli ana bilgisayarı, 1980'lerin sonundaki Micro-A'yı içeriyordu. Bu "ana çerçeve" yongası (Tek Çipli A-serisi Ana Bilgisayar İşlemcisi için SCAMP olarak adlandırılır) Intel tabanlı bir eklenti PC kartına oturdu.

Programlar yığınla nasıl eşleşir?

İşte programların yığın yapısıyla nasıl eşleştiğine dair bir örnek

başla   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bu sözcük düzeyi 2'dir (düzey sıfır işletim sistemi ve düzey 1 kod bölümleri için ayrılmıştır). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 2. seviyede programımız için global değişkenler yerleştiriyoruz. tamsayı ben, j, k;   gerçek f, g;   dizi a [0:9];      prosedür p (gerçek s1, s2);      değer s1; - p1 değeri ile geçti, p2 dolaylı olarak referansla geçti. başla         - - - - - - - - - - - - - - - - - - - Bu blok sözcüksel düzey 3'tür - - - - - - - - - - - - - - - - - - gerçek r1, r2;
         r2 := s1 * 5;         s2 := r2; - Bu ayarlar g değerine r2         s1 := r2; - Bu ayarlar s1 -e r2, Ama değil f         - Bu, orijinal değerinin üzerine yazdığı için f içinde s1 o belki bir - kodlama hatası. Bu nedenle, ALGOL'un haleflerinden birkaçı - değer parametrelerinin sadece okunması - ama çoğu değil. Eğer r2 > 10 sonra            başla               - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Burada belirtilen bir değişken bu sözcük düzeyini 4 yapar - - - - - - - - - - - - - - - - - - - - - - - - - - - - tamsayı n;
               - Bir değişkenin bildirimi, bunu bir yığın yapı kodunu çağıracak bir blok yapar. Normalde burada değişkenleri tanımlamazsınız, bu durumda bu bir blok değil, bileşik bir ifade olacaktır. ... <== örnek yığın burada bir yerde çalışıyor. son;      son;         .....      p (f, g);son.

Her yığın çerçevesi, mevcut yürütme ortamında bir sözcük düzeyine karşılık gelir. Gördüğünüz gibi, sözcük düzeyi, dinamik çağrı iç içe yerleştirme değil, bir programın statik metinsel yuvalanmasıdır. Tek geçişli derleyiciler için tasarlanmış bir dil olan ALGOL'un görünürlük kuralları, yalnızca geçerli konumdan önce bildirilen değişkenlerin kodun o bölümünde görünür olduğu anlamına gelir, bu nedenle ileriye dönük bildirimler için gerekliliktir. Çevreleyen bloklarda bildirilen tüm değişkenler görülebilir. Diğer bir durum, aynı isimli değişkenlerin iç bloklarda bildirilebilmesi ve bunların erişilemez hale gelen dış değişkenleri etkin bir şekilde gizlemesidir.

Sözcüksel yuvalama statiktir, yinelemeli yuvalama yürütme vb. İle ilgisizdir, bu nedenle beş düzeyden daha derin yuvalanmış bir yordam bulmak çok nadirdir ve bu tür programların kötü yapılandırılmış olacağı iddia edilebilir. B5000 makineleri, 32 seviyeye kadar yerleştirmeye izin verir. Bu, üretim yöntemi sık sık yordam içinde iç içe geçmişse, çıktı olarak Algol kaynağını oluşturan (bazı özel sorunları çözmek için uyarlanmış) bazı sistemler için zorluklara neden olabilir.

Prosedürler

Prosedürler dört şekilde çağrılabilir - normal, çağrı, işleme ve çalıştırma.

Normal çağrı, çağrılan prosedür geri dönene kadar çağıran rutini askıya alarak, herhangi bir dilin bir rutini çağırdığı normal şekilde bir prosedürü çağırır.

telefon etmek mekanizma, bir yordamı bir coroutine olarak çağırır. Coroutine'lerin, bir CONTINUE komutu vasıtasıyla görevler arasında açıkça kontrolün geçtiği ortak görevleri vardır. Bunlar senkronize süreçlerdir.

süreç mekanizma bir yordamı eşzamansız bir görev olarak çağırır ve bu durumda işlenen yordamın sözcük düzeyinde başlayarak ayrı bir yığın oluşturulur. Eşzamansız bir görev olarak, eşgüdümlerin aksine, görevler arasında tam olarak ne zaman kontrolün aktarılacağı üzerinde hiçbir kontrol yoktur. İşlenmiş prosedürün çevreleyen ortama hala erişimi vardır ve bu çok verimli bir IPC (Süreçler Arası İletişim) mekanizmasıdır. Artık iki veya daha fazla görev ortak değişkenlere erişebildiğinden, süreçlerin başka bir işbirliği sürecinden kaynaklanana kadar bir olayda BEKLEYebilecekleri EVENT veri türü tarafından işlenen yarış koşullarını önlemek için görevler senkronize edilmelidir. OLAYLAR ayrıca PROCURE ve LIBERATE işlevleri aracılığıyla karşılıklı dışlama senkronizasyonuna izin verir. Herhangi bir nedenle alt görev ölürse, çağıran görev devam edebilir - ancak, üst süreç ölürse, tüm alt işlemler otomatik olarak sonlandırılır. Birden fazla işlemciye sahip bir makinede işlemler aynı anda çalışabilir. Bu EVENT mekanizması, çoklu göreve ek olarak çoklu işlem için temel bir etkinleştiricidir.

Çağrı türünü çalıştır

Son çağrı türü koşmak. Bu, başlatılan süreç sona erdikten sonra devam edebilen bağımsız bir görev olarak bir prosedürü çalıştırır. For this reason, the child process cannot access variables in the parent's environment, and all parameters passed to the invoked procedure must be call-by-value.

Thus Burroughs Extended ALGOL had some of the multi-processing and synchronization features of later languages like Ada. It made use of the support for asynchronous processes that was built into the hardware.

Inline procedures

One last possibility is that a procedure may be declared INLINE, that is when the compiler sees a reference to it the code for the procedure is generated inline to save the overhead of a procedure call; this is best done for small pieces of code. Inline functions are similar to parameterized macros gibi C #defines, except you don't get the problems with parameters that you can with macros. This facility is available in NEWP.

Asynchronous calls

In the example program only normal calls are used, so all the information will be on a single stack. For asynchronous calls, the stack would be split into multiple stacks so that the processes share data but run asynchronously.

Display registers

A stack hardware optimization is the provision of D (or "display") registers. These are registers that point to the start of each called stack frame. These registers are updated automatically as procedures are entered and exited and are not accessible by any software. There are 32 D registers, which is what limits to 32 levels of lexical nesting.

Consider how we would access a lexical level 2 (D[2]) global variable from lexical level 5 (D[5]). Suppose the variable is 6 words away from the base of lexical level 2. It is thus represented by the address couple (2, 6). If we don't have D registers, we have to look at the control word at the base of the D[5] frame, which points to the frame containing the D[4] environment. We then look at the control word at the base of this environment to find the D[3] environment, and continue in this fashion until we have followed all the links back to the required lexical level. This is not the same path as the return path back through the procedures which have been called in order to get to this point. (The architecture keeps both the data stack and the call stack in the same structure, but uses control words to tell them apart.)

As you can see, this is quite inefficient just to access a variable. With D registers, the D[2] register points at the base of the lexical level 2 environment, and all we need to do to generate the address of the variable is to add its offset from the stack frame base to the frame base address in the D register. (There is an efficient linked list search operator LLLU, which could search the stack in the above fashion, but the D register approach is still going to be faster.) With D registers, access to entities in outer and global environments is just as efficient as local variable access.

D Tag Data                — Address couple, Commentsregister

| 0        | n          | (4, 1) The integer n (declared on entry to a block, not a procedure)|-----------------------|| D[4]==>3 | MSCW       | (4, 0) The Mark Stack Control Word containing the link to D[3].|=======================|| 0        | r2         | (3, 5) The real r2|-----------------------|| 0        | r1         | (3, 4) The real r1|-----------------------|| 1        | s2         | (3, 3) A SIRW reference to g at (2,6)|-----------------------|| 0        | s1         | (3, 2) The parameter s1 from value of f |-----------------------|| 3        | RCW        | (3, 1) A return control word|-----------------------|| D[3]==>3 | MSCW       | (3, 0) The Mark Stack Control Word containing the link to D[2].|=======================|| 1        | a          | (2, 7) The array a  ======>[ten word memory block]|-----------------------|| 0        | g          | (2, 6) The real g |-----------------------|| 0        | f          | (2, 5) The real f |-----------------------|| 0        | k          | (2, 4) The integer k |-----------------------|| 0        | j          | (2, 3) The integer j |-----------------------|| 0        | ben          | (2, 2) The integer ben|-----------------------|| 3        | RCW        | (2, 1) A return control word|-----------------------|| D[2]==>3 | MSCW       | (2, 0) The Mark Stack Control Word containing the link to the previous stack frame.|=======================| — Stack bottom

If we had invoked the procedure p as a coroutine, or a process instruction, the D[3] environment would have become a separate D[3]-based stack. This means that asynchronous processes still have access to the D[2] environment as implied in ALGOL program code. Taking this one step further, a totally different program could call another program’s code, creating a D[3] stack frame pointing to another process’ D[2] environment on top of its own process stack. At an instant the whole address space from the code’s execution environment changes, making the D[2] environment on the own process stack not directly addressable and instead make the D[2] environment in another process stack directly addressable. This is how library calls are implemented. At such a cross-stack call, the calling code and called code could even originate from programs written in different source languages and be compiled by different compilers.

The D[1] and D[0] environments do not occur in the current process's stack. The D[1] environment is the code segment dictionary, which is shared by all processes running the same code. The D[0] environment represents entities exported by the operating system.

Stack frames actually don’t even have to exist in a process stack. This feature was used early on for file I/O optimization, the FIB (file information block) was linked into the display registers at D[1] during I/O operations. In the early nineties, this ability was implemented as a language feature as STRUCTURE BLOCKs and – combined with library technology - as CONNECTION BLOCKs. The ability to link a data structure into the display register address scope implemented object orientation. Thus, the B5000 actually used a form of object orientation long before the term was ever used.

On other systems, the compiler might build its symbol table in a similar manner, but eventually the storage requirements would be collated and the machine code would be written to use flat memory addresses of 16-bits or 32-bits or even 64-bits. These addresses might contain anything so that a write to the wrong address could damage anything. Instead, the two-part address scheme was implemented by the hardware. At each lexical level, variables were placed at displacements up from the base of the level's stack, typically occupying one word - double precision or complex variables would occupy two. Arrays were değil stored in this area, only a one word descriptor for the array. Thus, at each lexical level the total storage requirement was not great: dozens, hundreds or a few thousand in extreme cases, certainly not a count requiring 32-bits or more. And indeed, this was reflected in the form of the VALC instruction (value call) that loaded an operand onto the stack. This op-code was two bits long and the rest of the byte's bits were concatenated with the following byte to give a fourteen-bit addressing field. The code being executed would be at some lexical level, say six: this meant that only lexical levels zero to six were valid, and so just three bits were needed to specify the lexical level desired. The address part of the VALC operation thus reserved just three bits for that purpose, with the remainder being available for referring to entities at that and lower levels. A deeply nested procedure (thus at a high lexical level) would have fewer bits available to identify entities, and so for level sixteen upwards their number was restricted. At the deepest nesting five bits would be needed to specify the choice of levels 0–31 thus leaving nine bits to identify 512 entities - not a severe constraint. This is much more compact than addressing entities by their literal memory address in a 32-bit addressing space. Further, only the VALC opcode loaded data: opcodes for ADD, MULT and so forth did no addressing, working entirely on the top elements of the stack.

Much more important is that this method meant that many errors available to systems employing flat addressing could not occur because they were simply unspeakable even at the machine code level. A task had no way to corrupt memory in use by another task, because it had no way to develop its address. Similarly, within a task, an array descriptor contained information on the array's bounds, and so any indexing operation was checked by the hardware: put another way, each array formed its own address space. In any case, the tagging of all memory words provided a second level of protection: a misdirected assignment of a value could only go to a data-holding location, not to one holding a pointer or an array descriptor, etc. and certainly not to a location holding machine code.

Array storage

Arrays were not stored contiguous in memory with other variables, they were each granted their own address space, which was located via the descriptor. The access mechanism was to calculate on the stack the index variable (which therefore had the full integer range potential, not just fourteen bits) and use it as the offset into the array's address space, with bound checking provided by the hardware. Should an array's length exceed 1,024 words, the array would be segmented, and the index be converted into a segment index and an offset into the indexed segment. In ALGOL's case, a multidimensional array would employ multiple levels of such addressing. For a reference to A(i,j), the first index would be into an array of descriptors, one descriptor for each of the rows of A, which row would then be indexed with j as for a single-dimensional array, and so on for higher dimensions. Hardware checking against the known bounds of all the array's indices would prevent erroneous indexing.

FORTRAN however regards all multidimensional arrays as being equivalent to a single-dimensional array of the same size, and for a multidimensional array simple integer arithmetic is used to calculate the offset where element A(i,j,k) would be found in that single sequence. The single-dimensional equivalent array, possibly segmented if large enough, would then be accessed in the same manner as a single-dimensional array in ALGOL. Although accessing outside this array would be prevented, a wrong value for one index combined with a suitably wrong value for another index might not result in a bounds violation of the single sequence array; in other words, the indices were not checked individually.

Because an array's storage was not bounded on each side by storage for other items, it was easy for the system to "resize" an array - though changing the number of dimensions was precluded because compilers required all references to have the same number of dimensions. In ALGOL's case, this enabled the development of "ragged" arrays, rather than the usual fixed rectangular (or higher dimension) arrays. Thus in two dimensions, a ragged array would have rows that were of different sizes. For instance, given a large array A(100,100) of mostly-zero values, a sparse array representation that was declared as SA(100,0) could have each row resized to have exactly enough elements to hold only the non-zero values of A along that row.

Because arrays larger than 1024 words were segmented but smaller arrays were not, on a system that was short of real memory, increasing the declared size of a collection of scratchpad arrays from 1,000 to say 1,050 could mean that the program would run with far less "thrashing" as only the smaller individual segments in use were needed in memory. Actual storage for an array segment would be allocated at run time only if an element in that segment were accessed, and all elements of a created segment would be initialised to zero. Not initialising an array to zero at the start therefore was encouraged by this, normally an unwise omission.

Stack structure advantages

One nice thing about the stack structure is that if a program does happen to fail, a stack dump is taken and it is very easy for a programmer to find out exactly what the state of a running program was. Compare that to core dumps and exchange packages of other systems.

Another thing about the stack structure is that programs are implicitly recursive. FORTRAN was not expected to support recursion and perhaps one stumbling block to people's understanding of how ALGOL was to be implemented was how to implement recursion. On the B5000, this was not a problem – in fact, they had the reverse problem, how to stop programs from being recursive. In the end they didn't bother. The Burroughs FORTRAN compiler allowed recursive calls (just as every other FORTRAN compiler does), but unlike many other computers, on a stack-based system the returns from such calls succeeded as well. This could have odd effects, as with a system for the formal manipulation of mathematical expressions whose central subroutines repeatedly invoked each other without ever returning: large jobs were ended by stack overflow!

Thus Burroughs FORTRAN had better error checking than other contemporary implementation of FORTRAN.^{[kaynak belirtilmeli ]} For instance, for subroutines and functions it checked that they were invoked with the correct number of parameters, as is normal for ALGOL-style compilers. On other computers, such mismatches were common causes of crashes. Similarly with the array-bound checking: programs that had been used for years on other systems embarrassingly often would fail when run on a Burroughs system. In fact, Burroughs became known for its superior compilers and implementation of languages, including the object-oriented Simula (a superset of ALGOL), and Iverson tasarımcısı APL declared that the Burroughs implementation of APL was the best he'd seen.^{[kaynak belirtilmeli ]} John McCarthy, the language designer of LISP disagreed, since LISP was based on modifiable code^{[kaynak belirtilmeli ]}, he did not like the unmodifiable code of the B5000^{[kaynak belirtilmeli ]}, but most LISP implementations would run in an interpretive environment anyway.

The storage required for the multiple processes came from the system's memory pool as needed. There was no need to do SYSGENs on Burroughs systems as with competing systems in order to preconfigure bellek bölümleri in which to run tasks.

Etiketli mimari

The most defining aspect of the B5000 is that it is a stack machine as treated above. However, two other very important features of the architecture is that it is etikete dayalı and descriptor-based.

In the original B5000, a flag bit in each control or numeric word^{[NB 7]} was set aside to identify the word as a control word or numeric word. This was partially a security mechanism to stop programs from being able to corrupt control words on the stack.

Later, when the B6500 was designed, it was realized that the 1-bit control word/numeric distinction was a powerful idea and this was extended to three bits outside of the 48 bit word into a tag. The data bits are bits 0–47 and the tag is in bits 48–50. Bit 48 was the read-only bit, thus odd tags indicated control words that could not be written by a user-level program. Code words were given tag 3. Here is a list of the tags and their function:

Internally, some of the machines had 60 bit words, with the extra bits being used for engineering purposes such as a Hamming kodu error-correction field, but these were never seen by programmers.

The current incarnation of these machines, the Unisys ClearPath has extended tags further into a four bit tag. The microcode level that specified four bit tags was referred to as level Gamma.

Even-tagged words are user data which can be modified by a user program as user state. Odd-tagged words are created and used directly by the hardware and represent a program's execution state. Since these words are created and consumed by specific instructions or the hardware, the exact format of these words can change between hardware implementation and user programs do not need to be recompiled, since the same code stream will produce the same results, even though system word format may have changed.

Tag 1 words represent on-stack data addresses. The normal IRW simply stores an address couple to data on the current stack. The SIRW references data on any stack by including a stack number in the address.

Tag 5 words are descriptors, which are more fully described in the next section. Tag 5 words represent off-stack data addresses.

Tag 7 is the program control word which describes a procedure entry point. When operators hit a PCW, the procedure is entered. The ENTR operator explicitly enters a procedure (non-value-returning routine). Functions (value-returning routines) are implicitly entered by operators such as value call (VALC). Global routines are stored in the D[2] environment as SIRWs that point to a PCW stored in the code segment dictionary in the D[1] environment. The D[1] environment is not stored on the current stack because it can be referenced by all processes sharing this code. Thus code is reentrant and shared.

Tag 3 represents code words themselves, which won't occur on the stack. Tag 3 is also used for the stack control words MSCW, RCW, TOSCW.

Figure 9.2 From the ACM Monograph in the References. Elliot Organick 1973.

Descriptor-based architecture

The figure to the left shows how the Burroughs Large System architecture was fundamentally a hardware architecture for nesne yönelimli programlama, something that still doesn't exist in conventional architectures.

Komut setleri

There are three distinct instruction sets for the Burroughs large systems. All three are based on short heceler that fit evenly into words.

B5000, B5500 and B5700

Programs on a B5000, B5500 and B5700 are made up of 12-bit syllables, four to a word. The architecture has two modes, Word Mode and Character Mode, and each has a separate repertoire of syllables. A processor may be either Control State or Normal State, and certain syllables are only permissible in Control State. The architecture does not provide for addressing registers or storage directly; all references are through the 1024 word Program Reference Table, current code segment, marked locations within the stack or to the A and B registers holding the top two locations on the stack. Burroughs numbers bits in a syllable from 0 (high bit) to 11 (low bit)

B6500, B7500 and successors

Programs are made up of 8-bit syllables, which may be Name Call, be Value Call or form an operator, which may be from one to twelve syllables in length. There are less than 200 operatörler, all of which fit into 8-bit syllables. Many of these operators are polimorfik depending on the kind of data being acted on as given by the tag. If we ignore the powerful string scanning, transfer, and edit operators, the basic set is only about 120 operators. If we remove the operators reserved for the operating system such as MVST and HALT, the set of operators commonly used by user-level programs is less than 100. The Name Call and Value Call syllables contain address couples; the Operator syllables either use no addresses or use control words and descriptors on the stack.

Multiple processors

The B5000 line also were pioneers in having multiple processors connected together on a high-speed bus. The B7000 line could have up to eight processors, as long as at least one was an I/O module. RDLK is a very low-level way of synchronizing between processors. The high level used by user programs is the EVENT data type. The EVENT data type did have some system overhead. To avoid this overhead, a special locking technique called Dahm locks (named after a Burroughs software guru, Dave Dahm) can be used.

Notable operators are:

HEYU — send an interrupt to another processor
RDLK — Low-level semaphore operator: Load the A register with the memory location given by the A register and place the value in the B register at that memory location in a single uninterruptible cycle. The Algol compiler produced code to invoke this operator via a special function that enabled a "swap" operation on single-word data without an explicit temporary value. x:=RDLK(x,y);
BEN KİMİM — Processor identification
BOŞTA — Idle until an interrupt is received

Two processors could infrequently simultaneously send each other a 'HEYU' command resulting in a lockup known as 'a deadly embrace '.

Influence of the B5000

The direct influence of the B5000 can be seen in the current Unisys ClearPath range of mainframes which are the direct descendants of the B5000 and still have the MCP operating system after 40 years of consistent development. This architecture is now called emode (for emulation mode) since the B5000 architecture has been implemented on machines built from Intel Xeon processors running the x86 instruction set as the native instruction set, with code running on those processors emulating the B5000 instruction set. In those machines, there was also going to be an nmode (yerel mod ), but this was dropped^{[kaynak belirtilmeli ]}, so you may often hear the B5000 successor machines being referred to as "emode machines".

B5000 machines were programmed exclusively in high-level languages; there is no assembler.

The B5000 stack architecture inspired Chuck Moore, the designer of the programming language İleri, who encountered the B5500 while at MIT. İçinde Forth - The Early Years, Moore described the influence, noting that Forth's DUP, DROP and SWAP came from the corresponding B5500 instructions (DUPL, DLET, EXCH).

B5000 machines with their stack-based architecture and tagged memory also heavily influenced the Soviet Elbruz series of mainframes and süper bilgisayarlar. The first two generations of the series featured tagged memory and stack-based CPUs that were programmed only in high-level languages. There existed a kind of an montaj dili for them, called El-76, but it was more or less a modification of ALGOL 68 and supported structured programming and first-class procedures. Later generations of the series, though, switched away from this architecture to the EPİK -sevmek VLIW CPUs.

Hewlett Packard designers of the HP 3000 business system had used a B5500 and were greatly impressed by its hardware and software; they aimed to build a 16-bit minicomputer with similar software. Several other HP divisions created similar minicomputer or microprocessor stack machines. Bob Barton's work on ters Lehçe notasyonu (RPN) also found its way into HP hesap makineleri beginning with the 9100A, and notably the HP-35 and subsequent calculators.

The NonStop systems designed by Tandem Bilgisayarlar in the late 1970s and early 1980s were also 16-bit stack machines, influenced by the B5000 indirectly through the HP 3000 connection, as several of the early Tandem engineers were formerly with HP. Around 1990, these systems migrated to MIPS RISC architecture but continued to support execution of stack machine binaries by object code translation or direct emulation. Sometime after 2000, these systems migrated to Itanium architecture and continued to run the legacy stack machine binaries.

Bob Barton was also very influential on Alan Kay. Kay was also impressed by the data-driven tagged architecture of the B5000 and this influenced his thinking in his developments in object-oriented programming and Smalltalk.^{[kaynak belirtilmeli ]}

Another facet of the B5000 architecture was that it was a secure architecture that runs directly on hardware. This technique has descendants in the virtual machines of today^{[kaynak belirtilmeli ]} in their attempts to provide secure environments. One notable such product is the Java JVM which provides a secure sandbox in which applications run.

The value of the hardware-architecture binding that existed before emode would be substantially preserved in the x86 -based machines to the extent that MCP was the one and only control program, but the support provided by those machines is still inferior to that provided on the machines where the B5000 instruction set is the native instruction set. A little-known Intel processor architecture that actually preceded 32-bit implementations of the x86 instruction set, the Intel iAPX 432, olur have provided an equivalent physical basis, as it too was essentially an object-oriented architecture.

Ayrıca bakınız

• Burroughs Orta Sistemler
• Burroughs Küçük Sistemler
• ŞEKER
• Network Definition Language (NDL)
• İş Akışı Dili (WFL)
• Octal floating point

Notlar

Referanslar

Bu makale için ek alıntılara ihtiyaç var doğrulama. Lütfen yardım et bu makaleyi geliştir tarafından güvenilir kaynaklara alıntılar eklemek. Kaynaksız materyale itiraz edilebilir ve kaldırılabilir. Kaynakları bulun: "Burroughs large systems"  – Haberler  · gazeteler  · kitabın  · akademisyen  · JSTOR (Kasım 2009) (Bu şablon mesajını nasıl ve ne zaman kaldıracağınızı öğrenin)

• The Extended ALGOL Primer (Three Volumes), Donald J. Gregory.
• Computer Architecture: A Structured Approach, R. Doran, Academic Press (1979).
• Stack Computers: The New Wave, Philip J. Koopman, available at: [1]
• B5500, B6500, B6700, B6800, B6900, B7700 manuals at: bitsavers.org

daha fazla okuma

• Barton, Robert S. "A New Approach to the Functional Design of a Digital Computer" Proceedings of the Western Joint Computer Conference. ACM (1961).
• Burroughs B 5000 Oral history, Charles Babbage Enstitüsü, Minnesota Universitesi. The Burroughs 5000 computer series is discussed by individuals responsible for its development and marketing from 1957 through the 1960s in a 1985 conference sponsored by AFIPS ve Burroughs Corporation.
• Gray, George (March 1999). "Some Burroughs Transistor Computers". Unisys Tarih Bülteni. 3 (1). Arşivlenen orijinal on October 1, 2016.
• Gray, George (Ekim 1999). "Burroughs Üçüncü Nesil Bilgisayarlar". Unisys Tarih Bülteni. 3 (5). Arşivlenen orijinal 26 Eylül 2017.
• Hauck, E.A., Dent, Ben A. "Burroughs B6500/B7500 Stack Mechanism", SJCC (1968) pp. 245–251.
• McKeeman, William M. "Language Directed Computer Design", Fall Joint Computer Conference, (1967) pp. 413–417.
• Organick, Elliot I. "Computer System Organization The B5700/B6700 series", Academic Press (1973).
• Waychoff, Richard, "Stories of the B5000 and People Who Were There", September 27, 1979. [2]
• Allweiss, Jack. "The Burroughs B5900 and E-Mode A bridge to 21st Century Computing", Revised 2010.
• Martin, Ian. "'Too far ahead of its time': Britain, Burroughs and real-time banking in the 1960s", Society for the History of Technology Annual Meeting, 20 Sep-3 Oct 2010, Tacoma, USA.

Dış bağlantılar

• Ian Joyner's Burroughs page
• The Burroughs B5900 and E-Mode: A bridge to 21st Century Computing - Jack Allweiss
• (web archive of:) Ralph Klimek on the B7800 at Monash University
• "Early Burroughs Machines", Virginia Üniversitesi 's Computer Museum.
• "Computer System Organization", ACM Monograph Series.
• Index of B8500 manuals
• B5500 Emulation Project Project to create a functional emulator for the Burroughs B5500 computer system.
• "Burroughs B6500 film & transcript"