[comp.compilers] lex/yacc question

johnl@ima.UUCP (04/24/87)

I have an assembler that uses lex & yacc, and I would like
to have it generate traditional assembler listings of the form:

    address: data	label: mnemonic instruction and operands

Now, my current technique is to gather the text in the lexical analyzer
and the address and data in the parser.  Production of the address &
data part of a listing line is driven by the parser recognizing an
instruction, while production of the text part is driven by the lexer
seeing a new-line.  The problem is that the execution of lex- and
yacc-generated code is not synchronized, so sometimes I see the text
first, then the data, while other times I see the data first and then
the text.  The problem is exacerbated when an instruction produces more
than one line of data, or multiple lines of text correspond to just one
word of data.  I have been able to deal with the problems, for the most
part, by keeping flags and counters around for special cases, but I'm
not very pleased with the result.

So here's the question.  Is there some arcanery in lex & yacc (of which
I am ignorant) that would make this easier?  I would appreciate advice
from anyone who has been in a similar boat.

					Thanks.
					Guy Hillyer

					guy%ksr.uucp@harvard.harvard.edu
[The few times I had to write an assembler, I finessed the problem by not
making source listings, just symbol tables.  But I thought about it some and
didn't come up with anything very clever.  I'd buffer up a source line and
set a flag when I saw a line feed.  Then, as I emit object code, I'd append
the source line to the next listing line I put out and clear the flag so
that subsequent listing lines didn't repeat the same source line.  If I
started to read another source line before dumping the current one, most
likely because it's a comment, I'd put out the saved source line then.  Not
too elegant, but probably effective.  Neither yacc nor lex are liable to give
you much more help.  Readers are encouraged to prove me wrong.  -John]
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.ARPA
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | cca}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request

edw@ius2.cs.cmu.edu (Eddie Wyatt) (04/29/87)

In article <558@ima.UUCP>, johnl@ima writes:
>[any easy way to make a listing in an assembler written in yacc and lex?]

Try production rules of the form

%term 	LEXDEFADDRESS	LEXDEFDATA COLON

addrprod 	: 	address COLON data LEXDEFNEWLINE
			{   generate_code ($1,$3); 
			   /* write code at end of production.
			      If you want, make generate_code
			      smart so that it buffers output
			      and writes only when the buffer is
			      full. */ }
		;

address		:	LEXDEFADDRESS
			{ $$ = make_address(); 
			  /* read the chars from yytext[]
			     and convert them into an address */ }
		;

data		:	LEXDEFDATA
			{ $$ = make_data();
			  /* read the chars from yytest[]
			     and convert them into data */ }
		;

I assume that your production is of the form:

addrprod	: 	LEXDEFADDRESS COLON LEXDEFDATA


in which case, any semantic rules will not be executed until
the lex symbol LEXDEFDATA is identified hence the chars that make
up the lex symbol LEXDEFADDRESS are lost to the parser (I know you've
hacked it so the lex code takes care of it, yuk).

General comment, lex and yacc are probably too powerful for writing
an assembler.  You will pay for all the generality of lex and
yacc in how fast your assembler runs.
	Eddie Wyatt, edw@ius2.cs.cmu.edu
[Lex might slow you down, but I have never, ever, seen a compiler where
hand-coding the parser rather than using yacc would make the compiler
noticably faster.  Yacc parses pretty fast, and parsing isn't that big a
part of compile time anway.  -John]
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.ARPA
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | cca}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request