Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!oliveb!pyramid!batcomputer!andy From: andy@batcomputer.UUCP Newsgroups: comp.unix.questions Subject: Re: Teaching Assembler (now m4/cpp) Message-ID: <1072@batcomputer.tn.cornell.edu> Date: Wed, 20-May-87 09:45:43 EDT Article-I.D.: batcompu.1072 Posted: Wed May 20 09:45:43 1987 Date-Received: Sat, 23-May-87 01:29:18 EDT References: <7447@brl-adm.ARPA> Reply-To: andy@tcgould.tn.cornell.edu.UUCP (Andy Pfiffer) Organization: Cornell Theory Center, Cornell University, Ithaca NY Lines: 32 In article <7447@brl-adm.ARPA> chris@mimsy.umd.EDU (Chris Torek) writes: >m4 is just about maximally untailored. >... >...All I want from an assembler is that it assemble, quickly, and that it >tell me where something is wrong. There is so little to go wrong >that it does not matter *what*: just *where*. Absolutely. While I did pay my dues with a PDP-11 macro assembler under RT-11, I've found m4/cpp to be more than enough to get the job done. The project that I am currently involved in is based upon the INMOS transputer (T414 to be exact). Our board-level monitor is a classicly implemented threaded interpreter (forth-like for the uninformed) written entirely in native T4 assembler. After a weekend of playing with m4, I put together an m4 macro package that does some gee-whiz things at assemble time. By default, our assembler front end runs the source through any specified macro files (*.m4), then through cpp, and then finally assembles it. I could have gotten by, I think, with just cpp if our assembler understood semicolon separated statements. I suppose that I shouldn't tell you that the current version of the assembler backend (linker, symbolic address binder, etc.) are *all* written in awk and m4... -- Andy Pfiffer andy@tcgould.tn.cornell.edu Cornell Theory Center / Cornell U. cornell!batcomputer!andy Home of the first usable T-Series (607) 255-8686 "...that's the way a Transputer works, right?" Systems Group