TIP: Click on subject to list as thread! ANSI
echo: cis.os9.68000.osk
to: Jack Crenshaw 72325,1327 (X)
from: Jack Crenshaw 72325,1327
date: 1990-12-26 08:33:35
subject: #8899-#68000 ASM Language

#: 8900 S12/OS9/68000 (OSK)
    26-Dec-90  08:33:35
Sb: #8899-#68000 ASM Language
Fm: Jack Crenshaw 72325,1327
To: Jack Crenshaw 72325,1327 (X)

[Continued]

Worse yet, though, is the syntax of the arguments.  Consider the two
instructions

       MOVE -(A0),D0 and    MOVE -(A06 + (4 * D05)/2)(A0,D0),D0

Both of these areperfectly valid instructions, assuming the labels A06 and D05
are defined somewhere.  But, of course, the encoding of the instructions are
completely different.  And a parser, scanning from left to right, can't tell
which kind of instruction it's dealing with until it gets to the fifth
character of the first operand.  In other words, a predictive parse is not
possible without some prefiltering by the lexical scanner.

This is the same problem as the old FORTRAN problem, often given as this
example:

       DO 10 I=1.5

which is an assignment to the variable DO10I, but the compiler doesn't know
that until it sees the '.'.   After all these years, you'd think that we
wouldn't fall into that trap again!

I finally figured out how other folks do it:  They keep a set of legal argument
strings around (things like "-(A0)", '-(A1)", etc.) and compare the whole
argument string with them, looking for the special cases. If nothing matches
the "canned arguments, then they assume it's an expression.  Even then, the
argument could be:

[More]



There is 1 Reply.

SOURCE: compuserve via textfiles.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.