Re: High Level Assemblers vs. High Level Language Compilers

"Randall Hyde" <rhyde@cs.ucr.edu>
24 Mar 2002 00:16:33 -0500

          From comp.compilers

Related articles
High Level Assemblers vs. High Level Language Compilers whopkins@csd.uwm.edu (2002-03-19)
Re: High Level Assemblers vs. High Level Language Compilers rhyde@cs.ucr.edu (Randall Hyde) (2002-03-21)
Re: High Level Assemblers vs. High Level Language Compilers idbaxter@semdesigns.com (Ira D. Baxter) (2002-03-22)
Re: High Level Assemblers vs. High Level Language Compilers fjh@cs.mu.OZ.AU (2002-03-22)
Re: High Level Assemblers vs. High Level Language Compilers rhyde@cs.ucr.edu (Randall Hyde) (2002-03-24)
Re: High Level Assemblers vs. High Level Language Compilers rhyde@cs.ucr.edu (Randall Hyde) (2002-03-24)
Re: High Level Assemblers vs. High Level Language Compilers kgw-news@stiscan.com (2002-03-24)
Re: High Level Assemblers vs. High Level Language Compilers whopkins@alpha2.csd.uwm.edu (2002-03-31)
Re: High Level Assemblers vs. High Level Language Compilers rhyde@cs.ucr.edu (Randall Hyde) (2002-04-06)
Re: High Level Assemblers vs. High Level Language Compilers rhyde@cs.ucr.edu (Randall Hyde) (2002-04-06)
| List of all articles for this month |

From: "Randall Hyde" <rhyde@cs.ucr.edu>
Newsgroups: comp.compilers
Date: 24 Mar 2002 00:16:33 -0500
Organization: Prodigy Internet http://www.prodigy.com
References: 02-03-120 02-03-127 02-03-154
Keywords: assembler, macros
Posted-Date: 24 Mar 2002 00:16:33 EST

Fergus Henderson wrote in message 02-03-154...


>I think part of the problem is that debugger support for C macros in
>most existing systems varies from weak to non-existent.
>
>A really good debugger would allow the "step" command to step through
>macro expansion.


I've used various compiler options (usually something like "-E" to get the
CPP output and then I compile that if I have to step through the macro.
Though you're absolutely right that debugger support would be nice.


>--
>[Seems to me that inline functions are better than macros for executable
>stuff. With inlines available, I'd only use macros for
declarations. -John]


The semantics of macros and inline procedures are different.
Sometimes inline procedures just won't do the job. A classic example
is the "RatC" macro package I wrote about four or five years ago that
expands statements like _if.._endif into the corresponding if(){..}
sequence.


Now before you barf at such syntactical nonsense, the purpose of RatC
was not simply to let me eliminate braces in C/C++ (though that's not
such a bad idea). What RatC allows is a transparent implementation of
program instrumentation. By defining a single symbol (sorta like
NDEBUG) I can turn on and off (off, as in eliminate the code, just
like ASSERT) tracing of the control statements in a program. Stuff
like that just isn't possible with inline procedures. (RatC
reference: http://webster.cs.ucr.edu/Page_ratc/ratc.html )


Cool things like true (CLU-like) iterators would be possible as well
with a really good macro processor (okay, plus a little in-line
assembly).


Randy Hyde


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.