No abstract

project problern1.introduction to the student compiler project problemThe student compiler project problem is the following: Design a general-purpose programming language suitable for implementation by a small student team in a one-semester course. The project should maximize the range of implementation skills which are learned while minimizing repetitive, tedious work.The language proposal below was designed and implemented by a team of three computer science students (Kevin Atteson, Michael Lorenz, and William Pinto) during a ten-week "compiler workshop" class. This course is preceded by a "compiler theory" course covering lexical analysis, parsing techniques and tools, and an introduction to syntax directed translation. The result is NARPL, a structured imperative programming language, whose pdmary features include:o C/Pascal-like syntax , strong typing based on name equivalence • programmer-controlled dynamic allocation • (recursive) functions with parameters passed by value or by reference ° 'extern' declarations allowing access to independently compiled modules • several novel syntactic ideas.In order make NARPL as rich as possible, it was necessary to utilize fully the tools that were available. Thus YACC was employed for parsing and organizing the translation. A subset of 68000 assembly language was chosen as the target code without producing an intermediate representation. The decision to target an assembly language for which we had a linker and assembler enabled us to link in external routines when needed and freed us from writing an ad hoc interpreter, as suggested e.g. in [ASU]. J Before describing the NARPL language, we consider several published proposals for student compiler projects. In each case, we find that NARPL presents significant pedagogical and language design advantages.[ASU] presents a Pascal "subset." This project is among the weakest we found, perhaps owing to its origins before compiler tools were in common use. This Pascal "subset" is not a subset at all --for example, all parameters are passed by reference (without the use of the keyword VAR, however). Pointers are not attempted, nor are characters nor strings. Arrays are the only structured type. The proposed treatment of I/O procedures is unclear --except that they are "assumed supplied by the compiler." There is no nesting of subprograms. We feel this project does not provide a realistic learning experience, and may be quite tedious if a quad-interpreter must be written as well as the translator.

No abstract

No abstract

No abstract