Our first effort went into designing and analyzing the hypercube network as a message passing switch. We aimed at making a VLSI chips, one for each node, which should store and forward the messages. Message passing have some negative effects: Message delays are both unpredictable and significant, nodes have to be able to store messages, thereby increasing chip size, and finally it was discovered during simulation tests that deadlocks occurred rather frequently. Later a remedy for deadlock was found, but the other negative indicators are still valid. The result: we abandoned the message passing method and turned to line switching. Still there should be one chip in each node. The hypercube line switching node has one communication path to each neighbor (D lines in a D dimensional cube) and two paths to the node computer. The chip should be able to participate in decentralized routing through the cube, and when a connection is established: hold a path through the node. An outline of the node functions will be given. A line switching hypercube network will have enormous data transmission capacity. In a D dimensional cube with N=2D nodes, at most N channels can be active at the same time. (Remember that each node computer has both an input port and an output port). 10 MB/sec data transfer rate on each channel is well within reach. The critical operation is to establish a path through the hypercube. Set up time varies with network size and load, clock frequency and actual path through the network. With the same clock frequency as already mentioned, the normal set up time under light load conditions is from 1 to 3 microseconds. An analysis of the path setup process has been carried out. The focus has been on the probability of being able to establish a path under a given load condition. The load is defined as the number of established (active) channels over N. Two approximate analytical models are developed and compared with results from a simulation model. All models give the same picture, and it is safe to say that for loads less or equal to 50% the probability of getting through is very high, almost 1.0 for larger cubes, i.e. D > 8. For loads larger than 80% almost all requests are denied.
{"title":"Performance analysis of the hypercube line switch","authors":"K. Bratbergsengen","doi":"10.1145/62297.62375","DOIUrl":"https://doi.org/10.1145/62297.62375","url":null,"abstract":"Our first effort went into designing and analyzing the hypercube network as a message passing switch. We aimed at making a VLSI chips, one for each node, which should store and forward the messages. Message passing have some negative effects: Message delays are both unpredictable and significant, nodes have to be able to store messages, thereby increasing chip size, and finally it was discovered during simulation tests that deadlocks occurred rather frequently. Later a remedy for deadlock was found, but the other negative indicators are still valid. The result: we abandoned the message passing method and turned to line switching.\u0000Still there should be one chip in each node. The hypercube line switching node has one communication path to each neighbor (D lines in a D dimensional cube) and two paths to the node computer. The chip should be able to participate in decentralized routing through the cube, and when a connection is established: hold a path through the node. An outline of the node functions will be given.\u0000A line switching hypercube network will have enormous data transmission capacity. In a D dimensional cube with N=2D nodes, at most N channels can be active at the same time. (Remember that each node computer has both an input port and an output port). 10 MB/sec data transfer rate on each channel is well within reach. The critical operation is to establish a path through the hypercube. Set up time varies with network size and load, clock frequency and actual path through the network. With the same clock frequency as already mentioned, the normal set up time under light load conditions is from 1 to 3 microseconds.\u0000An analysis of the path setup process has been carried out. The focus has been on the probability of being able to establish a path under a given load condition. The load is defined as the number of established (active) channels over N. Two approximate analytical models are developed and compared with results from a simulation model. All models give the same picture, and it is safe to say that for loads less or equal to 50% the probability of getting through is very high, almost 1.0 for larger cubes, i.e. D > 8. For loads larger than 80% almost all requests are denied.","PeriodicalId":299435,"journal":{"name":"Conference on Hypercube Concurrent Computers and Applications","volume":"15 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1900-01-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125563142","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}
for the Macintosh permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission.
{"title":"Transputer systems for the Macintosh","authors":"Corporate Levco","doi":"10.1145/62297.62421","DOIUrl":"https://doi.org/10.1145/62297.62421","url":null,"abstract":"for the Macintosh permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission.","PeriodicalId":299435,"journal":{"name":"Conference on Hypercube Concurrent Computers and Applications","volume":"46 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1900-01-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121987383","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 discusses problems associated with designing a processor capable of sustaining a teraflop (1012 floating point operations per second) of processing power. Several researcher have speculated on achieving this performance. The technical problems of a practical design are shown to be formidable. However, none of these problems requires a technology breakthrough for their solution. The predictable advances of the next generation of technology together with a major engineering effort is all that will be required to build such a parallel machine with usable teraflop processing power.
{"title":"Problems and approaches for a Teraflop processor","authors":"A. Frey, G. Fox","doi":"10.1145/62297.62300","DOIUrl":"https://doi.org/10.1145/62297.62300","url":null,"abstract":"This paper discusses problems associated with designing a processor capable of sustaining a teraflop (1012 floating point operations per second) of processing power. Several researcher have speculated on achieving this performance. The technical problems of a practical design are shown to be formidable. However, none of these problems requires a technology breakthrough for their solution. The predictable advances of the next generation of technology together with a major engineering effort is all that will be required to build such a parallel machine with usable teraflop processing power.","PeriodicalId":299435,"journal":{"name":"Conference on Hypercube Concurrent Computers and Applications","volume":"845 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1900-01-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116828261","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 mapping problem is the problem of implementing a computational task on a target architecture in order to maximize some performance metric. For a hypercube-interconnected multiprocessor, the mapping problem arises when the topology of a task graph is different from a hypercube. It is desirable to find a mapping of tasks to processors that minimizes average path length and hence interprocessor communication. The problem of finding an optimal mapping, however, has been proven to be NP-complete. Several different approaches have been taken to discover suitable mappings for a variety of target architectures. Since the mapping problem is NP-complete, approximation algorithms are used to find good mappings instead of optimal ones. Usually, greedy and/or local search algorithms are introduced to approximate the optimal solutions. This paper presents a greedy mapping algorithm for hypercube interconnection structures, which utilizes the graph-oriented mapping strategy to map a communication graph to a hypercube. The strategy is compared to previous strategies for attacking the mapping problem. A simulation is performed to estimate both the worst-case bounds for the greedy mapping strategy and the average performance.
{"title":"A graph-oriented mapping strategy for a hypercube","authors":"Woei-kae Chen, E. Gehringer","doi":"10.1145/62297.62322","DOIUrl":"https://doi.org/10.1145/62297.62322","url":null,"abstract":"The mapping problem is the problem of implementing a computational task on a target architecture in order to maximize some performance metric. For a hypercube-interconnected multiprocessor, the mapping problem arises when the topology of a task graph is different from a hypercube. It is desirable to find a mapping of tasks to processors that minimizes average path length and hence interprocessor communication. The problem of finding an optimal mapping, however, has been proven to be NP-complete. Several different approaches have been taken to discover suitable mappings for a variety of target architectures. Since the mapping problem is NP-complete, approximation algorithms are used to find good mappings instead of optimal ones. Usually, greedy and/or local search algorithms are introduced to approximate the optimal solutions. This paper presents a greedy mapping algorithm for hypercube interconnection structures, which utilizes the graph-oriented mapping strategy to map a communication graph to a hypercube. The strategy is compared to previous strategies for attacking the mapping problem. A simulation is performed to estimate both the worst-case bounds for the greedy mapping strategy and the average performance.","PeriodicalId":299435,"journal":{"name":"Conference on Hypercube Concurrent Computers and Applications","volume":"12 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1900-01-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129013056","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 I/O facility for FORTRAN programmers is defined for use with the Crystalline Operating system and the CUBIX I/O library. All of the external I/O switches and file types of the F77 standard FORTRAN are supported from within the nodes of a Hypercube. This is expected to both ease the development of FORTRAN applications and to greatly facilitate the conversion of existing sequential programs into concurrent versions. The implementation is portable to most machines that have both a C and FORTRAN compiler. The FORTRAN compiler is not required to have the ability to parse I/O statements. The only nonportable components of this package are, the interface codes to bridge between C and FORTRAN, and the implementation of your favorite FORTRAN extensions.
{"title":"Fortran cubix: definition and implementation","authors":"I. Angus","doi":"10.1145/62297.62398","DOIUrl":"https://doi.org/10.1145/62297.62398","url":null,"abstract":"An I/O facility for <italic>FORTRAN</italic> programmers is defined for use with the Crystalline Operating system and the <italic>CUBIX</italic> I/O library. All of the external I/O switches and file types of the <italic>F77</italic> standard <italic>FORTRAN</italic> are supported from within the nodes of a Hypercube. This is expected to both ease the development of <italic>FORTRAN</italic> applications and to greatly facilitate the conversion of existing sequential programs into concurrent versions.\u0000The implementation is portable to most machines that have both a <italic>C</italic> and <italic>FORTRAN</italic> compiler. The <italic>FORTRAN</italic> compiler is not required to have the ability to parse I/O statements. The only nonportable components of this package are, the interface codes to bridge between <italic>C</italic> and <italic>FORTRAN</italic>, and the implementation of your favorite <italic>FORTRAN</italic> extensions.","PeriodicalId":299435,"journal":{"name":"Conference on Hypercube Concurrent Computers and Applications","volume":"37 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1900-01-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129253530","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}
Traditional hypercube programming has three main characteristics. Most is done in a compiled language, FORTRAN or C, directly for the hypercube architecture and usually, one particular hypercube operating system. Secondly, algorithms have had very symmetrical decompositions; each node does essentially the same thing as other nodes. Similarly, data decomposition has normally been very regular, To an extent, these characteristics are very understandable. The people coding for the hypercube have been programmers writing code to solve problems suited to their particular hypercube as quickly as possible. The hypercube architecture is obviously well-suited to regular problems. The hypercube is reaching a stage of maturity, however, at which it’s appropriate to consider alternatives to these methods. In particular, compiled languages such as FORTRAN and C offer little to the casual user in the way of a convenient development environment or real-time feedback. Moreover, individual users must either build up and maintain a software library or recode commonly-used routines as they develop applications. The user must be familiar with the operating system interface to the hypercube, be willing to change code if the program needs to be ported, and be willing and able to convert the code into a parallel implementation.
{"title":"A dataflow-based APL for the hypercube","authors":"A. Mazer","doi":"10.1145/62297.62357","DOIUrl":"https://doi.org/10.1145/62297.62357","url":null,"abstract":"Traditional hypercube programming has three main characteristics. Most is done in a compiled language, FORTRAN or C, directly for the hypercube architecture and usually, one particular hypercube operating system. Secondly, algorithms have had very symmetrical decompositions; each node does essentially the same thing as other nodes. Similarly, data decomposition has normally been very regular, To an extent, these characteristics are very understandable. The people coding for the hypercube have been programmers writing code to solve problems suited to their particular hypercube as quickly as possible. The hypercube architecture is obviously well-suited to regular problems. The hypercube is reaching a stage of maturity, however, at which it’s appropriate to consider alternatives to these methods. In particular, compiled languages such as FORTRAN and C offer little to the casual user in the way of a convenient development environment or real-time feedback. Moreover, individual users must either build up and maintain a software library or recode commonly-used routines as they develop applications. The user must be familiar with the operating system interface to the hypercube, be willing to change code if the program needs to be ported, and be willing and able to convert the code into a parallel implementation.","PeriodicalId":299435,"journal":{"name":"Conference on Hypercube Concurrent Computers and Applications","volume":"21 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1900-01-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130080290","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 problem of placing the individual processes of a logically partitioned problem on the nodes of a multiprocessor in such a manner as to minimize the communication and memory utilization costs is known as the process placement problem. This problem is, in general, NP-complete. A number of algorithms for finding approximate solutions to the process placement problem have been investigated. Some of these algorithms rely on heuristics to initially place the processes. This approach is sometimes followed by iterative refinement, where pairs of processes are swapped in a search for better approximations. For other algorithms which rely almost solely on iterative refinement, initial placement is of much less importance. Recently simulated annealing, a more sophisticated adaptive search technique, has been applied to the process placement problem. All of these process placement algorithms are sequential. (Although simulated annealing has recently been implemented in parallel on a hypercube architecture, no work has been done in applying the parallel version to the process placement problem.) The purpose of this paper is to discuss work with a parallel algorithm for approximating solutions to the process placement problem. The algorithm has been implemented on an Intel iPSC hypercube with 16 nodes. The class of problems which were investigated involve mapping logical problem graphs to physical architectural interconnection graphs (e.g., mapping a binary tree to a hypercube or mapping a hypercube to a hypercube). The algorithm (PGA) is a parallel version of genetic algorithms, an adaptive search technique based on the principles of population genetics. Unlike the previously mentioned algorithms, PGA can be implemented on the multiprocessor system to which the actual logical problem will be mapped.
{"title":"Parallel placement of parallel processes","authors":"C. Pettey, M. Leuze","doi":"10.1145/62297.62325","DOIUrl":"https://doi.org/10.1145/62297.62325","url":null,"abstract":"The problem of placing the individual processes of a logically partitioned problem on the nodes of a multiprocessor in such a manner as to minimize the communication and memory utilization costs is known as the process placement problem. This problem is, in general, NP-complete. A number of algorithms for finding approximate solutions to the process placement problem have been investigated. Some of these algorithms rely on heuristics to initially place the processes. This approach is sometimes followed by iterative refinement, where pairs of processes are swapped in a search for better approximations. For other algorithms which rely almost solely on iterative refinement, initial placement is of much less importance. Recently simulated annealing, a more sophisticated adaptive search technique, has been applied to the process placement problem. All of these process placement algorithms are sequential. (Although simulated annealing has recently been implemented in parallel on a hypercube architecture, no work has been done in applying the parallel version to the process placement problem.)\u0000The purpose of this paper is to discuss work with a parallel algorithm for approximating solutions to the process placement problem. The algorithm has been implemented on an Intel iPSC hypercube with 16 nodes. The class of problems which were investigated involve mapping logical problem graphs to physical architectural interconnection graphs (e.g., mapping a binary tree to a hypercube or mapping a hypercube to a hypercube).\u0000The algorithm (PGA) is a parallel version of genetic algorithms, an adaptive search technique based on the principles of population genetics. Unlike the previously mentioned algorithms, PGA can be implemented on the multiprocessor system to which the actual logical problem will be mapped.","PeriodicalId":299435,"journal":{"name":"Conference on Hypercube Concurrent Computers and Applications","volume":"8 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1900-01-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"131514978","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}
Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission.
{"title":"The NCUBE family of high-performance parallel computer systems","authors":"Corporate Ncube","doi":"10.1145/62297.62415","DOIUrl":"https://doi.org/10.1145/62297.62415","url":null,"abstract":"Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission.","PeriodicalId":299435,"journal":{"name":"Conference on Hypercube Concurrent Computers and Applications","volume":"46 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1900-01-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116199970","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}
Multicomputer Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission.
{"title":"Series 2010 multicomputer","authors":"Corporate Ametek","doi":"10.1145/62297.62409","DOIUrl":"https://doi.org/10.1145/62297.62409","url":null,"abstract":"Multicomputer Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission.","PeriodicalId":299435,"journal":{"name":"Conference on Hypercube Concurrent Computers and Applications","volume":"30 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1900-01-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"122130277","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}
When we started this work, there was no C compiler available on the NCUBE. (Now there is one, from Caine, Farber, and Gordon, Inc., and it works well, but it has some restrictions on addressing, because of the underlying Intel 80286 processor, that make it unsuitable for porting certain of the UNIX utilities.) Thus we sought out a C cross-compiler, and found one from AT&T. We obtained the necessary UNIX source licenses and the sources for AT&T’s System V/iAPX286 UNIX cross-development system. That system is intended to run on a VAX running System V UNIX, but our VAX runs Ultrix, so we ported the cross-development system to Ultrix. This involved, among other things, making hybrid versions of certain UNIX utilities, hybrids with System V ancestry but adapted to run on a Berkeley UNIX file system. It was necessary to do this for lex, yacc, m4, cut, sh, and make before we were able to build the C cross-compiler and cross-linker, because, for each of these utilities, there was some small but crucial difference in behavior between the Ultrix (Berkeley UNIX) version and the System V version. Once these hybrid utilities were in place, we were able to make the cross-linker and cross-compiler
当我们开始这项工作时，NCUBE上没有可用的C编译器。(现在有一个来自Caine, Farber, and Gordon, Inc.的，它工作得很好，但是由于底层的Intel 80286处理器，它在寻址方面有一些限制，这使得它不适合移植某些UNIX实用程序。)因此，我们寻找了一个C交叉编译器，并从AT&T找到了一个。我们获得了必要的UNIX源代码许可和AT&T的System V/iAPX286 UNIX交叉开发系统的源代码。该系统旨在运行在运行system V UNIX的VAX上，但我们的VAX运行Ultrix，因此我们将交叉开发系统移植到Ultrix上。这包括制作某些UNIX实用程序的混合版本，这些工具是System V祖先的混合版本，但经过调整可以在Berkeley UNIX文件系统上运行。在我们能够构建C交叉编译器和交叉链接器之前，有必要对lex、yacc、m4、cut、sh和make执行此操作，因为对于这些实用程序中的每一个，Ultrix (Berkeley UNIX)版本和System V版本在行为上存在一些微小但至关重要的差异。一旦这些混合实用程序就位，我们就能够制作交叉链接器和交叉编译器
{"title":"A collection of NCUBE UNIX utilities","authors":"D. Tolle","doi":"10.1145/62297.62408","DOIUrl":"https://doi.org/10.1145/62297.62408","url":null,"abstract":"When we started this work, there was no C compiler available on the NCUBE. (Now there is one, from Caine, Farber, and Gordon, Inc., and it works well, but it has some restrictions on addressing, because of the underlying Intel 80286 processor, that make it unsuitable for porting certain of the UNIX utilities.) Thus we sought out a C cross-compiler, and found one from AT&T. We obtained the necessary UNIX source licenses and the sources for AT&T’s System V/iAPX286 UNIX cross-development system. That system is intended to run on a VAX running System V UNIX, but our VAX runs Ultrix, so we ported the cross-development system to Ultrix. This involved, among other things, making hybrid versions of certain UNIX utilities, hybrids with System V ancestry but adapted to run on a Berkeley UNIX file system. It was necessary to do this for lex, yacc, m4, cut, sh, and make before we were able to build the C cross-compiler and cross-linker, because, for each of these utilities, there was some small but crucial difference in behavior between the Ultrix (Berkeley UNIX) version and the System V version. Once these hybrid utilities were in place, we were able to make the cross-linker and cross-compiler","PeriodicalId":299435,"journal":{"name":"Conference on Hypercube Concurrent Computers and Applications","volume":"63 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1900-01-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"132173962","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}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：