Burn, Geoffrey L., Peyton Jones, Simon L., and Robson, John D. The Spineless G-Machine. In Proceedings of the ACM Conference on Lisp and Functional Programming, Snowbird (1988) 244--258.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....in the extended notation as: f = f (g,h) f (g,h) x y = g . h . indicating that f is represented as a node referencing g and h and that selfcontained code is generated for f . 8. 4 The Brisk Abstract Machine Many approaches to compiling functional languages [59] 6] 136] [15], 105] use abstract machines with imperative machine instructions to provide the operational semantics of programs; see also [14] 99] With the STG Machine [100] a different approach was taken. The STG language is a small, low level, intermediate language which is on the one hand still ....

Geoffrey Burn and Simon L. Peyton Jones. The Spineless G-machine. In Conference on Lisp and Functional Programming, 1988.

....of a program substantially, and can also improve its cache performance. We do not evaluate this opportunity here. 2.2 The STG machine The STG machine [19, 16, 17] is a model for the compilation of lazy functional languages. It is derived from the G machine [2, 14] and the Spineless G machine [5]. In the STG machine every program object is represented as a closure. The rst eld of each closure is a pointer to statically allocated entry code, above which sits an info table that contains static information relating to the object s type, notably its layout. An example is shown in Figure 1 ....

G. Burn, S. Peyton-Jones, and J. Robson. The spineless g-machine. In Conference on Lisp and Functional Programming, pages 244-58, 1988.

....of a program substantially, and can also improve its cache performance. We do not evaluate this opportunity here. 2.2 The STG machine The STG machine [18, 15, 16] is a model for the compilation of lazy functional languages. It is derived from the G machine [2, 13] and the Spineless G machine [4]. In the STG machine every program object is represented as a closure. The rst eld of each closure is a pointer to statically allocated entry code, above which sits an info table that contains static information relating to the object s type, notably its layout. An example is shown in Figure 1 ....

G. Burn, S. Peyton-Jones, and J. Robson. The spineless g-machine. In Conference on Lisp and Functional Programming, pages 244-58, 1988.

....blackholing the redex if the result of a function is certain to be a graph that contains references to all the arguments of the function. However, omitting black holes will mean that non termination due to self dependence may fail to be detected. 7. Other abstract machines The Spineless G machine (Burn, 1988) goes to some length to avoid creating spines. Without a spine, space leaks of the form considered here are not possible. The Spineless G machine uses two different sorts of application node: the SAP for those applications which are both shared and reducible, and the AP for all other applications. ....

Burn, G.L., Peyton Jones, S.L. and Robson, J.D. 1988 The Spineless G-machine. In ACM Conference on Lisp and Functional Programming, Snowbird, July , pp.244--258.

....finds some parts which can be evaluated strictly. The strict part need not be saved in the heap as a closure form. The more the strict parts are found, the more heap space can be saved. In short, strictness analysis supports avoiding the needless allocation of closures. Spineless G machine (SGM)[BPR88] shows another way to avoid the allocation of graphs. It avoids the allocation of a graph in heap when it is certain not to be shared. If a graph is not shared, there is no need to update it and it can be stored on the top of the control stack. The original G machine always writes out a graph in ....

G. L. Burn, S. L. Peyton Jones, and J. D. Robson. The spineless G-machine. In Proceedings of the 1988 ACM Conference on Lisp and Functional Programming, pages 244--258. ACM, July 1988.

....derivations, but we could generate instances of smaller functions at the various instantiation types if we needed more parallelism in certain fragments of the code. This, however, has the disadvantage of increasing the code size, an important factor. As Stoffel is based on the spineless G machine [BPR88], some of the resulting code manipulates graphs. This graph manipulation can be parallelized, as we can disambiguate these memory references. If it is obvious that memory will cause a bottleneck in these situations, we can add more memory ports or more memory units [MV91] Basic information such ....

G L Burn, S L Peyton Jones, and J D Robson. The Spineless G-Machine. In Proceedings of the 1988 ACM conference on Lisp and Functional Programming, pages 244--258, Snowbird, Utah, July 1988. ACM.

....keep all the subexpressions around, updating each to its proper value only as needed although it had to some extent been folklore since [McC60] and has been used extensively in implementations of functional languages. Examples are the Functional Abstract Machine [Car83] the G machine [Joh84, BPJR88] Clean [BvEvLP87, KSvEP91] and DACTL [Ken88, GKS89] All of these can be perceived as notations for algorithms that describe how graphs may be used to model the evaluation of the implemented language. Such notations have the advantage that they are directly executable. However, they are often ....

G. L. Burn, S. L. Peyton Jones, and J. D. Robson. The spineless G-machine. In 1988 ACM Conference on LISP and Functional Programming, pp. 244--258, Snowbird, Utah, July 1988, ACM.

....linked list of stack frames. In the parallel case, we have many points of reduction. For further details of the abstract machine, see [AJ89a] FR FR EVAL.c . FR FR c . Figure 1: Calling EVAL to reduce a frame node. To be fair, the stack model has some advantages too. The spineless G machine [BRJ88], which offers a more general and efficient tail call mechanism than the standard G machine in particular when dealing with higher order functions, requires essentially an arbitrarily big stack. Lester [Les89] has devised an analysis technique based on abstract interpretation, to determine the ....

G. Burn, J. Robson, and S. Peyton Jones. The Spineless G-machine. In Proceedings of the 1988 ACM Symposium on Lisp and Functional Programming, Snowbird, Utah, 1988.

....There are many compiled supercombinator implementations based on different abstract machines that perform supercombinator graph reduction. The model used in the prototype implementation is based on the Spineless Tagless G Machine [Peyton Jones Salkild 89] a successor to the Spineless G Machine [Burn et al. 88] and the original G Machine [Johnsson 84] The Spineless Tagless G Machine, or STG Machine, uses a closure based model of graph reduction, which means that each node of the graph is represented by a closure in the heap. A closure consists of a code pointer and a (possibly empty) set of ....

G.L. Burn, S.L. Peyton Jones, and J.D. Robson. The spineless G-machine. In [ACM 88], pages 244--58. 207

....abstract machine for our experiments; it extends it because we consider a more complicated computational model. This paper reports on our initial work on assessing how the evaluation transformer model of reduction [Bur87, Bur91] affects the performance of programs run on the Spineless Gmachine [BPR88]. The key idea of the evaluation transformer reduction model is that the amount of evaluation needed of an argument to a function depends on the amount of evaluation required of the application of that function. This model is described further in Section 2.1. Questions and comments on the paper ....

G.L. Burn, S.L. Peyton Jones, and J.D. Robson. The spineless G-machine. In Proceedings of the 1988 ACM Symposium on Lisp and Functional Programming, pages 244--258, Snowbird, Utah, 25--27 July 1988.

....process to evaluate it, whilst a sequential implementation gains its speed by evaluating an expression without creating a closure for it. We will demonstrate compiling the projection transformer into code by giving compilation rules for a parallel G machine based on the Spineless G machine [8]. Whilst more efficient code can be generated (see [21, 2] for example) it is easy to show how to introduce the projection transformer information into code for the Spineless G machine. Three compilation functions will be considered: ffl R: Used to compile the bodies of function definitions. ....

G.L. Burn, S.L. Peyton Jones, and J.D. Robson. The spineless G-machine. In Proceedings of the 1988 ACM Symposium on Lisp and Functional Programming, pages 244--258, Snowbird, Utah, 25-- 27 July 1988.

....transformer model of reduction for both shared and distributed memory architectures. To make the work more accessible, we have described the compilation of lazy functional languages to abstract machines based on a variant of the G machine [Joh83, Aug87a, Joh87] called the Spineless G machine [BPR88] The key features of the implementations are: ffl They support the evaluation transformer model of reduction. ffl An independent parallel process is created to evaluate an argument to a user defined function when it is known that the expression must eventually be evaluated. No coordination is ....

....in terms of a parallel abstract machine. Not only does this provide a suitable level of abstraction, but it makes the presentation more accessible to those familiar with the more traditional abstract machine based implementations. Our development will be based on the Spineless G machine [BPR88] The key observation that distinguishes this machine from its predecessor, the G machine of Augustsson and Johnsson [Aug87a, Joh83, Joh87] is that graph representing an expression can only become shared in the special circumstance that the expression is named, for example by becoming bound to a ....

[Article contains additional citation context not shown here]

G.L. Burn, S.L. Peyton Jones, and J.D. Robson. The spineless G-machine. In Proceedings of the 1988 ACM Symposium on Lisp and Functional Programming, pages 244--258, Snowbird, Utah, 25--27 July 1988.

No context found.

Burn, Geoffrey L., Peyton Jones, Simon L., and Robson, John D. The Spineless G-Machine. In Proceedings of the ACM Conference on Lisp and Functional Programming, Snowbird (1988) 244--258.

No context found.

G. Burn, S. Peyton-Jones, and J. Robson. The spineless g-machine. In Conference on Lisp and Functional Programming, pages 244--58, 1988.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC