TREE-META(ID:3891/tre003)Tree grammar compilerCompiler compiler used by Henri Gouraud to implement FLEX on the SRI SDS-940 for the PDP-20 interface Used at the Atlas Computer Lab by Hopgood to create compilers in PLASYD Used by Engelbart to create the editor for the famous HCI demonstration Related languages
References: Two FLEX compilers have been programmed in ALGOL on the UNIVAC 1108 and have been running since mid-February 1968. Several partially successful attempts were made to combine the compilers with a number of the operating text editors at the University of Utah. The failures were partially due to the inadequacies of ALGOL as a real-time and process language in general, and in particular, to the very real defects of the UNIVAC version of ALGOL-60. Implementation of the interpreter has been severely delayed for several reasons – the main one being that it took longer than expected to work out a rationale for a segmenting and swapping system that would work on such a small scale. Current implementation is now taking place on an IBM 1130 partially because the machine can be dedicated most of the time to this task and partly also because it is small and does not tempt one into grandiose schemes. Implementation on a PDP-10 is also being contemplated. Future Expansion The process-oriented nature of FLEX should make it an ideal kernel for numerous discrete simulation schemes. A search for primitives in this as well as in the semantic transformation area is currently going on, and it is expected that some fruit will be available for plucking in the next month on this field of discourse. Application packages are also being studied with a view toward both allowing FLEX to do something useful and providing a test-bench on which to evaluate the system. To this end, the solid-state circuit design program developed by W.R. Sutherland on the TX-2 computer at Lincoln Laboratories is being eye-balled. FLEX and LEAP (the implementation language at Lincoln) share some properties – notably the ability to store and retrieve associations – and it will be interesting to notice the difference between the 256k words of fast memory on the TX-2 versus 4 to 8k smaller words on the FLEX machine. extensively, so the first task was to transfer the compiler- compiler Tree Meta. Source code was generated on the 940 to run on the PDP-10. Binaries were then transmitted to Utah and run and debugged. Patches were performed where possible, and source changes accumulated. A new source and binaries would then be made periodically. Once Tree Meta was running, a new high level language (called L- 10) for programming the On-Line System (NLS) was implemented in the same way. When L-10 was running the core device independent parts of NLS were rewritten and debugged. NLS was completely reorganized during the transfer. TREE-META (FRAH) The TREE-META translator writing system has been implemented on the 1906A. The current system follows closely the design of the version available on the INTERDATA computer of Queen Mary College. It uses the same storage system for strings, trees and stacks. The method of storing and accessing strings is not very efficient and it is likely that this will have to be changed to speed up the final version. A translator for a particular language L is defined in terms of two types of TREE-META statements. The first type defines the syntax of the language L and describes how trees will be built from sentences in the language at recognition time. The second type of statement describes how these trees will be scanned and manipulated to generate code equivalent to the input sentence. So far the system is defined in terms of a set of basic routines written in PLASYD. Both types of TREE-META statements are compiled into calls of these basic routines so that the system is similar to an interpreter at present. To check-out the system, a definition of TREE-META in terms of itself has been successfully input to the system. A number of delays in the production were caused by internal PLASYD tables overflowing. In particular the limit of 100 on the number of unresolved forward references has required a large amount of code rearrangement. The aim in the next quarter will be to speed up the system by redefinition so that PLASYD code is generated rather than routine calls. This is not too difficult as, although the system is large (about 6000 PLASYD statements), its definition in terms of itself is only about 150 lines. Once an efficient version is available, it will be used to experiment with preprocessor facilities for the SPROGS system. External link: Online copy |