SNAP(ID:6503/sna004)
Ramo Woolridge floating point package for UNIVAC 1103
Ramo Woolridge interpreter for UNIVAC 1103, operational August 1955
Developed by R. Beach, D. Gantner, M. Perry, M. Speer, R. Summers under the direction of William Bauer at Ramo-Woolridge LA 1955
As it targetted RAWOOP, it was later bundled with it into the RAWOOP-SNAP package for 1103A
Places Hardware:
- UNIVAC 1103 Sperry Univac
Related languages
| SNAP | => | RAWOOP/SNAP | Incorporated into | |
| SNAP | => | SNIP | Extension of |
References:
1. SNAP 10/10/55
2. SNAP SAMPLER TRACE 3/27/56
3. SNIP (SNAP Complex) 5/1/56
in 1103 CENTRAL EXCHANGE NEWSLETTER NUMBER 9, June 1956 view details
in 1103 CENTRAL EXCHANGE NEWSLETTER NUMBER 9, June 1956 view details
SNAP Description
SNAP is an interpretive floating point package for the ERA 1103. It contains a single address floating binary point arithmetic section, floating decimal data input and output on cards, fixed-to-floating and floatlng-to-fixed conversion, square root, load and store operations. Additional features include an address modifier, or "B-box", and optional replacement of the result of an operation in the address of the operand. Experience has shown that representative programs using SHAP operate at about 1,000 programmed operations per second. The speed is obtained by fast floating point operations and the fact that many operations are performed at machine speed.
The package is entered by execution of an Interpret (IP) instruction. The u and v portions of this instruction each contain a complete SNAP command. Of these fifteen bits, four contain the operation part, one the B-box option, one the replace option, and the remaining nine the address part. Accordingly, only the lower half (512 cells) of electrostatic may be addressed directly. However, use of the B-box makes any electrostatic or magnetic drum cell indirectly addressable.
A packed number representation is used and results are normalized after each execution. Each floating point number occupies one 36 bit cell. One bit contains the sign, eight the characteristic and twenty-seven the mantissa, Hence the range of the numbers is approximately +/- 1038 and approximately eight significant decimal digits are contained in the mantissa. The representation is such that all 1103 logical commands may be validly applied. Therefore, floating point number comparisons may be made at regular machine speed and no need exists for inclusion of comparison commands in the SNAP repertoire.
SNAP occupies approximately 900 cells on the magnetic drum and 300 cells in electrostatic. When a card is to be punched or read, appropriate coding is brought in automatically from the drum. These are the only occasions on which drum references are made.
SNAP commands may be written with alphabetic operations and symbolic addresses, and then assembled by RAWOOP. Floating point numbers may also be included in the program and will be converted and assembled by RAWOOP.
Storage Extract: Symbolic Coding
Symbolic Coding
Although it is possible to code for SNAP in octal, it is much easier to code symbolically for assembly on RAWOOP, The advantages of using alphabetic operations and symbolic addresses are magnified by the peculiar command structure of SNAP instructions. Regular machine instructions may be interspersed arbitrarily with SNAP instructions.
At the end of this section is a facsimile of a standard RAWOOP coding sheet. It contains some sample floating point numbers and SNAP instructions (not a program), and their assembled equivalents (in the Comments column). There are two alphabetic operations, two symbolic addresses, and two optional B-box and store columns in each instruction. The left hand items in each pair are combined to form the left SNAP command,, the right hand items to form the right command. The numbers in rows (l), (2), and (3) are respectively .125 -4096, and 1.125.
Consult the RAWOOP write-up for more complete details on symbolic coding.
Extract: Subroutines
Subroutines
Many of the common subroutines have been coded using the SNAP number representation for argument and result. Others are in process. Their use is extremely simple.
It is, however, possible to employ any fixed point subroutine in a floating point program by the expedient of the Fix and Float commands contained in SNAP. Note that conversion is rapid and that scaling is easily supplied in the address part of the command.
Extract: Design Criteria
Design Criteria
The philosophy which leads to this package states that, in order of importance, the following three items are virtues:
(1) Simplicity - To produce faster coding with fewer errors.
(2) Execution speed - To conserve machine time.
(3) Minimum storage usage - Both in the problem program and in the package, to conserve high speed storage.
With these in mind, a single address system was chosen. While logical operations are generally best served by multiple addresses, use of a single address is indicated for arithmetic operations. Since the four basic arithmetic operations may occur in a great variety of sequences, a multiple address system must either waste many of the addresses or contain contain a very large number of arithmetic command types.
Wasting addresses wastes storage in the main program; inclusion of a large number of command types expends storage in the package, Thus (3) is satisfied by the single address. With only one kind of each of the arithmetic operations, jumping and sorting in the arithmetic section is minimized.
Furthermore, use of only one operand saves the unpacking of multiply packed numbers. So the requirements of (2) are met. Finally, the consideration of (1), ultimate simplicity is achieved with a system which always operates on the same register with but a singlet operand.
in 1103 CENTRAL EXCHANGE NEWSLETTER NUMBER 9, June 1956 view details
Let me elaborate these points with examples. UNICODE is expected to require about fifteen man-years. Most modern assembly systems must take from six to ten man-years. SCAT expects to absorb twelve people for most of a year. The initial writing of the 704 FORTRAN required about twenty-five man-years. Split among many different machines, IBM's Applied Programming Department has over a hundred and twenty programmers. Sperry Rand probably has more than this, and for utility and automatic coding systems only! Add to these the number of customer programmers also engaged in writing similar systems, and you will see that the total is overwhelming.
Perhaps five to six man-years are being expended to write the Alodel 2 FORTRAN for the 704, trimming bugs and getting better documentation for incorporation into the even larger supervisory systems of various installations. If available, more could undoubtedly be expended to bring the original system up to the limit of what we can now conceive. Maintenance is a very sizable portion of the entire effort going into a system.
Certainly, all of us have a few skeletons in the closet when it comes to adapting old systems to new machines. Hardly anything more than the flow charts is reusable in writing 709 FORTRAN; changes in the characteristics of instructions, and tricky coding, have done for the rest. This is true of every effort I am familiar with, not just IBM's.
What am I leading up to? Simply that the day of diverse development of automatic coding systems is either out or, if not, should be. The list of systems collected here illustrates a vast amount of duplication and incomplete conception. A computer manufacturer should produce both the product and the means to use the product, but this should be done with the full co-operation of responsible users. There is a gratifying trend toward such unification in such organizations as SHARE, USE, GUIDE, DUO, etc. The PACT group was a shining example in its day. Many other coding systems, such as FLAIR, PRINT, FORTRAN, and USE, have been done as the result of partial co-operation. FORTRAN for the 705 seems to me to be an ideally balanced project, the burden being carried equally by IBM and its customers.
Finally, let me make a recommendation to all computer installations. There seems to be a reasonably sharp distinction between people who program and use computers as a tool and those who are programmers and live to make things easy for the other people. If you have the latter at your installation, do not waste them on production and do not waste them on a private effort in automatic coding in a day when that type of project is so complex. Offer them in a cooperative venture with your manufacturer (they still remain your employees) and give him the benefit of the practical experience in your problems. You will get your investment back many times over in ease of programming and the guarantee that your problems have been considered.
Extract: IT, FORTRANSIT, SAP, SOAP, SOHIO
The IT language is also showing up in future plans for many different computers. Case Institute, having just completed an intermediate symbolic assembly to accept IT output, is starting to write an IT processor for UNIVAC. This is expected to be working by late summer of 1958. One of the original programmers at Carnegie Tech spent the last summer at Ramo-Wooldridge to write IT for the 1103A. This project is complete except for input-output and may be expected to be operational by December, 1957. IT is also being done for the IBM 705-1, 2 by Standard Oil of Ohio, with no expected completion date known yet. It is interesting to note that Sohio is also participating in the 705 FORTRAN effort and will undoubtedly serve as the basic source of FORTRAN-to- IT-to-FORTRAN translational information. A graduate student at the University of Michigan is producing SAP output for IT (rather than SOAP) so that IT will run on the 704; this, however, is only for experience; it would be much more profitable to write a pre-processor from IT to FORTRAN (the reverse of FOR TRANSIT) and utilize the power of FORTRAN for free.
in "Proceedings of the Fourth Annual Computer Applications Symposium" , Armour Research Foundation, Illinois Institute of Technology, Chicago, Illinois 1957 view details
Bob Bemer states that this table (which appeared sporadically in CACM) was partly used as a space filler. The last version was enshrined in Sammet (1969) and the attribution there is normally misquoted.
in [ACM] CACM 2(05) May 1959 view details
in E. M. Crabbe, S. Ramo, and D. E. Wooldridge (eds.) "Handbook of Automation, Computation, and Control," John Wiley & Sons, Inc., New York, 1959. view details
in [ACM] CACM 6(03) (Mar 1963) view details