[author : W. M. McKeeman] #Method #Algorithm #Listing #Programming #Book

Extract : «  The problem of writing a programming language translator consists of setting the design objective, selecting the techniques to be used, assembling the tools, carrying out the implementation, and finally “proving” the result. Properly done, the result is an understandable program that can be easily changed, is relatively machine independent, and is free of features annoying to its eventual users. In practice this is a big, but achievable order.

In the following pages the reader will find illustrations of various principles, techniques and tools useful to the translator writer. The presentation is tutorial, suppressing some important details in the cause of brevity. Further information, including a comprehensive list of references, can be found in Gries [71] and McClure [72].

Some important attributes of a translator are listed in Table 1.1. Much of the initial planning of an implementation is concerned with choosing among them. The contents of the table are too much to assimilate all at once, thus the initial sections of this paper present two translators, illustrating two recognition algorithms and a simple code generation scheme. The paper then proceeds to elaborate upon the theme, working up to an organization subsuming most practical translators. [...]

REFERENCES

Allen, Frances E., "A Basis for Program Optimization,” Computer Software, IFIP (1971), page 64.

Cocke, J. and Schwartz J.T., "Programming Languages and their Compilers (preliminary notes)", Courant Institute of Mathematical Sciences, N.Y.U., N.Y. (April 1970).

DeRemer, F.L., Practical Translators for LR(k) Languages, Ph.D. dissertation, M.I.T. (September 1969).

Dijkstra, E.W., Notes on Structured Programming, Report 241, Technische, Hogeschool Eindhoven (1969).

Gries, D., Compiler Construction for Digital Computers, John Wiley & Sons (1971).

Lehman, M. & Belady, L., "Programming System Dynamics..." IBM Research RC3546 (September 17, 1971).

McClure, R.M., "An Appraisal of Compiler Technology," Proc. SJCC (1972) page 1-9.

McKeeman, W.M., Horning, JJ. & Wortman, D.B., A Compiler Generator, Prentice Hall (1970).

McKeeman, W.M., "Peephole Optimization," Comm. ACM 8, 7 page 443 (July 1965).

Parnas, D.L., "Information Distribution Aspects of Design Methodology," Computer Software, IFIP (1971) page 26.

Rohl, J.S., "A Note on Backus-Naur Form," Computer Journal, Vol. 10, pages 336-337 (1967-68)  »

[author : Ken Anderson] #Listing #Assembly #Graphics

Extract : «  Enclosed is a program listing of ‘Yet Another Body’ for Lichen Wang’s Tiny Robot Language. In this body, the VDM/Sol display is shared to map robot movement during the ‘Body Mode’ as well as display mind contents during the ‘Mind Mode’. Please note that a graphics density of 128 x 48 cells is accomplished on the VDM/Sol display by addition of a ‘GraphicAdd’ piggyback board. This program is easily converted for Poly/SSM type displays by modification of the cell mask table (see listing). [...]  »

[author : John James] #Forth #HowItWorks #Listing #Programming #Book

Extract : «  Forth is a unique threaded language ideally suited for microcomputers. Programs are incredibly compact; e.g. in 5K to 6K bytes you can get the interactive Forth compiler, running stand-alone as its own operating system including I/O drivers and other run-time routines, plus an assembler written in Forth (in case you want to optimize time-critical programs), virtual memory software, and a text editor. Not only does all this fit into 5K to 6K bytes (of which 4K are written in Forth), but it runs in the same space (plus 1K buffer), with no additional symbol table area, overlays, swapping, or use of any other software.

And while Forth gives all the convenience of interactive interpreters, it is very fast. For most applications, the runtime overhead is 20 to 30% for minis and 70 to 100% for micros (compared to 1000% or more which is common for interpreters). Number-crunching applications may take longer. And when Forth isn’t fast enough, the system’s own assembler can be used to re-code inner loops.

But the best news of all is that software development times are cut by half or more over assembly programming. The programming is entirely structured (there is no GOTO), and the resulting code is re-entrant and can be designed for PROM.

Forth has been implemented on many microcomputers. A recommended configuration is 16K bytes and a terminal; a floppy is a good idea for storing source programs (and virtual memory for programs and data is supported). Forth works well with a CRT, so hard copy is less necessary.

Forth has existed for several years, and is used commercially in a number of installations, but until recently it has been priced far out of reach of hobbyists, and even most computer experts have never heard of it. However, the language is in the public domain, and today low-cost versions are just becoming available. Also there is a new Forth Interest Group (787 Old County Rd, San Carlos, CA 94070), dedicated to letting the serious hobbyist and the professional know about Forth and how they can get it.

[...]

Forth was developed by Charles H. Moore around 1970, at the National Radio Astronomy Observatory, and to our knowledge was first described in publication in 1973.

[...]

1. Moore, C.H., and E.D. Rather, "The FORTH program for spectral line observing," Proc. IEEE, vol. 61, September, 1973, pp. 1346- 1349.

2. —, "FORTH: A new way to program a minicomputer," Astron. Astrophys. Suppl. 15 1974, pp. 497-511.

3. DECUS, Forth Programming System for the PDP-11 , DECUS No. 11-232, September 1975. (Note also manual for the PDP-10.)

4. Stein, P., "The FORTH dimension: Mini language has many faces," Computer Decisions, November, 1975, pp. 10.

5. Rather, E.D., and C.H. Moore, "FORTH high-level programming technique on microprocessors." Presented at Electro/76 Professional Program (paper 23/4), Boston, MA, 11-14 May 1976.

6. Sinclair, W.S., "Forth: A Stack Oriented Language," Interface Age, September 1976.

7. —, "The FORTH approach to operating systems," A CM '76 Proc., pp. 233-240, October 1976.

8. Forth, Inc., Microforth Primer, December 1976.

9. —, "The use of 'FORTH' in process control." Presented at International '77 Mini-Micro Computer Conference, Geneva, 26 May 1977  »

[author : Terry Ritter] #Listing #Assembly #Diagnostic #Memory

Extract : «  A memory test package can be a very useful utility for a microcomputer system. Not only can it provide periodic checks of memory functionality, but it can also give day-to-day checks of the system after re-configuration. Getting a moderately-complex program to actually execute says a great deal about the correctness of the entire computer. Testing the area which is supposedly RAM isolates address-decode and board-contact problems which could otherwise inhibit operations. A small and fast memory test package can confirm the correctness of a dynamically-changing system to a high degree of probability. [...]  »

[author : H.T. Gordon] #Listing #Assembly #Programming

Extract : «  I am herewith submitting an extensive recoding and enhancement of the editor section of Dan Fylstra’s SWEETS program for the KIM-1, published in (and copyrighted by) BYTE. It poses several dilemmas of general interest. First, the problem of program names. SWEETS is Fylstra’s acronym for 2 main programs, that share some subroutines. The entry label for the editor (the only one I have worked on) is CMD. I have given the more descriptive name EDITHA to my revision, on the grounds that its coding is mostly quite different and that it includes some major innovations (address information and modification capability, greater error-protection, and a richer command structure with modes not found in CMD). [...]

The second dilemma is the perennial one of software ownership. I assert copyright (qualified by a special non-monopolistic free-diffusion clause) for all components of EDITHA not either previously in the public domain or copyrighted by someone else. Exactly what these are is a moot question. Very little of the original CMD coding is left intact in EDITHA. [...]

The third dilemma is: where should revision of a program published in BYTE be published? First, let me say that I consider BYTE a valuable journal. I have had a note (on 6502 opcodes) published in it, and a second one (on a pseudorandom number generator, 8080-coded) is accepted and will (eventually!) get published. There are some advantages (a small remuneration, glossy paper, and a very large readership) and some disadvantages (among them are: loss of all rights to your work, and often long publication delay, and no indication of the date of receipt of articles). On the whole, my relationship with DDJ has been a more humanly satisfying one. [...]  »

[author : George Morrow and Howard Fullmer] #Interface #Standard

Extract : «  The following is a preliminary specification for the computer bus commonly known as the S-100 Bus. This bus was first introduced by MITS Inc. with their Altair kit. It has since spread throughout the electronics industry and beyond. Today over a hundred manufacturers make products which claim to be compatible with the S-100 bus even though, until now, no complete specification has been available.

This document is a specification for both timing and signal discipline. Signal discipline is described using the Bus Master/Bus Slave language long associated with Digital Equipment’s PDP 11. This point of view facilitated the development of a simple and highly realizable DMA protocol, the extended addressing capabilities, and the 16 bit wide data path proposals. These extensions to the original Altair bus represent a significant advance in the state of the art of small computers. These advances are a direct result of a continuing dialogue with a large number of interested people who have contributed their thoughts and ideas to the standards committee. [...]  »