Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #196 > unrolled thread
| Started by | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| First post | 2011-07-12 06:39 +0000 |
| Last post | 2011-08-02 20:54 +0000 |
| Articles | 3 — 2 participants |
Back to article view | Back to comp.compilers
The STEP Preprocessor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-07-12 06:39 +0000
Re: The STEP Preprocessor Marco <prenom_nomus@yahoo.com> - 2011-07-16 06:59 -0700
Re: The STEP Preprocessor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-08-02 20:54 +0000
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2011-07-12 06:39 +0000 |
| Subject | The STEP Preprocessor |
| Message-ID | <11-07-020@comp.compilers> |
Many years ago I worked with the STEP Preprocessor. It was first described to me as a form of Compiler-Compiler, but it seems more like a Preprocessor-Compiler. (It runs more like an interpreter than is usual for a compiler.) In case anyone is interested, the manual is now online at: http://www.bitsavers.org/pdf/stanford/slac/The_STEP_Processor.pdf Unlike many preprocessors, the macro form can describe the exact grammar required, process appropriately or print error messages, and generate any required output. I now have the source code (in Fortran-66, and in an extended Fortran processed by STEP macros.) I hope soon to send it to the software archive of bitsavers. Not that I follow preprocessors so carefully, but I don't know of anything at all similar done since then (about 1977). -- glen
[toc] | [next] | [standalone]
| From | Marco <prenom_nomus@yahoo.com> |
|---|---|
| Date | 2011-07-16 06:59 -0700 |
| Message-ID | <11-07-025@comp.compilers> |
| In reply to | #196 |
This was a fairly popular technique back in the 1970s. The RATFOR preprocessor <http://en.wikipedia.org/wiki/Ratfor> was actually used by non-academic types. [Considering that Ratfor was written at Bell Labs, of course it was used by non-academic types. It was quite popular in the numerical analysis community. I ported it to PDP-10 Fortran. -John]
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2011-08-02 20:54 +0000 |
| Message-ID | <11-08-003@comp.compilers> |
| In reply to | #201 |
Marco <prenom_nomus@yahoo.com> wrote: > This was a fairly popular technique back in the 1970s. > The RATFOR preprocessor <http://en.wikipedia.org/wiki/Ratfor> > was actually used by non-academic types. > [Considering that Ratfor was written at Bell Labs, of course it > was used by non-academic types. It was quite popular in the > numerical analysis community. I ported it to PDP-10 Fortran. -John] STEP was written at the same place as MORTRAN, and, as I understand it, is meant to be a little higher level. (Maybe a step up, I don't know the source of the name.) MORTRAN and RATFOR are similar in being macro processors for an improvement to Fortran. Both have the limitation that bad input can generate bad output, with the error messages uncoupled to the original error. STEP allows the macro writer to restrict the allowed arguments to a macro, and generate error messages as appropriate. The example in the manual starts with a macro allowing for: ADD A TO B AND STORE INTO C; (In the days when programming was done in upper case.) If instead one wrote: ADD A TO B AND STORE INTO 38; A processor like RATFOR or MORTRAN would generate Fortran code that would generate an error from the Fortran compiler. With STEP, one can write a macro that restricts the argument appropriately, and generates an error message when appropriate. The message can accurately describe the problem in terms of the original source statements. The MORTRAN (and I believe RATFOR) processors were designed to minimize the required storage, such that large programs could be processed even on machines without a lot of memory. Doing the full parse with STEP likely does take more memory. With current machines, that is not likely to be a problem. -- glen [The people who did Ratfor did a subsequent language called EFL that was a full compiler that translated into Fortran. As was clear if you looked at the yacc source, Ratfor didn't know any Fortran, and just passed through anything it didn't know how to handle. Nonetheless, it worked pretty well, particularly if you could pass through hints to the Fortran compiler about what line numbers in the Ratfor source corresponded to what lines in the Fortran. -John]
[toc] | [prev] | [standalone]
Back to top | Article view | comp.compilers
csiph-web