The problem of determining derivatives on a digital computer has received a great deal of attention for several years. Some exotic systems have been developed and numerous papers have treated the problem. In 1964 it was suggested by Wengert that the chain rule could be applied to values for the determination of derivatives.
{"title":"The Q approach to problem solving","authors":"J. McCully","doi":"10.1145/1478559.1478643","DOIUrl":"https://doi.org/10.1145/1478559.1478643","url":null,"abstract":"The problem of determining derivatives on a digital computer has received a great deal of attention for several years. Some exotic systems have been developed and numerous papers have treated the problem. In 1964 it was suggested by Wengert that the chain rule could be applied to values for the determination of derivatives.","PeriodicalId":230827,"journal":{"name":"AFIPS '69 (Fall)","volume":"110 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1899-12-30","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115252825","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
The advent of modern electronic computers has expanded the scope of nearly all areas of scientific endeavor. The electrical engineer is perhaps most acutely affected by this expanision by virtue of his two-fold interest in computer processes. He is, as are his colleagues of other scientific disciplines, excited by the computing capabilities now at his disposal. Even more, he is deeply involved by virtue of his responsibility for the conception and design of the computer and its hardware adaptation to a variety of applications. It is to the second phase of the electrical engineer's involvement with computers that our educational activities are directed, that is, to his involvement in the realization of computers or computerlike systems.
{"title":"A computer engineering laboratory","authors":"D. M. Robinson","doi":"10.1145/1478559.1478621","DOIUrl":"https://doi.org/10.1145/1478559.1478621","url":null,"abstract":"The advent of modern electronic computers has expanded the scope of nearly all areas of scientific endeavor. The electrical engineer is perhaps most acutely affected by this expanision by virtue of his two-fold interest in computer processes. He is, as are his colleagues of other scientific disciplines, excited by the computing capabilities now at his disposal. Even more, he is deeply involved by virtue of his responsibility for the conception and design of the computer and its hardware adaptation to a variety of applications. It is to the second phase of the electrical engineer's involvement with computers that our educational activities are directed, that is, to his involvement in the realization of computers or computerlike systems.","PeriodicalId":230827,"journal":{"name":"AFIPS '69 (Fall)","volume":"105 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1899-12-30","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124222124","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
The system engineer operating within the framework of a typical manufacturing organization operates from the following basic information and constraints: a. A set of customer specifications to be met, b. A basic system configuration to be used in realizing these specifications, c. A set of standard components that fit into this configuration. The problem is to determine the collection of components that satisfies the given specification at minimum total dollar cost.
{"title":"Directed library search to minimize cost","authors":"Bruce A. Chubb","doi":"10.1145/1478559.1478631","DOIUrl":"https://doi.org/10.1145/1478559.1478631","url":null,"abstract":"The system engineer operating within the framework of a typical manufacturing organization operates from the following basic information and constraints:\u0000 a. A set of customer specifications to be met,\u0000 b. A basic system configuration to be used in realizing these specifications,\u0000 c. A set of standard components that fit into this configuration. The problem is to determine the collection of components that satisfies the given specification at minimum total dollar cost.","PeriodicalId":230827,"journal":{"name":"AFIPS '69 (Fall)","volume":"13 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1899-12-30","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"128217076","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Any input device used in conjunction with a computer controlled display for interactive information exchange between man and computer must function as a position encoder. Input devices for handling two dimensional positional information can be grouped into two general types, one type encoding absolute positions and the other encoding changes in position.
{"title":"A touch sensitive X-Y position encoder for computer input","authors":"A. Hlady","doi":"10.1145/1478559.1478625","DOIUrl":"https://doi.org/10.1145/1478559.1478625","url":null,"abstract":"Any input device used in conjunction with a computer controlled display for interactive information exchange between man and computer must function as a position encoder. Input devices for handling two dimensional positional information can be grouped into two general types, one type encoding absolute positions and the other encoding changes in position.","PeriodicalId":230827,"journal":{"name":"AFIPS '69 (Fall)","volume":"12 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1899-12-30","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124887538","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
An on-line software checkout facility for special purpose computers (referred to as the Flight Software Development Laboratory) has been created to aid programmer/engineers in the development of programs that will operate in a spaceborne computer aboard the Apollo/Saturn IB and V Launch Vehicles. The Flight Computer operates as an integral part of various vehicle subsystems in the Instrument Unit (IU). The subsystems provide onboard navigation, guidance, control, sequencing, data compression, and ground communications. These functions are illustrated in Figure 1. Continued emphasis is placed on error-free flight software, since it is an essential element in overall vehicle performance. No opportunity exists to test or exercise the flight program in its actual flight environment prior to a mission. Therefore, to ensure the integrity of the flight program, simulators are used to accomplish flight testing. The purpose of this paper is to present the organization of one such simulator that has been created for the sole purpose of the development and checkout of Saturn flight software. The emphasis throughout the design and implementation of the Laboratory has been that it must be user-oriented for program checkout. Before the existence of the Laboratory, available facilities for checking out flight programs were oriented to hardware checkout. Although such facilities can be, and have been, rigged for program checkout, they have not provided the type of assistance required to produce the quality of software demanded by spaceborne computers. The Laboratory is believed to be unique in the capabilities it provides to the programmer/engineer in controlling and affecting the operation of the Flight Computer in a real-time environment.
{"title":"On-line software checkout facility for special purpose computers","authors":"J. Hughes, T. Witzel","doi":"10.1145/1478559.1478654","DOIUrl":"https://doi.org/10.1145/1478559.1478654","url":null,"abstract":"An on-line software checkout facility for special purpose computers (referred to as the Flight Software Development Laboratory) has been created to aid programmer/engineers in the development of programs that will operate in a spaceborne computer aboard the Apollo/Saturn IB and V Launch Vehicles. The Flight Computer operates as an integral part of various vehicle subsystems in the Instrument Unit (IU). The subsystems provide onboard navigation, guidance, control, sequencing, data compression, and ground communications. These functions are illustrated in Figure 1. Continued emphasis is placed on error-free flight software, since it is an essential element in overall vehicle performance. No opportunity exists to test or exercise the flight program in its actual flight environment prior to a mission. Therefore, to ensure the integrity of the flight program, simulators are used to accomplish flight testing. The purpose of this paper is to present the organization of one such simulator that has been created for the sole purpose of the development and checkout of Saturn flight software. The emphasis throughout the design and implementation of the Laboratory has been that it must be user-oriented for program checkout. Before the existence of the Laboratory, available facilities for checking out flight programs were oriented to hardware checkout. Although such facilities can be, and have been, rigged for program checkout, they have not provided the type of assistance required to produce the quality of software demanded by spaceborne computers. The Laboratory is believed to be unique in the capabilities it provides to the programmer/engineer in controlling and affecting the operation of the Flight Computer in a real-time environment.","PeriodicalId":230827,"journal":{"name":"AFIPS '69 (Fall)","volume":"227 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1899-12-30","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121160346","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Long term mission reliability of a modular computer has been studied at Hughes Aircraft Company as a consequence of a study with NASA ERC. Particular interest lay in the attainment of long term reliability with modular computer organization and the effects on reliability of variations in modular organization. The results of this investigation are presented in this paper.
{"title":"Modular computer architecture strategy for long term missions","authors":"F. D. Erwin, E. Bersoff","doi":"10.1145/1478559.1478598","DOIUrl":"https://doi.org/10.1145/1478559.1478598","url":null,"abstract":"Long term mission reliability of a modular computer has been studied at Hughes Aircraft Company as a consequence of a study with NASA ERC. Particular interest lay in the attainment of long term reliability with modular computer organization and the effects on reliability of variations in modular organization. The results of this investigation are presented in this paper.","PeriodicalId":230827,"journal":{"name":"AFIPS '69 (Fall)","volume":"127 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1899-12-30","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121224545","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Testing of complex integrated cellular logic circuits fabricated using LSI techniques has become a source of concern to users and manufacturers. Since an economically feasible solution to testing problems is not visible for the complex arrays contemplated for the near future, manufacturers have acknowledged the seriousness of the problem. Currently some observers believe that LSI cannot be tested because general procedures for testing and diagnosing digital circuits are applicable to small networks of approximately 30 gates, while cellular arrays are contemplated as containing hundreds or thousands of gates on one chip. However, if arrays are constrained to be in a cellular form, then testing problems can be simplified and test schedules can be produced which use the interconnection structure of cellular arrays.
{"title":"Fault location in cellular arrays","authors":"K. Thurber","doi":"10.1145/1478559.1478569","DOIUrl":"https://doi.org/10.1145/1478559.1478569","url":null,"abstract":"Testing of complex integrated cellular logic circuits fabricated using LSI techniques has become a source of concern to users and manufacturers. Since an economically feasible solution to testing problems is not visible for the complex arrays contemplated for the near future, manufacturers have acknowledged the seriousness of the problem. Currently some observers believe that LSI cannot be tested because general procedures for testing and diagnosing digital circuits are applicable to small networks of approximately 30 gates, while cellular arrays are contemplated as containing hundreds or thousands of gates on one chip. However, if arrays are constrained to be in a cellular form, then testing problems can be simplified and test schedules can be produced which use the interconnection structure of cellular arrays.","PeriodicalId":230827,"journal":{"name":"AFIPS '69 (Fall)","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1899-12-30","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129575399","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
The control of large military forces is creating the need for large data-processing systems located in transport aircraft and in other situations where tight quarters and hostile environments call for the design features found in airborne systems. In these applications the configuration of the computer and its peripheral equipment strongly resembles what is found in a typical commercial data-processing system, with some additional requirements for reliability. In particular, the functional programs are complex and extensive, and the availability of a complete package of support software, including compilers and utility routines as well as the resident executive, is likely to be of critical importance. Because of its cost, so complete a software package cannot reasonably be developed specifically to answer a particular military need; it must be captured from an existing software system. The only source of complete data-management software packages is commercial data-processing; and thus it makes practical sense for a large, militarized data-processing computer to be strictly compatible with an existing commercial product. As a bonus, the commercial computer can then be used as a support computer for compilation and program checkout. An example of a program in which an airborne computer is supported by an existing ground-based commercial computer is found in the Strategic Air Command's Post Attack Command and Control System---Airborne Data Automation. In this system the airborne computer is the RCA/USAF Variable Instruction Computer and the ground support computer is the IBM 7090.
{"title":"A compatible airborne multiprocessor","authors":"E. Dieterich, L. Kaye","doi":"10.1145/1478559.1478599","DOIUrl":"https://doi.org/10.1145/1478559.1478599","url":null,"abstract":"The control of large military forces is creating the need for large data-processing systems located in transport aircraft and in other situations where tight quarters and hostile environments call for the design features found in airborne systems. In these applications the configuration of the computer and its peripheral equipment strongly resembles what is found in a typical commercial data-processing system, with some additional requirements for reliability. In particular, the functional programs are complex and extensive, and the availability of a complete package of support software, including compilers and utility routines as well as the resident executive, is likely to be of critical importance. Because of its cost, so complete a software package cannot reasonably be developed specifically to answer a particular military need; it must be captured from an existing software system. The only source of complete data-management software packages is commercial data-processing; and thus it makes practical sense for a large, militarized data-processing computer to be strictly compatible with an existing commercial product. As a bonus, the commercial computer can then be used as a support computer for compilation and program checkout. An example of a program in which an airborne computer is supported by an existing ground-based commercial computer is found in the Strategic Air Command's Post Attack Command and Control System---Airborne Data Automation. In this system the airborne computer is the RCA/USAF Variable Instruction Computer and the ground support computer is the IBM 7090.","PeriodicalId":230827,"journal":{"name":"AFIPS '69 (Fall)","volume":"413 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1899-12-30","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"122481128","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
This paper describes the results of a collaborative design effort aimed at development of a general purpose display system for the SDS-940 time-shared computer. The important features of the system evolved gradually from a number of separate design goals. We wanted a display system that would: 1. Contain an extensive but straightforward set of display generating commands. 2. Be able to generate pictures from highly complex data structures. 3. Allow easy access to display files from user programs in the main computer. 4. Provide some immediate feedback and interactive processing service to the display user, and be able to call upon the main computer for more extensive service. 5. Permit attachment of special purpose display generation and interactive hardware, as well as multiple display consoles. 6. Be capable of time-sharing its central resources among separate console-users.
{"title":"A display processor design","authors":"R. Watson, T. Myer, I. Sutherland, M. K. Vosbury","doi":"10.1145/1478559.1478584","DOIUrl":"https://doi.org/10.1145/1478559.1478584","url":null,"abstract":"This paper describes the results of a collaborative design effort aimed at development of a general purpose display system for the SDS-940 time-shared computer. The important features of the system evolved gradually from a number of separate design goals. We wanted a display system that would:\u0000 1. Contain an extensive but straightforward set of display generating commands.\u0000 2. Be able to generate pictures from highly complex data structures.\u0000 3. Allow easy access to display files from user programs in the main computer.\u0000 4. Provide some immediate feedback and interactive processing service to the display user, and be able to call upon the main computer for more extensive service.\u0000 5. Permit attachment of special purpose display generation and interactive hardware, as well as multiple display consoles.\u0000 6. Be capable of time-sharing its central resources among separate console-users.","PeriodicalId":230827,"journal":{"name":"AFIPS '69 (Fall)","volume":"37 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1899-12-30","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123010261","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
H. Potash, A. Tyrrill, D. Allen, S. Joseph, G. Estrin
This article is concerned with the problems of digital simulation and describes methods used in the Digital Control Design System (DCDS) for the simulation of digital structures. The paper is divided into five parts: • A short introduction to DCDS, its structure and purposes. • A discussion of simulation techniques, entities and attributes. • The DCDS pseudo machine simulator. • The pseudo machine program. • A simple example of a DCDL program.
{"title":"DCDS digital simulating system","authors":"H. Potash, A. Tyrrill, D. Allen, S. Joseph, G. Estrin","doi":"10.1145/1478559.1478645","DOIUrl":"https://doi.org/10.1145/1478559.1478645","url":null,"abstract":"This article is concerned with the problems of digital simulation and describes methods used in the Digital Control Design System (DCDS) for the simulation of digital structures. The paper is divided into five parts:\u0000 • A short introduction to DCDS, its structure and purposes.\u0000 • A discussion of simulation techniques, entities and attributes.\u0000 • The DCDS pseudo machine simulator.\u0000 • The pseudo machine program.\u0000 • A simple example of a DCDL program.","PeriodicalId":230827,"journal":{"name":"AFIPS '69 (Fall)","volume":"366 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1899-12-30","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115902249","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}