Concurrent Control Abstraction Language, CCAL, is an interpreted language which provides no particular control regime to the user. CCAL instead supports five primitive operations which manipulate an abstract model of inter-procedural control. This model is intrinsically concurrent, and the user is allowed to construct high-level concurrent control operations from the primitives (hence, control abstraction). The primary use of CCAL is as a vehicle by which rapid prototyping of application specific control forms may be done and as a tool for the construction and evaluation of novel control forms, especially control forms for highly concurrent and distributed systems. The CCAL interpreter is implemented as a distributed program on a network of Vaxen and Sun-3 workstations under 4.2bsd and 4.3bsd Unix1. CCAL programs appear as multi-process programs in a shared memory system. Both true and apparent concurrency are possible. This paper describes the control abstraction facilities offered by the CCAL interpreter, its use, and implementation strategies in the distributed environment.
{"title":"CCAL: an interpreted language for experimentation in concurrent control","authors":"P. Kearns, C. Cipriani, Mitzi Freeman","doi":"10.1145/29650.29680","DOIUrl":"https://doi.org/10.1145/29650.29680","url":null,"abstract":"Concurrent Control Abstraction Language, CCAL, is an interpreted language which provides no particular control regime to the user. CCAL instead supports five primitive operations which manipulate an abstract model of inter-procedural control. This model is intrinsically concurrent, and the user is allowed to construct high-level concurrent control operations from the primitives (hence, control abstraction). The primary use of CCAL is as a vehicle by which rapid prototyping of application specific control forms may be done and as a tool for the construction and evaluation of novel control forms, especially control forms for highly concurrent and distributed systems. The CCAL interpreter is implemented as a distributed program on a network of Vaxen and Sun-3 workstations under 4.2bsd and 4.3bsd Unix1. CCAL programs appear as multi-process programs in a shared memory system. Both true and apparent concurrency are possible. This paper describes the control abstraction facilities offered by the CCAL interpreter, its use, and implementation strategies in the distributed environment.","PeriodicalId":414056,"journal":{"name":"SIGPLAN Conferences and Workshops","volume":"25 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1987-07-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123319318","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 ability to extend programs dynamically has clear advantages. However, providing efficient yet sufficiently flexible support for such capabilities system-wide presents significant challenges. We describe a design and implementation of an extension mechanism that depends heavily on interpretive techniques, including call arbitration, dynamic linking, and multilanguage extensions. We discuss these mechanisms in the context of our Extension Interpreter, which embodies our ideas and provides a framework for discussing the efficiency and generality of the implementation. Our current implementation runs under BSD UNIX 4.2 and 4.3 on VAXes and SUN workstations. Extensions can be written in both C and in Icon, demonstrating our ability to address problems both of compiled and interpreted languages.
{"title":"Enhancement through extension: the extension interpreter","authors":"D. Notkin, W. Griswold","doi":"10.1145/29650.29655","DOIUrl":"https://doi.org/10.1145/29650.29655","url":null,"abstract":"The ability to extend programs dynamically has clear advantages. However, providing efficient yet sufficiently flexible support for such capabilities system-wide presents significant challenges. We describe a design and implementation of an extension mechanism that depends heavily on interpretive techniques, including call arbitration, dynamic linking, and multilanguage extensions. We discuss these mechanisms in the context of our Extension Interpreter, which embodies our ideas and provides a framework for discussing the efficiency and generality of the implementation. Our current implementation runs under BSD UNIX 4.2 and 4.3 on VAXes and SUN workstations. Extensions can be written in both C and in Icon, demonstrating our ability to address problems both of compiled and interpreted languages.","PeriodicalId":414056,"journal":{"name":"SIGPLAN Conferences and Workshops","volume":"33 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1987-07-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"134456250","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}
There are two basic approachs to the problem of storage reclamation, process- and processor-based, named for the view point used to recognize when a particular piece of storage can be reclaimed. Examples of the processor approach include mark/sweep and copying algorithms and their variants, while reference counting schemes use a process view of the collection. It is argued that the process approach is better suited for distributed computation where links between dynamically allocated objects may cross processor boundaries. In addition, the process approach allows the heap to be more conveniently shared with other processes in those cases when different processes might not have their own virtual address spaces. A new algorithm using the process approach is given. Its space requirement per object is better than that for reference counting. In addition, a restricted form of pointer replacement is supported which allows circular structures so constructed to be properly collected.
{"title":"Distributed garbage collection","authors":"J. D. Eckart, R. LeBlanc","doi":"10.1145/29650.29678","DOIUrl":"https://doi.org/10.1145/29650.29678","url":null,"abstract":"There are two basic approachs to the problem of storage reclamation, process- and processor-based, named for the view point used to recognize when a particular piece of storage can be reclaimed. Examples of the processor approach include mark/sweep and copying algorithms and their variants, while reference counting schemes use a process view of the collection. It is argued that the process approach is better suited for distributed computation where links between dynamically allocated objects may cross processor boundaries. In addition, the process approach allows the heap to be more conveniently shared with other processes in those cases when different processes might not have their own virtual address spaces. A new algorithm using the process approach is given. Its space requirement per object is better than that for reference counting. In addition, a restricted form of pointer replacement is supported which allows circular structures so constructed to be properly collected.","PeriodicalId":414056,"journal":{"name":"SIGPLAN Conferences and Workshops","volume":"41 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1987-07-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133381039","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}
A two-level programming model permits the applications programmer to write programs that benefit both from the code density of interpreted virtual machines and from the speed of native code execution. A well-defined boundary between the native code and the virtual machine facilitates the development of translators to be used at both levels.
{"title":"Two-level hybrid interpreter/native code execution for combined space-time program efficiency","authors":"T. Pittman","doi":"10.1145/29650.29666","DOIUrl":"https://doi.org/10.1145/29650.29666","url":null,"abstract":"A two-level programming model permits the applications programmer to write programs that benefit both from the code density of interpreted virtual machines and from the speed of native code execution. A well-defined boundary between the native code and the virtual machine facilitates the development of translators to be used at both levels.","PeriodicalId":414056,"journal":{"name":"SIGPLAN Conferences and Workshops","volume":"309 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1987-07-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124287427","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 Illinois Functional Programming (IFP) language is a modified version of Backus' FP(1). IFP has the same side-effect free combinator style of Backus FP, while introducing an ALGOL-like syntax and structure. While IFP superficially appears to be an inefficient language to execute, its simplicity makes it quick to interpret. Functions are always monadic and there are no variable or parameter names. Furthermore, combinator-style languages allow common housekeeping operations to be condensed into efficient machine-language primitives.By reference-counting, the interpreter can often convert call-by-value to destructive call-by-reference while preserving referential transparency. The interpreter has an expression cache which can improve the asymptotic time of some combinatorial functions. IFP function definitions are stored as UNIX files, so much of UNIX's functionality is immediately borrowed into the IFP environment, e.g. ls, more, and grep.Benchmarks indicate that IFP is an order of magnitude faster than Berkeley FP[2], and is competitive with interpreted von-Neumann languages such as BASIC. The interpreter can parallel process on shared-memory multiprocessors, e.g. the Encore Multimax. IFP currently runs on machines as varied as the IBM PC, VAX, and CRAY-XMP.
{"title":"The Illinois functional programming interpreter","authors":"A. Robison","doi":"10.1145/29650.29657","DOIUrl":"https://doi.org/10.1145/29650.29657","url":null,"abstract":"The Illinois Functional Programming (IFP) language is a modified version of Backus' FP(1). IFP has the same side-effect free combinator style of Backus FP, while introducing an ALGOL-like syntax and structure. While IFP superficially appears to be an inefficient language to execute, its simplicity makes it quick to interpret. Functions are always monadic and there are no variable or parameter names. Furthermore, combinator-style languages allow common housekeeping operations to be condensed into efficient machine-language primitives.By reference-counting, the interpreter can often convert call-by-value to destructive call-by-reference while preserving referential transparency. The interpreter has an expression cache which can improve the asymptotic time of some combinatorial functions. IFP function definitions are stored as UNIX files, so much of UNIX's functionality is immediately borrowed into the IFP environment, e.g. ls, more, and grep.Benchmarks indicate that IFP is an order of magnitude faster than Berkeley FP[2], and is competitive with interpreted von-Neumann languages such as BASIC. The interpreter can parallel process on shared-memory multiprocessors, e.g. the Encore Multimax. IFP currently runs on machines as varied as the IBM PC, VAX, and CRAY-XMP.","PeriodicalId":414056,"journal":{"name":"SIGPLAN Conferences and Workshops","volume":"109 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1987-07-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116107248","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}
Software simulation of one computer on another tends to be slow. Traditional simulators typically execute about 100 instructions on the host machine per instruction simulated. Newer simulators reduce the expansion factor to about 10, by saving and reusing translations of individual instructions. This paper describes an experimental simulator which takes the progression one step further, translating groups of instructions as a unit. This approach, combined with flow analysis, reduces the expansion factor to about 4. The new simulator simulates System/370 on a RISC, namely the IBM RT PC.
{"title":"Mimic: a fast system/370 simulator","authors":"C. May","doi":"10.1145/29650.29651","DOIUrl":"https://doi.org/10.1145/29650.29651","url":null,"abstract":"Software simulation of one computer on another tends to be slow. Traditional simulators typically execute about 100 instructions on the host machine per instruction simulated. Newer simulators reduce the expansion factor to about 10, by saving and reusing translations of individual instructions. This paper describes an experimental simulator which takes the progression one step further, translating groups of instructions as a unit. This approach, combined with flow analysis, reduces the expansion factor to about 4. The new simulator simulates System/370 on a RISC, namely the IBM RT PC.","PeriodicalId":414056,"journal":{"name":"SIGPLAN Conferences and Workshops","volume":"73 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1987-07-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"122285250","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}
We present a system which generates interactive high-level debugging systems from formal language definitions. The language definer has to specify a denotational semantics augmented with a formal description of the language specific debugging facilities. The generated debugger offers the traditional features such as tracing programs, setting breakpoints, displaying variables etc; interaction with the user is always on language level rather than on machine level. The concept has been implemented as part of the PSG-Programming System Generator, and has successfully been used to generate debuggers for Pascal and Modula-2. The core of the implementation consists of an interpreter for a functional language, which has been extended with the language-independent mechanisms needed in order to allow interaction with the user during program execution.
{"title":"A generator for language-specific debugging systems","authors":"Rolf Bahlke, B. Moritz, G. Snelting","doi":"10.1145/29650.29660","DOIUrl":"https://doi.org/10.1145/29650.29660","url":null,"abstract":"We present a system which generates interactive high-level debugging systems from formal language definitions. The language definer has to specify a denotational semantics augmented with a formal description of the language specific debugging facilities. The generated debugger offers the traditional features such as tracing programs, setting breakpoints, displaying variables etc; interaction with the user is always on language level rather than on machine level. The concept has been implemented as part of the PSG-Programming System Generator, and has successfully been used to generate debuggers for Pascal and Modula-2. The core of the implementation consists of an interpreter for a functional language, which has been extended with the language-independent mechanisms needed in order to allow interaction with the user during program execution.","PeriodicalId":414056,"journal":{"name":"SIGPLAN Conferences and Workshops","volume":"42 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1987-07-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"134278215","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 presents a constant-time marking-collecting algorithm to efficiently implement recursion with a general heap memory rather than with a vectorial stack, in a context of frequent captures of continuations. It has been seen to reduce the 80% garbage collection overhead to less than 5% on average.The algorithm has been built into a virtual machine to efficiently implement at the assembly level the Actor language PLASMA, an Actor-oriented version of PROLOG and a variant of SCHEME, currently in use on 8086, 68000 and Vax.The rationale to use the heap memory is that continuations are available via a single pointer in a unified memory and can be shared optimally when recurrently captured, which is simply impossible using a strategy based on stack recopy. Further, non-captured continuations can be incrementally garbage collected on the fly.Part I describes the elementary recursive instructions of the virtual machine. Part II presents and proves the marking-collecting strategy. Part III safely generalizes the transformation "call + return = branch" in a way compatible with the possible capture of the current continuation. An appendix relates its integration in the Virtual Scheme Machine supporting Scheme 84.
{"title":"Memory allocation and higher-order functions","authors":"O. Danvy","doi":"10.1145/29650.29676","DOIUrl":"https://doi.org/10.1145/29650.29676","url":null,"abstract":"This paper presents a constant-time marking-collecting algorithm to efficiently implement recursion with a general heap memory rather than with a vectorial stack, in a context of frequent captures of continuations. It has been seen to reduce the 80% garbage collection overhead to less than 5% on average.The algorithm has been built into a virtual machine to efficiently implement at the assembly level the Actor language PLASMA, an Actor-oriented version of PROLOG and a variant of SCHEME, currently in use on 8086, 68000 and Vax.The rationale to use the heap memory is that continuations are available via a single pointer in a unified memory and can be shared optimally when recurrently captured, which is simply impossible using a strategy based on stack recopy. Further, non-captured continuations can be incrementally garbage collected on the fly.Part I describes the elementary recursive instructions of the virtual machine. Part II presents and proves the marking-collecting strategy. Part III safely generalizes the transformation \"call + return = branch\" in a way compatible with the possible capture of the current continuation. An appendix relates its integration in the Virtual Scheme Machine supporting Scheme 84.","PeriodicalId":414056,"journal":{"name":"SIGPLAN Conferences and Workshops","volume":"212 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1987-07-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"122658758","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 implementation of a high speed Prolog interpreter on a standard microprocessor (50 KLIPS on a 16 MHz MC68020). The interpreter is based on direct threaded code. By this method an interpreted program achieves the same speed as a compiled program, but uses only a tenth of memory. The first part of this paper describes the implementation of the interpreter. The second part compares the implementation, the runtime and the storage requirements with that of a compiler.
{"title":"Implementation of a high-speed Prolog interpreter","authors":"A. Krall","doi":"10.1145/29650.29663","DOIUrl":"https://doi.org/10.1145/29650.29663","url":null,"abstract":"This paper describes the implementation of a high speed Prolog interpreter on a standard microprocessor (50 KLIPS on a 16 MHz MC68020). The interpreter is based on direct threaded code. By this method an interpreted program achieves the same speed as a compiled program, but uses only a tenth of memory. The first part of this paper describes the implementation of the interpreter. The second part compares the implementation, the runtime and the storage requirements with that of a compiler.","PeriodicalId":414056,"journal":{"name":"SIGPLAN Conferences and Workshops","volume":"25 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1987-07-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125355388","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 benefits of programming in a functional style are well known. For example, algorithms which are expressed as compositions of functions operating on series/vectors/streams of data elements are much easier to understand and modify than equivalent algorithms expressed as loops. Unfortunately, many programmers hesitate to use series expressions because they are typically implemented very inefficiently-the prime source of inefficiency being the creation of intermediate series objects.A restricted class of series expressions, obviously synchronizable series expressions, is defined which can be evaluated very efficiently because they do not require the creation of any intermediate series objects. A Common Lisp macro package has been implemented which supports obviously synchronizable series expressions. Using this macro package, programmers can obtain the advantages of expressing computations as series expressions without incurring any runtime overhead. Obviously synchronizable series expressions could be straightforwardly supported in any programming language.
{"title":"Efficient interpretation of synchronizable series expressions","authors":"R. Waters","doi":"10.1145/29650.29658","DOIUrl":"https://doi.org/10.1145/29650.29658","url":null,"abstract":"The benefits of programming in a functional style are well known. For example, algorithms which are expressed as compositions of functions operating on series/vectors/streams of data elements are much easier to understand and modify than equivalent algorithms expressed as loops. Unfortunately, many programmers hesitate to use series expressions because they are typically implemented very inefficiently-the prime source of inefficiency being the creation of intermediate series objects.A restricted class of series expressions, obviously synchronizable series expressions, is defined which can be evaluated very efficiently because they do not require the creation of any intermediate series objects. A Common Lisp macro package has been implemented which supports obviously synchronizable series expressions. Using this macro package, programmers can obtain the advantages of expressing computations as series expressions without incurring any runtime overhead. Obviously synchronizable series expressions could be straightforwardly supported in any programming language.","PeriodicalId":414056,"journal":{"name":"SIGPLAN Conferences and Workshops","volume":"46 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1987-07-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116883388","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
扫码关注我们
求助内容：
应助结果提醒方式：