Article T: integrated building blocks for parallel computing Share on Authors: G. M. Papadopoulos Lab for Comp. Sci., MIT 545 Technology Square, Cambridge, MA Lab for Comp. Sci., MIT 545 Technology Square, Cambridge, MAView Profile , G. A. Boughton Lab for Comp. Sci., MIT 545 Technology Square, Cambridge, MA Lab for Comp. Sci., MIT 545 Technology Square, Cambridge, MAView Profile , R. Greiner Motorola, Motorola, Inc., DW220, 2900 South Diablo Way, Tempe, AZ Motorola, Motorola, Inc., DW220, 2900 South Diablo Way, Tempe, AZView Profile , M. J. Beckerle Motorola, Motorola Cambridge Research Center, One Kendall Square, Bld 200, Cambridge, MA Motorola, Motorola Cambridge Research Center, One Kendall Square, Bld 200, Cambridge, MAView Profile Authors Info & Claims Supercomputing '93: Proceedings of the 1993 ACM/IEEE conference on SupercomputingDecember 1993 Pages 624–635https://doi.org/10.1145/169627.169811Online:01 December 1993Publication History 20citation170DownloadsMetricsTotal Citations20Total Downloads170Last 12 Months4Last 6 weeks2 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteGet Access

What should the architecture of each node in a general purpose, massively parallel architecture (MPA) be? We frame the question in concrete terms by describing two fundamental problems that must be solved well in any general purpose MPA. From this, we systematically develop the required logical organization of an MPA node, and present some details of *T (pronounced Start, a concrete architecture designed to these requirements. *T is a direct descendant of dynamic dataflow architectures, and unifies them with von Neumann architectures. We discuss a hand-compiled example and some compilation issues.

An aggressive, integrated hardware/software approach for the test and validation of Monsoon processing elements is developed. The strategy comprises three main elements: scan-paths of internal processor state, gate-level simulator of the entire processing element for hardware timing verification, and a novel table-driven instruction-level interpreter. Each of these elements is detailed, and it is shown how they contribute to design, test, validation, and debug.>

Monsoon is an experimental multi-threaded multiprocessor targeted to large-scale, general purpose scientific and symbolic computations. In particular, Monsoon is designed for the efficient execution of code compiled from Id, a high-level, implicitly parallel declarative language. Monsoon is a product of a multiyear cooperative research and development program between the Massachusetts Institute of Technology (MIT) and Motorola, Inc., which, in turn is an outgrowth of over ten years of research in dynamic dataflow architectures and languages conducted at MIT. The intent is to provide an overall view of the Monsoon hardware and software system architecture. In addition, the run-time system and emulator are detailed.>

Althoughthey are powerful intermediate representations for

Dataflow architectures tolerate long unpredictable communication delays and support generation and coordination of parallel activities directly in hardware, rather than assuming that program mapping will cause these issues to disappear. However, the proposed mechanisms are complex and introduce new mapping complications. This paper presents a greatly simplified approach to dataflow execution, called the explicit token store (ETS) architecture, and its current realization in Monsoon. The essence of dynamic dataflow execution is captured by a simple transition on state bits associated with storage local to a processor. Low-level storage management is performed by the compiler in assigning nodes to slots in an activation frame, rather than dynamically in hardware. The processor is simple, highly pipelined, and quite general. It may be viewed as a generalization of a fairly primitive von Neumann architecture. Although the addressing capability is restrictive, there is exactly one instruction executed for each action on the dataflow graph. Thus, the machine oriented ETS model provides new understanding of the merits and the real cost of direct execution of dataflow graphs.