The birth of the Soviet missile defense system. Pros and cons of BESM-6
CDC 6200
In terms of speed, BESM-6 was no longer a fountain in those years either, since 1960 computers have gone far ahead, we had to look for a solution to this problem as well. The USSR swallowed its pride for the second time and went to ask to sell him CDC 6600 as well. Here CoCom has already rested its horns, and they offended not only the Union, not a single CDC 6600 was delivered to anyone outside the United States, even France refused. Only in 1972, CoCom allowed (and then under its strict supervision) to install in Dubna a junior version of CDC 6200, which in 1975 (already obsolete after the release of Cray-1) was upgraded to a multiprocessor 6500, and the flagship - 6600, remained purely American monster.
Here is how G. Ososkov recalls this (newspaper "Dubna", No. 21 (3759) of May 27, 2005)
In 1967, as part of a contract for the purchase of a CDC-1604 computer, I was sent to Germany together with engineers A. Karlov and V. Mirolyubov to study at the European center of the CDC firm in Frankfurt am Main. After studying the computer operating system and programming in the FORTRAN language, I did an internship for another two months at the CDC-1604 operator in Hanover. As a result, I worked as a senior mathematician at CDC-1604 for a year after installing this computer in the LCTA and, in addition, learned spoken English. In 1969-1970 and 1973. at CERN he was studying the system of control and calibration programs for the Spiral Reader scanning machine, similar to that developed at LCTA. In 1972, together with the deputy director of LCTA G. I. Zabiyakin, we were on a two-week business trip to the United States at the invitation of the CDC company. They visited the BNL Computing Center, participated in the CDC User Conference in Dulus, visited the CDC headquarters and the plant where the latest CDC-7600 computers were produced in Minneapolis, as well as the Berkeley University and Livermore Laboratory computer centers equipped with CDC machines. Among other things, we were shown the well-known computer CDC-Star at that time. However, I was most impressed by the capabilities of the CYBERNET computer network, which connected 49 CDC machines across America for simultaneous batch operation.
Most of the user talks at the Dulus conference were devoted to discussing the capabilities and disadvantages of this network. Now, 30 years later, such opportunities seem common, but at the time it looked quite fantastic. The main purpose of the trip was to conclude contracts for the purchase of the CDC-6200 computer, bypassing the infamous COCOM agreement aimed at banning the supply of the latest computer technologies to socialist countries. Agreeing to a permanent inspection by KOCOM in Dubna, the LVTA directorate in 1972 obtained permission to purchase the CDC-6200. Such machines of the 6000 series belonged to powerful computers, there were many application programs for them in the CERN library, and although the 6200 was already quite outdated, such a purchase allowed LVTA in 1974 to develop the machine to the CDC-6400, and the next year to the multiprocessor CDC-6500. Together with BESM-6, this dramatically increased the computing power of JINR, made it possible to create an extensive terminal network and launch fortran stations.
Most of the user talks at the Dulus conference were devoted to discussing the capabilities and disadvantages of this network. Now, 30 years later, such opportunities seem common, but at the time it looked quite fantastic. The main purpose of the trip was to conclude contracts for the purchase of the CDC-6200 computer, bypassing the infamous COCOM agreement aimed at banning the supply of the latest computer technologies to socialist countries. Agreeing to a permanent inspection by KOCOM in Dubna, the LVTA directorate in 1972 obtained permission to purchase the CDC-6200. Such machines of the 6000 series belonged to powerful computers, there were many application programs for them in the CERN library, and although the 6200 was already quite outdated, such a purchase allowed LVTA in 1974 to develop the machine to the CDC-6400, and the next year to the multiprocessor CDC-6500. Together with BESM-6, this dramatically increased the computing power of JINR, made it possible to create an extensive terminal network and launch fortran stations.
The funniest thing about this stories the fact that cars with the CDC 6200 index never existed in nature! It was not released by CDC and is not found in any Western source!
What is it?
It's very simple - Kray's company needed new partners, business is good, but CoCom did not agree to supply the Soviets with even a junior supercomputer - 6500. Then CDC engineers dismantled one processor from it, made another downgrade and received a unique stub - CDC 6200 specially for the USSR in a single copy. They were allowed to sell the stub, and a few years later, when the line became obsolete and was discontinued, CoCom allowed them to screw the processor back.
A similar story was repeated later with CDC 7600 and Cray-1, they failed to buy, and the attempt to create a clone in the form of "Electronics SS BIS" failed phenomenally, but two more CDCs, simpler models, CYBER 170 and 172, were legally bought.
CYBER 172 was purchased in 1975 for the USSR Hydrometeorological Center and successfully operated there until 1996. In general, the study of the climate was extremely important for the USSR in connection with the huge area of the country and the needs of shipping and land use, so that in the Hydrometeorological Center there were some of the most powerful machines of the Union, not inferior to Dubna and Arzamas-16, and usually several machines were used at once. The first computer for meteorologists was the M-20, which operated there from 1959 to 1962, it was thrown out after only three years, and it is not surprising.
The director of the Main Computer Center Vladimir Antsipovich, who worked there for over 40 years, recalls:
We had to achieve the reliability of the operation of technological schemes with the minimum required continuous counting time of at least one hour, while, for example, for the M-20, the passport MTBF was only fifteen minutes.
It was replaced by M-220, then M-222 and Vesna, a rather exotic large computer with a performance of 300 KIPS, created in 1965 at the Industrial Automation Design Bureau of the Ministry of Radio Industry (as you can see, despite the BESM-6, other ministries continued to play with enthusiasm at the zoo architectures).
This machine worked at the Hydrometeorological Center until 1972, in parallel with the top of the purely Soviet mainframes - "Minsk-32". Also from 1968 to 1985 BESM-6 worked there.
CYBER-172 was the first foreigner at the Main Computer Center (it was for meteorologists that they wanted to buy a CDC 1975 in 7600, but they broke off about CoCom), and with it the dominance of Western supercomputers in Soviet meteorology began. In general, they wanted to buy two of them, but CoCom even then put a pig on it, they decided that two of them were too fat for the USSR.
Naturally, there were also the EU 1060 and 1066, as well as the IBM 3033 - the newest replacement for the S / 370 line, came out in 1979, however, for conspiracy it was called Hitachi (however, there is a muddy story - either ours bought it a licensed clone from Hitachi , or the original IBM, but they called it that for the sake of greater mystery, in any case, the "Hitachi 3033" machine does not exist in nature, there is only Hitachi HITAC M-220 or IBM 3033).
In 1992, they already wanted to deliver the long-suffering Elbrus-2, but then suddenly CoCom approved the sale to Russia of the most powerful Cray Y-MP, which surpasses Elbrus by about 30 times. While discussing all the details - the installation moved to 1996 and from the Top 500 Cray Y-MP has already dropped out.
This monster worked at the Main Computer Center for 10 years continuously, until 2006, when he died safely at his post. This is largely due to the fact that three years after installation, for financial reasons, it was necessary to continue using the Cray Y-MP without support from the manufacturer. Antsypovich says:
For eight years of operation, we went through all the nodes of the computer, trying to make it work due to the redundancy of the design, but, in the end, even hidden reserves began to be insufficient: the complex stopped.
Then two clusters appeared - SGI Alltix 4700 (11 teraflops 832 Intel Itanium 2 9140M) and SGI Alltix ICE (16 teraflops, an unknown number of Intel Xeon E5440), and in 2019 the power forked out for a new cluster from Cray - XC40.
CYBER 170 was purchased in 1976 for the laboratory of the Leningrad Scientific Research Center of the Academy of Sciences of the USSR at LIAN, now the SPII RAS. The fate of the Hydrometeorological Center's car is unknown to the author, but he saw the remains of the LIAN car with his own eyes in the building of the SPII RAS on Vasilievsky Island, it is difficult to get there, but not impossible, the staff are very friendly and, if they call and negotiate in advance, they will gladly conduct a short excursion, so that those living in St. Petersburg have a good chance to touch the history.
CDC CYBER-170 from SPII RAS, or rather its remains. Photo by the author.
To solve the problem with a lack of computing power by 1973, Melnikov developed the so-called. interface equipment, the AS-6 complex, in fact a complex programmable switch with additional memory and coprocessors, which allows you to combine several BESM-6 and turn them into a cluster with shared RAM. A total of 8 sets were made.
Questions
We have two questions left to answer.
First, why was the system architecture of BESM-6 so unsuccessful?
Secondly, what strengths did it have and why did it become so overgrown with myths and legends?
To begin with, Lebedev originally designed his first machines for very specific purposes - specifically for solving systems of differential equations (that is, calculating the trajectory of missiles or simulating nuclear reactions). He understood how to build such computers, since he himself was an outstanding electrical engineer and developer of analog computers for modeling the same differential equations.
Unlike Eckert, Wilkes, Amdalla - Lebedev was not exactly a computer scientist, did not have the appropriate mindset, and even less was a programmer, his only attempt to create an autocode ended with the fact that no one used this horror. Therefore, Lebedev did not have a close idea of the problems of the users of his machines, he built, although formally and universal, but in spirit rather mono-task computers, well adapted to solving systems of difura and poorly to everything else.
By the way, this was a common problem for everyone in ITMiVT: they could still create machines for missilemen, but they could create a truly universal computer with great difficulty. Burtsev eventually had the same problems with Elbrus, taking the Burroughs banking mainframe as a basis and trying to convert it into a missile defense control computer. It turned out at the very least, but a successful general-purpose supercomputer for scientists did not come out of Elbrus either.
CDC made machines for control systems and scientific computing, and IBM made machines for business, mainly for finance and accounting systems. These are fundamentally different areas of application, and they left their mark on architecture. BESM-6 reached the absolute in this division.
Let's start with a fact that has already surfaced here. There was no integer arithmetic in it. Generally. Not at all.
In CDC 1604 it was, and very developed, but Lebedev threw it out of BESM-6, why?
Because all his life he built mono-task crushers of differential equations (mono-task - in the sense that, according to his logic, they were simply run at the expense of a system of different difura, and more - they were not particularly used), and there integer arithmetic is not needed. As a result, faced with the difficulties of combining the real and the whole ALU, he simply threw away the whole, deciding that if someone suddenly needs it, they will emulate the real one.
Why do we need integer arithmetic at all?
The answer is simple - to manipulate addresses in RAM. As you already understood, both the CDC-1604 and BESM-6 were machines with an adder (that is, in modern terminology, they had only two registers, of which one dedicated was the battery, in which all the actions were performed). In part, this is similar to the stack architecture that can now be found in the Forth and Java languages.
The problem is that with such an organization, ALU has to constantly load / unload something into memory, and this requires index registers and advanced index arithmetic, which allows manipulating addresses in RAM.
By the way, there was a certain inconvenience in BESM-6 and CDC - the bit width of the index registers did not coincide with the word size (!) And the size of the accumulator register and was even non-multiple to it (15 and 48 bits), which was still normal by the standards of 1959-1960. but pulling such an archaic into 1968 is already gloom.
So, it is natural that machines with adders had rather developed integer arithmetic precisely because of the need to load something from RAM or drop it into it every clock cycle, while Lebedev ignored this feature of the CDC. As a result, each computation of addresses required emulation on a real processor, which did not positively affect either the speed of work or the convenience of programming.
The periphery has become another very serious problem of BESM-6.
First, as we have already said, Melnikov abandoned channel processors and explained it this way:
The method of interfacing external devices, adopted in the BESM-6 machine, was subjected to the greatest attacks from the critics of this machine. Indeed, the connection of any new device requires certain engineering improvements in the device for controlling external devices, and the user who has managed to get his hands on any "non-standard" device has great difficulties with its connection. It seems that there are no excuses for such a decision, especially since by the time the BESM-6 was developed, IBM had implemented a standard interface that largely eliminated the problem of connecting new devices and replacing some with others.
But if you think carefully or simply compare the cost and volume of the equipment required to implement interfacing with external devices in either case, then the decisions made in BESM-6 may not be so bad. In fact, each external device for providing a standard interface contains a controller or is connected to this very expensive and complex device, which provides a standard output to the multiplex or selector channels. If we sum up the costs of additional equipment and the space it occupies, required when connecting devices via a standard interface, it turns out that the BESM-6 system is many times more economical. In other words, the centralized control unit BESM-6 is several times cheaper than the cost of controllers for a standard set of external storage and input / output devices of machines of a similar class.
However, in a number of IBM machine models, a so-called integrated file adapter was introduced, which allows you to connect a disk storage device to a computer without using a standard channel and controller. In this fact, one can see some analogy with the rational method of connecting devices, adopted in BESM-6.
But if you think carefully or simply compare the cost and volume of the equipment required to implement interfacing with external devices in either case, then the decisions made in BESM-6 may not be so bad. In fact, each external device for providing a standard interface contains a controller or is connected to this very expensive and complex device, which provides a standard output to the multiplex or selector channels. If we sum up the costs of additional equipment and the space it occupies, required when connecting devices via a standard interface, it turns out that the BESM-6 system is many times more economical. In other words, the centralized control unit BESM-6 is several times cheaper than the cost of controllers for a standard set of external storage and input / output devices of machines of a similar class.
However, in a number of IBM machine models, a so-called integrated file adapter was introduced, which allows you to connect a disk storage device to a computer without using a standard channel and controller. In this fact, one can see some analogy with the rational method of connecting devices, adopted in BESM-6.
Translated into ordinary language, it turns out the following - to implement sane work with channel coprocessors, as in the S / 360, we did not have enough money and the desire of Lebedev, who fanatically opposed the introduction of coprocessors into his machines (a fix idea left over from the tube times, when an additional couple of thousand Soviet-quality lamps would clearly not improve reliability, and the game was not worth the candle, Burtsev pushed channel processors into the 5E26, which sharply raised its performance, in fact, behind the already very sick Lebedev, who was then not up to architecture).
In general, working with channels was often overly confusing for our programmers, hence the myths about the superiority of BESM-6 in this regard over the EU series. Given their low literacy, huge problems with the quality of the first EU clones, as well as the almost complete absence of textbooks, documentation, example programs, patches, etc., of course, working with such a complex thing as channels could become hell compared to the implementation input-output in BESM-6, as simple as a felt boot. Hence the numerous myths about incredibly progressive architecture.
At the same time, many people confuse different levels of architecture - the architecture of the command system and the system architecture, which describes, among other things, the physical connection of peripherals, etc. With the system architecture in BESM-6, everything was just very good - machines could be combined into a network, to a cluster up to 8 computers, it was possible to connect up to 128 terminals, including remote ones, a cluster disk controller (each machine in a cluster has access to each disk), etc. all Western computers of this class).
A funny paradox is the fact that many successful technical solutions were born from attempts to overcome the wretchedness of the domestic element base.
For example, the progressive technology of double recording on tape (even if a block has errors, but in two different places, it will collect from pieces and read normally) appeared as a response to the disgusting quality of the Soviet tape, which began to pour out literally after two or three runs - in the EU , after IBM, there was no such mechanism; as a result, a myth arose about the unreliability of their tape recording subsystem in comparison with BESM.
At the same time, not progressive hard disks were used as a magnetic drive, but an outdated magnetic drum, while disk controllers appeared only in 1974, after they were copied from the controllers of the ancient General Electric mainframes (by that time they were so outdated that CoCom had no problem solving their sale officially for the needs of KIAE and ITEP, unofficially - to disassemble them into useful parts for BESM-6).
In general, a separate book can be written about the horrors of a purely Soviet periphery, as well as about its quality. In a discussion about BESM-6 in the magazine 1500py470.livejournal, one of the programmers who worked with her left such memories on this occasion:
I accidentally wandered into your conversation. He worked at BESM-6 for 17 years. There were two machines # 135 and # 335 ... You at least know that one of the standard tools for testing and diagnosing machine operation errors, especially with a floating error, was a hammer, in the form of a heavy metal cylinder (all in notches so that it would not slip out of the hand when tapping) with replaceable ebonite tips on both sides (they changed with wear). Our cars were turned off once a year. It's easy to guess - December 31. So, after turning them on, everyone tapped them. Memory (these are 8 double cabinets) with a total capacity of 128x6Kb (I did not count two control digits), i.e. e. less than 1 Mb, and the area occupied 60–80 m, or even more. We worked under DISPAK OS, in batch mode the processor processed 5-10 tasks (depending on how much the task eats), the CRAB system was constantly in access ... then there was a benefit from the EU). Nobody noticed that the clock frequency in different sources indicate different, where is 9 MHz, and where is 10 MHz? Developed for 10, but the element base let us down, made 9,1 MHz. There is much more to tell. We combined two machines into shared disks (first 7,5 MB, then 29 MB each drive, removable disks). There are 16 such drives. We made a terminal network through a local automatic telephone exchange, leased lines up to 500 meters. The terminals were alphanumeric, Videoton-340 was considered the best (Hungary bought a license from IBM for an outdated model). Even better were the Videoton VDT 52100 on Intel 8080 processors. One of the biggest problems was magnetic drums. If we omit the details, then it is very similar to the operation of the HDD, but the heads are fixed, and there are hundreds of them (I don’t remember exactly). The whole hemorrhoids are that the gaps in them are set manually on each head in a cold state, and after this device has warmed up, this cannot be done - during acceleration, increased vibrations and the surface bulged (and it weighed 200-250 kilograms, therefore, in a working the regime entered for several hours and cooled down for almost a day). If turned off, then you cannot start hot, you have to wait until it cools down. So we got rid of them too, putting the memory of Electronics. Instead of 16 drums - 8 boxes, one rack. Two BESM-6s were easily put into one hall 200 m, the plotter Digi graph was connected. They practically abandoned magnetic tapes, switching to disks and installing ARFA software (archive-file system). To download programs written in Fortran, we connected a PC, installed Kermit. Users received their program texts on a floppy disk ... By 1975, it was necessary to release a new machine of this line, taking into account the shortcomings: 15 bits in the address part is a dead end, the element base is completely outdated, about ADCP, UPDK, ML, etc. periphery and say nothing, HORROR! Power consumption is outrageous! You can't remember all the shortcomings at once, this is for the best. But they soldered and assembled CAM at the plant, crooked, sometimes sober, birdies. After them, the adjusters put it into operation for two months.
The head of the LCTA department of OMOED, G. N. Tentyukova (JINR weekly "Dubna" No. 34 (4325) of 11 August 2016, "When the machines were big") recalls:
You, probably, did not find the first device for inserting punched cards on the BESM-6? Now I'll tell you how it worked. You put the deck. You turn it on. Slowly: chug-chug-chug ... Suddenly: tra-ta-ta! Four cards ... This means you need to pull out the deck, count four cards from what has passed, put at the beginning of the rest of the deck - and press start again. Valya Nikitina said that during some international conference (BESM-6 had just been introduced) the Talker brought foreigners into the turbine room - to boast about what kind of computer we have. And Valya, as if on purpose, set up a large deck. Well what are you going to do! "Four cards", "four cards" ... Valya stands, blushes. Well, nothing, foreigners are polite people: they looked as Valya entered the cards and left. Valya says: I almost burned out with shame! What can you do? We are not to blame.
If you wish, you can find so many such memories that not a single article will contain.
Even the JINR employees themselves wrote in the Dubna newspaper in 1990 (when they could no longer be ashamed:
The equipment was constantly being improved. A group of operators under the leadership of V.V. Fedorin and I.A. CDC punched card input and tape recorder, Hungarian terminals, Bulgarian tape recorders and discs, a Polish printer, a Japanese plotter - you will not find a more diverse fleet of external devices anywhere. This zoo has highlighted the long-standing misfortune of domestic technology: our people are skilled, but the industry is not!
In general, it became possible to work normally at BESM-6 about 15 years after the release of the car - when the most penetrating comrades who had the most heavy pull (like Dubna scientists) threw the entire periphery from the BESM itself into the trash heap (and at the same time from the EU, it was much better, but in comparison with imports - monstrous scrap metal) and supplied everything American, Japanese and German (at worst - Polish or Hungarian).
In addition, it was desirable to upgrade the memory, screw up normal terminals with hellish crutches (at worst, from the EU) and write a huge bunch of software ourselves, from translators to the OS. Then fond memories of working with BESM-6 could remain.
In general, all the years of the Union's existence, a simple idea was categorically not mastered in it - the client wants a finished product, and not a raw semi-finished product that needs to be finished for years. Imagine a situation - the NSA receives the CDC 6600 they ordered for ten million dollars, the computer arrives without peripherals (or with one that is impossible to work with, and if possible, you need to connect it for six months using a soldering iron and famous magic words), without a sensible OS, no compilers and completely insane assembler.
And gentlemen, cryptographers must do all the commissioning work with their own hands and at their own expense, write software and generally work normally with the machine in 10 years, before that - bear with it. For any company of a market type, such a trick would be the last in their work; a dissatisfied client will not come a second time. In a planned economy, there was no choice, as a class - what the party deigned to give, then eat.
The performance myth
As for performance, there is a myth that the BESM-6 was incredibly powerful, almost at the level of the CDC 6600. The declared performance of the BESM-6 is 1 MIPS. In reality, this information is fundamentally inconsistent, since the execution time of commands could differ by an order of magnitude.
For example, the theoretical speed of operation of the multiplying device (MD) alone could really reach values of 1-1,3 MIPS, while the practical speed, when the CD was intensively accessing memory in the process, did not exceed 0,5-0,8 MIPS. Division commands worked at a speed of 0,15-0,3 MIPS, while commands returning data from AU to CU (UI, MOD, etc.) could produce anything at all, since they were waiting for 5 teams (4 from the LHC and 1 from the PR). At the same time, the memory cycle of BESM-6 is 2 μs, that is, commands that read an operand that is not in the BRZ could, in the worst case, get +2 μs to their execution time.
In 1992, before decommissioning the BESM-6, employees of the Research Computing Center compared its performance in counting bridge combinations with a 286 processor (AMD's implementation overclocked to 16 MHz versus the standard 12) and, according to their assurances, received approximately equal numbers. The performance of the AMD 286 exceeded 2,6 MIPS, but we do not know which version of the BESM-6 (most likely, Elbrus-1K2, on the IC is much more powerful than the original one) they used.
The book "From microprocessors to personal computers" (Cheremnykh S.V., Giglavy A.V., Polyak Yu.E., 1988, Radio and communication) provides examples of a benchmark (addition and multiplication of arrays in a loop) in different languages for different machines and the time of their execution is given. According to this information, the test execution time was (depending on the language) from 0,08 to 0,23 s for BESM-6 and from 0,11 to 0,38 s for EC 1055M, 0,45 s for DCK (processor MS 1201.02) and 0,37 s for PC / AT with 16 MHz processor.
All these data are very contradictory, and in the absence of a working BESM-6, it will no longer be possible to find out the truth, however, we note that the average result in a random problem in any case does not exceed 0,8–1,5 MIPS.
Note that this speed was reached by the IBM 7030 Stretch eight years earlier, the legendary CDC 6600 was confirmed to deliver more than 3 MIPS 4 years earlier, and the S / 360 of older models produced the same 0,8–1 MIPS a couple of years earlier.
Thus, we see that BESM-6 would definitely have been among the world record holders in 1959–1960, but for 1968 its parameters did not represent anything supernatural and were at the level standard for a typical mainframe, moreover, in the middle of the decade. At the level of European machines of that time (Siemens, Bull, Olivetti), the BESM-6 looked normal, while not keeping up with the CDC (which were the most powerful machines of the era). S / 360s were no worse - in scientific calculations, and significantly better - in financial ones.
There is nothing to be surprised at.
As we said, BESM-6 did not have support for integer arithmetic, which means that any arithmetic commands were performed on a real adder, and now imagine the pleasure of calculating addresses through emulation of integer arithmetic almost every clock cycle - the machine is not a register, but antediluvian , with an adder, as a result, the numbers need to be constantly driven from RAM to RAM. This led to the fact that even in the best case reading required 3 ticks, addition - 5 ticks (on average - 11, at worst - 280), multiplication - 15 ticks (on average - 18,5, and at worst - 162), the division took an average of 50 clock cycles. As a result, programs not only ran slower than they could, but also took up more space.
V.V. Przhiyalkovsky also mentions this in his review:
Research carried out at the Institute of Applied Mathematics of the USSR Academy of Sciences has shown that programs compiled for the IBM S / 360 require 1,5–3 times less memory than the BESM-6, Vesna, M-20 programs.
If we talk about performance in numbers according to the then popular Whetstone test, BESM-6 gained about 0,3–0,4 million single precision operations per second, which was at the level of average IBM models.
Another problem was the complete unpredictability of time work. One and the same command could be executed for timings that differed literally by an order of magnitude! It's a nightmare by modern standards, and not much better by 1970s standards.
In any instruction system, starting in the 1960s, it is known exactly how many clock cycles one or another action will take, and these timings are spelled out in all manuals for low-level programmers. Lebedev, on the other hand, did not understand why at least some kind of predictability was needed, and did not even try to achieve it.
As a result, in BESM-6, the execution time walks depending on random phenomena, not only on the obvious ones - for example, whether an address was or did not get into the prefetch, but even on the value of the operands.
It is not known in relation to which competitor Lebedev uttered the phrase attributed to him: "Yes, the speed of your machine is higher than mine, but given the low reliability, it still will not have time to calculate the task in the interval between two breakdowns!", But many interpret it, as proof of the super-reliability of the BESM-6.
There was the only place in the world where she could meet in a fair fight with the CDC 6500 - the nuclear research center in Dubna. Here is the result of their battle: their annual plan in operating hours coincided - 6000 nominally, but in reality BESM-6 worked 1979 hours in 6910, and CDC 7440 hours. The most important thing is in other figures - 75 thousand tasks were processed on Lebedev's machine, on the CDC - almost 200 thousand ...
There are several persistent myths about the system architecture of BESM-6, one of them is the presence of virtual memory.
This concept was first implemented in Atlas, and it also implemented associative memory to determine the presence of a required page of virtual memory in RAM.
Why is what was in BESM-6 not it?
Virtual memory support makes it possible to address more memory than is actually installed on the machine. On BESM-6 in the version with tripled RAM, everything was the other way around - there was more physical memory on the machine than it could be addressed! The fact is that, having 128 kilowords of memory, we had to work with it through 15-bit addresses (a legacy from the CDC 1604). Due to the absolutely controversial concept of "keeping the address format compatible with CDC 1604, but tripling the memory", a special crutch was introduced - 32 so-called. register of registration. Before accessing real memory, the executive address was split into two parts 5 + 10 bits. The upper part was interpreted as the registration register number, from which 7 bits of the physical page number were taken, and together with the 10 least significant bits of the address, they made up a 17-bit physical address. Lebedev proudly called this regime "virtual memory".
In Atlas, the address was originally 24-bit, and when trying to address outside of real memory, the supervisor pumped up a page from the drum with the corresponding virtual address in RAM, similar to what happens now when pages are downloaded from disk.
By the way, a similar problem with addressing existed in BESM / BESM-2 / M-20 / BESM-4, but everything was even more neglected there. In them Lebedev used his beloved three-address command system of the KOP format | A1 | A2 | A3, where COP is the operation code, A1 – A3 addresses.
Why do we scold this principle so much, is everything outwardly beautiful?
The fact is that each address could refer to a maximum of 4096 words, it no longer fit into the bus, which was already prohibitively wide, because it was necessary to push three such addresses and an operation code along it. But even the first BESM had more memory!
How do you turn to her?
To use the entire amount of RAM, it was divided into the so-called. "Cubes", the prefixes of these cubes were introduced for addressing. Indirect addressing had not yet been discovered (at ITMiVT, at least), so programmers wrote self-modifying code, changing the addresses A1, A2, A3 in commands on the fly (which, from the point of view of more or less modern programming principles, is a dirty hack and outrageous perversion, so even viruses try not to write unless absolutely necessary, in BESM it was a regular mode of operation).
An additional problem was the notorious work with external devices, Lebedev in his original machines solved it as harshly as possible - simply by hard-coding all calls right in the hardware, despite the fact that there were not enough commands anyway. There were no attempts at abstraction from devices, which suggests, again, that he was as excellent an electrical engineer as he was a flawed system architect. Hence it follows that, thank God, the CDC was taken as a prototype of the BESM-6. Lebedev understood the limits of his competence (sometimes) and did not dare to develop a supercomputer of the required level entirely from scratch using his own imagination.
The next architectural myth
The next architectural myth is associated with a conveyor belt, they say, the BESM-6 was the first machine in the world on which the genius Lebedev built his "water supply", which he reported at a conference in Darmstadt, and narrow-minded Europeans experienced shock and awe.
In reality, the idea of the conveyor was expressed by Konrad Zuse and was implemented in a primitive two-stage form back in Z3. In 1949, he tried to patent its implementation in the Z4, but surprisingly, the patent was stalled until the mid-1960s, despite the fact that the patron of Zuse was IBM.
Similar ideas were in the air in the early 1950s, both Lebedev and Rameev thought about them, they were discussed at MPEI seminars. In 1946, Great Britain urgently needed a huge uninhabited piece of land for nuclear tests. weapons... Fortunately, they found such a piece of sushi, and it was called Australia.
As a result, a partnership agreement was concluded - test sites in exchange for access to modern technologies. This is how the Australian Arms Research Institute was founded (WRE, they invented a lot of things, for example, in 1957 they created the same "black box" for aircraft).
The British company Elliott Brothers developed the Elliott model 403 computer (often referred to as WREDAC) especially for the WRE. This tube machine started up in 1955 and had a two-stage conveyor, similar to Zuse's patent.
Note that neither Zuse's nor Lebedev's ideas belong to a real conveyor in the modern sense of the word. In their "pipeline" only the combination of two multidirectional operations was supposed - arithmetic-logical in the processor and fetching the next operand from RAM.
A real conveyor assumes the presence of an advanced control device operating on a completely different principle. Parallelism at the instruction level in a real pipeline means overlapping at least three operations on instructions - fetching, decoding and executing; for this, it is necessary to implement a rather complex mechanism for predicting conditional branches.
The conveyor in this sense of the word was first described by Donald Bruce Gillies, an eminent Canadian mathematician and computer scientist who worked at the University of Illinois on the ILLIAC II supercomputer project. It was an incredibly progressive machine, but its development ended only in 1962, while all the documentation and operating principles were set out in open academic papers back in 1957–1958. and not patented, Stretch developers borrowed the conveyor scheme from them, but formally managed to release their car three years earlier.
In the same 1959, a single copy was made of the M-100 Kitov tube monster, which we already wrote about, there is practically no information about its architecture, it is reliably known that it had a Harvard architecture and a pipelined processor, but to what extent it could execute general-purpose programs and what kind of conveyor it was is unknown.
Classic as it is. BESM-6 in natural habitat, JINR turbine room, Dubna (photo https://ramlamyammambam.livejournal.com/). At the same time, two BESM-4, CDC 1604, CDC 6500, three EC-1040, EC-1060, EC-1010, EC-1061 and Robotron KRS-4201 worked at JINR. In terms of the number of installations, it was most likely the most powerful and largest exhibition center in the USSR.
The BESM-6 pipeline was spied on from the CDC-6600, only with Cray, each processor had 10 independent blocks that could execute instructions from the pipeline in parallel, therefore this machine is considered the first superscalar processor in the world.
The CDC 7600, created in 1969, and the IBM System / 360 model 91 (1967), which used all the modern features of the pipeline, including speculative execution and register renaming, had even more advanced architecture.
A much more primitive circuit with an adder in BESM-6 also could not have a conveyor in the modern sense of the word, as well as virtual memory. The ALU itself was not pipelined - if the processor multiplied two numbers, it could not do anything else, although the next instruction could be fetching at the same time. So the implementation of the "conveyor" here was 15 years old, similar to the work of Zuse, Rameev and Elliot.
The last delusion
The last misconception about the "colossal innovations" of BESM-6 is the presence of cache memory in it.
In fact, there was no cache in the modern sense of the word, a full-fledged cache appeared only in the IBM System / 360 model 85 series in the same 1967.
The cache of a healthy person consists of a set of records in ultrafast RAM (usually static), each record is associated with a block of data, which is a copy of this block in normal RAM. Each entry has an identifier (often called a tag) that identifies the correspondence between items of data in the cache and their copies in main memory. If an entry is found in the cache with an identifier that matches the identifier of the requested item, then the items in the cache are used. This is called a cache hit. If no entry is found in the cache containing the requested data item, then it is read from main memory into the cache and becomes available for subsequent calls. This is called a cache miss.
In BESM-6, instead of this model, there were only four so-called. buffer number registers (BRCH), where words were read from memory, so that later the ALU could access them faster. Likewise, there were 8 (again strange asymmetries) buffer write registers (BRZ) where the number was placed before being written to memory. The address where the operand should be written was saved in the so-called. BAZ (buffer write address register). If later it turned out that the executive address coincides with one of the addresses in the BAZ / BAS, the operand was taken from the BRZ / BRCH, and not from memory. That's the whole "cache" in Besm way.
And finally, the final misconception is the idea that BESM-6 was a harbinger of RISC architecture.
Of course, there are not too many commands in BESM-6, rather few, but this is the only parameter by which it is similar to RISC. However, a full-fledged RISC processor: it has a small set of simple instructions, a huge number of RON (general-purpose registers), a developed scheme for renaming them, elementary instructions and a predictable and standard execution speed of any of them - 1–2 clock cycles.
If you have read the article up to this point, you already understand that BESM-6 flew here in all parameters, except for the number of commands.
As we have already said, everything was sad with the software in BESM-6.
It was delivered only with the forerunner of the OS "Dispatcher-68" developed by ITMiVT, which allowed only the batch launch of tasks and the allocation of resources to them. The Lebedev autocode was proposed as a language, which was immediately abandoned by all adequate people. As we have already mentioned, the expectation was that it would be possible to immediately launch the entire array of software from CDC 6 on the BESM-1604, but it did not come true. As a result, each scientific group feverishly began to saw for themselves various implementations of languages and operating systems, of course, incompatible with each other.
The coolest among them was the “Dubna” monitor system - and the USSR did not have enough forces for it, it was necessary to involve Germans from the GDR, Hungarians and even Mongols - the entire JINR International Committee.
The stolen Fortran and Algol-60 compilers, much later LISP and Pascal, were successfully used for it, but all this at the cost of hellish efforts. Algol-60 was originally created at the Computing Center of the USSR Academy of Sciences in the Programming Laboratory under the leadership of V.M. Kurochkin, first for BESM-2, later ported to BESM-6 (for BESM-4 there were at least 3 different compilers with Algol-60, not less than 2 different assemblers, Dubninsky and Bayakovsky and a compiler from the original Epsilon language - this is such a typical zoo), and as many said, it remained for her the only non-stick translator from the popular language.
The trouble was that in 1964 a new language specification came out, usually called (after the final year of the standard's adoption) Algol-68, which Kurochkin no longer mastered. The CDC 68 Algol-1604 translator worked crookedly, which broke off the launch of many CERN programs that our physicists in Dubna were counting on.
In Europe, Algol-68 has long been used by the British Royal Committee for Communications and Radar.
In the USSR, there were working groups for the development of Algol-68 (for example, Novosibirsk under the leadership of Academician Andrei Petrovich Ershov, Leningrad under the leadership of Andrei Nikolaevich Terekhov, Moscow under the leadership of Alexander Nikolaevich Maslov and Mikhail Ruvimovich Levinson). At the Leningrad State University, a compiler and a powerful programming system in Algol-68 were created, but ... already for the ES computers, which had been in operation for many years (by the way, this is why, including in Dubna, the EU appeared, for the sake of a developed periphery and for the sake of a huge number of software and compilers not available for BESM-6 or working incorrectly).
Just a reference photo - installation of two BESM-6 at the same time in the Moscow State University Computing Center (photo http://www.besm-6.su)
Many programs appeared after familiarization with foreign source codes, for example, the already mentioned N.N. Govorun from LVT JINT, after a trip to CERN using machine printouts with CDC 3200 made in their computer center, implemented six BESMs on BESM-6 Fortran and libraries of standard programs -6 were transferred to the GDR, and their programmers from JINR, having gone to their homeland, made their own version of the assembler, Fortran-GDR and Algol-GDR (which worked 20-30% faster than domestic ones).
Z. F. Bochkova, G. N. Ezerov, V. M. Mikhelev under the leadership of V. S. Shtarkman from the Institute of Applied Mathematics. Keldysh (after his trip to IBM) developed the BMSH autocode, since the original autocode of M.G. Tchaikovsky, based on the mnemonics of Lebedev himself, was fundamentally two-letter and absolutely illogical and unreadable, which gave rise to many incompatible alterations.
The BESM-6 file system was never written and completed to the end, in general, in each scientific center it was possible to write something of its own to the detriment of everything else. In Chelyabinsk, there was archiving on tapes, in Dubna - the human language for describing tasks from both Fortran-GDR and Algol-GDR, at the VMK MSU - LISP and DISPAK.
A separate holiday was the documentation for the BESM-6. Imagine that you are an ordinary graduate student or junior researcher who came to work from the faculty of, say, mathematics. And you are offered to delve into IT. For such a quality description of the machine for end users, these users in the United States would have burned Cray at the stake from the instructions.
Of course, both the original OS / 360 and IBM had a problem, but they corrected the situation extremely quickly, in the USSR, the mess with thousands of libraries written at different times by just anyone and incompatible with each other was never resolved in all areas where it was not about direct copying of EU software.
Everything that BESM-6 fans are so proud of - the famous OS ND-70, Dubna, DISPAK, etc., were developed only by the mid-1970s. Thanks to DISPAK, in 1972 it was finally mastered to connect hard drives with controllers taken from General Electric to BESM-6, before that people worked with an archaic drum, originally from the early 1950s.
IBM machines have been working with disks since 1956 - this is the question of the "advanced architecture" of BESM-6. One drum had a capacity of 16 kilo words (192 kilobytes) and weighed half a ton. The drums could be attached to a maximum of 4 pieces. At the same time, conventional IBM hard drives had a capacity of 5 megabytes, and large ones - 30 megabytes. Note that BESM-6 in Dubna had some hardware differences, ranging from the parity of characters in terminal lines to bits of the physical address in registers.
As a result, OS "Dubna" did not start on machines with more than 4 cubes of memory, because the extra bits of the physical address are used by the dispatcher for their own purposes. Overall, this explains why Dubna was not popular elsewhere.
In general, people who are far from Western computer design often cannot understand that the main thing in a machine is not hardware, but software. Not programs are written for a finished machine. The machine is created so that it would be convenient to write programs for it, and even better - to use the existing ones with minimal changes. Unfortunately, even in the West, not everyone has understood the essence of this simple axiom.
Fred Brooks, one of the leading developers of Stretch, put it very clearly - designing any computer architecture should begin with collecting user requirements, and not the personal deep-thinking shiza of a particular system architect and his personal unique vision of what the machine should turn out to be.
Not people for a computer, but a computer for people.
The second step is to formulate a draft of the instruction set that most satisfies end users (and for a system architect, end users are low-level programmers who will create all the software for ordinary mortals), and only then the development of specific circuitry solutions begins.
This cycle was perfectly mastered by two companies - IBM, which learned from Stretch and created the great S / 360, and Burroughs, which similarly developed the equally great B5000 series (here we are talking about mass commercial machines, CDC and Cray similarly created scientific supercomputers - collecting applications and the requirements of scientists and trying to satisfy them as much as possible).
As a result, Z-series mainframes are still compatible with machines from the 1960s, the banking sector has billions of lines of code written in COBOL since Kennedy's time, and IBM and Burroughs (incarnated as UNISYS) were the only mainframe makers to emerge from the XNUMXth century. when they were founded, in the XXI century.
In the USSR, this axiom, alas, was not realized (from the word at all), taking into account the fact that by 1960 we had ITMiVT as a monopolist comparable to IBM. The same Yuditsky designed the Almaz for the specific requirements of the missile defense system (and then the GRU), and his potential users were delighted with the prototypes of the machine, although he was not allowed to release a series. In ITMiVT, everything was different, by default it was believed that the genius Lebedev knows better than you what computer you need, he is a professional, so you live with the command system and architecture that he gave birth to.
For people who are well acquainted with modern technologies, familiarity with, for example, the details of the implementation of working with memory in the S / 360 does not cause misunderstanding or disgust. Acquaintance with the peculiarities of low-level programming in BESM-6 often shocks modern programmers. In fact, the grandfathers had no easier time, so the software for BESM-6 was written for a long, very long time, until her death in the 1990s.
Some of the implementations were successful, some were not very good, all this was done by the efforts of scattered research institutes and research centers, somehow spreading across the country in different versions. The myth about the quality and quantity of software for BESM-6 arose largely from the fact that, firstly, almost 400 of them were produced (including modifications), which was incredible by the standards of the Union, its own BESM-6 was in almost every major scientific center, and secondly, they were riveted for 20 years and used for 40 years.
As a result, scientists, people are far from stupid, during this time they were able to give birth to quite a few tolerable programs. Naturally, there were also large theoretical schools of programming (in general, Soviet programmers of maximum strength, world-renowned as theorists of computer science, were people who came there from mathematics, starting with Lyapunov and Shura-Bura).
Theoretical principles of OS and compilers construction were developed, articles were written, dissertations were defended, scientific schools were created. All this was, of course, worthy of both quantity and quality.
The only problem was that excellent academic science was sitting in its ivory tower, helping with epoch-making developments, such as DISPAK, Dubna and ND-70, but the country needed tens of thousands of programmers, not just tens of programming academics. We had no problems with them, but with ordinary coders ...
In the next article, we will complete the consideration of this epoch-making domestic development.
To be continued ...
- Alexey Eremenko
- https://www.computerhistory.org, http://www.besm-6.su, https://www.1500py470.livejournal.com
Information