del@fnx.UUCP (Dag Erik Lindberg) (01/28/91)
I have an application that is just screaming for something like a
macro-processor. The C pre-processor is no good because the files
I need to deal with are Motorola assembly sources which use '#'
to signify a constant value as opposed to a memory reference.
The M4 macro processor sounds like it might work, and is available
on both the ISC and SCO systems I have access to, but the manuals
only seem to include information on how to run the program, and the
pre-defined macros. There is nothing on how to write macros for the
thing.
Any pointers?
--
del AKA Erik Lindberg uunet!pilchuck!fnx!del
Who is John Galt?rbj@uunet.UU.NET (Root Boy Jim) (02/01/91)
In article <873@fnx.UUCP> del@fnx.UUCP (Dag Erik Lindberg) writes:
?I have an application that is just screaming for something like a
?macro-processor. The C pre-processor is no good because the files
?I need to deal with are Motorola assembly sources which use '#'
?to signify a constant value as opposed to a memory reference.
cpp only cares about # if it's the first nonwhite char on a line.
--
Root Boy Jim Cottrell <rbj@uunet.uu.net>
Close the gap of the dark year in betweenjones@acsu.buffalo.edu (terry a jones) (02/01/91)
In article <873@fnx.UUCP> del@fnx.UUCP (Dag Erik Lindberg) writes: > >The M4 macro processor sounds like it might work, and is available >on both the ISC and SCO systems I have access to, but the manuals >only seem to include information on how to run the program, and the >pre-defined macros. There is nothing on how to write macros for the >thing. > >Any pointers? You want to check on prep.ai.mit.edu. I think the GNU people have a version of the M4 macro processor. Check for it there. It may do what you want and the docs should also be included. -- Terry Jones {rutgers,uunet}!acsu.buffalo.edu!jones SUNY at Buffalo ECE Dept. or: rutgers!ub!jones You are in a maze of twisty little compiler features, all different.
martin@mwtech.UUCP (Martin Weitzel) (02/01/91)
In article <873@fnx.UUCP> del@fnx.UUCP (Dag Erik Lindberg) writes: >I have an application that is just screaming for something like a >macro-processor. The C pre-processor is no good because the files >I need to deal with are Motorola assembly sources which use '#' >to signify a constant value as opposed to a memory reference. The C-Preprocessor is a C-Preprocessor is a C-Preprocessor .... and NOT a general macro processor. I support your view so far. >The M4 macro processor sounds like it might work, and is available >on both the ISC and SCO systems I have access to, but the manuals >only seem to include information on how to run the program, and the >pre-defined macros. Try to get your hands on Part 1 of the good ol' UPM (UNIX Programmers Manual - I hope I remember this right and it wasn't Part 2). You'll find numereous nice tutorials on some of the more complex tools, not only (but of course also) for M4. ifelse(sidenotes,`yes',` It's a pitty that later software companies who did the various UNIX ports didn't understand the organization of the two parts of the UPM, especially that these two parts build a unit: The "reference entries" were arbitrarily split off and much background information vanished with this. There is more than one case were you can prove that the man page is incomplete (i.e. some features are only described half and some parts are obviously missing). But those incomplete docs made it even into SVID and XPG3. Only some few vendors gave the tutorials a chance to survive. (I just checked this for XENIX 286, which did.) In case of doubt have a look for the "Programmers Guide" - maybe you find some of the old stuff there. ') dnl (you'll understand this one day :-)) >There is nothing on how to write macros for the >thing. > >Any pointers? Of course: (You can try the following interactively if you call M4 without arguments, but every small sections should be tried independently, i.e. I've not designed this to take care of the earlier definitions.) define(a,b) a -----> prints: b In most cases (and especially for macros) it is important that macro replacement takes place very early, i.e. if you do the following define(x,y) define(x,z) you don't re-define the macro x in the second case but rather define a macro y, since the x is replaced by y in the second define before the definition is stored. Because of that it is generally advisable to quote things you mean "literally", e.g define(`x',y) define(`x',z) which would set up two definitions of x, with the replacement text y and z, provided the latter two have not been previously be defined as macros (in the latter case their replacement would take place prior to storing the definition, but this could easily be overlooked by the fact that even if it weren't there would occur a replacement during expansion of macro x. You can also stack macro definitions with pushdef and pop them with popdef, but again be aware pushdef(x,y) popdef(x) would try to pop the definition of the macro y, not x (replacement is done early, no implicit quoting during argument scan!). As this draws no complaint you may at first think popdef (or undefine) doesn't work, but usually there are just some quotes missing. The qouting mechanism uses the (balanced) delimiters ` and ' and one level of quotes is stripped during the primary scan of the input and an additional level with every macro expansion. I warned you, it can become a little complex (sometimes you'll get knots in your brains, as we would express it in German) and I've typed this all out of my brain, which may still be a little knotted from extensively using M4 about three years ago :-) No, what I really wanted to say is: I've checked the above information quickly during writing this article, but I may remember some things wrong and have not checked thoroughly enough here. In case of doubt: Try all this by yourself with small experiments. Well, that will not be sufficient for real sophisticated work, but may be a start. Getting the quoting right can be tricky sometimes, but in general M4 is very consistent, i.e. you only need to know a few rules to work with it. If you have any questions feel free to send me mail, but don't expect a quick answer (I've no access to my system in the next two weeks). -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
clewis@ferret.ocunix.on.ca (Chris Lewis) (02/04/91)
In article <1080@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: >In article <873@fnx.UUCP> del@fnx.UUCP (Dag Erik Lindberg) writes: >>I have an application that is just screaming for something like a >>macro-processor. The C pre-processor is no good because the files >>I need to deal with are Motorola assembly sources which use '#' >>to signify a constant value as opposed to a memory reference. >The C-Preprocessor is a C-Preprocessor is a C-Preprocessor .... >and NOT a general macro processor. I support your view so far. Weeelll, I agree with the sentiment, but it shouldn't neccessarily stop people from trying new things with it. Back when U of Toronto got its first 68000 evaluation board (long before Sun et. al.) some poor soul cobbled up a 68000 assembler out of CPP. (well, actually, I believe it was used to substitute ".text" numeric constants for mnemonics and run thru the PDP 11 assembler to produce a binary, but you get what I mean). Dag may very well be able to use CPP on his assembler provided that he runs sed on it first and afterwards to change the '#' to something else and back. Sed may even be enough to do what he needs all by itself. Another source for reasonably close documentation on m4 (or, indeed source for a replacement) is in Kernighan's Software Tools book (or, Software Tools in Pascal). -- Chris Lewis, Phone: (613) 832-0541, Internet: clewis@ferret.ocunix.on.ca UUCP: uunet!mitel!cunews!latour!ecicrl!clewis Moderator of the Ferret Mailing List (ferret-request@eci386) Psroff enquiries: psroff-request@eci386, current patchlevel is *7*.
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (02/05/91)
As quoted from <120737@uunet.UU.NET> by rbj@uunet.UU.NET (Root Boy Jim): +--------------- | In article <873@fnx.UUCP> del@fnx.UUCP (Dag Erik Lindberg) writes: | ?I have an application that is just screaming for something like a | ?macro-processor. The C pre-processor is no good because the files | ?I need to deal with are Motorola assembly sources which use '#' | ?to signify a constant value as opposed to a memory reference. | | cpp only cares about # if it's the first nonwhite char on a line. +--------------- ...unless it conforms to ANSI C, in which case it considers # other than column 1 to be a token concatenation command. "m4" is documented in the Programmer's Guide (*not* the Reference, that's the manpages). ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY