JC> For instance 2+3*5 should be interpreted as 2 + (3*5) = 17 
 JC> instead of (2 + 3)*5
 
For an assembler you don't need a parse tree. Infix evaluation using
two stacks (operators/operands) is fine. You'll never encounter a place 
where you have a variable and constant--that's the only use for a parse 
tree. Parse tree generation requires a number of "levels" and an excellent 
understanding of recursion. Parse tree collapsing, although simple to 
implement, is quite a bit longer than the infix double stack method.
 JC> The parsing tree for solution 1 (the good one) is
 JC> +
 JC> /   \
 JC> 2     *
 JC> /   \
 JC> 3      5
 
I used to write parse trees like that, here's a suggestion (sorry if the 
high bit gets stripped):
+
+- *
|  +- 3
|  +- 5
+- 2
 
It just makes *so* much more sense to write a tree in a vertical (ie left
is top, right is bottom) fashion (like tree.com) rather horizontal (like 
yours); especially when you want to write a procedure to dump parse trees 
to the screen. A procedure to write the above to the screen then again can 
handle loop/statement/identifier nodes, etc.
 JC> Sorry Fernando, but these are basics you should know.
 
And I don't think they're necessary in an assembler.
                                       - DarkFire 
[John Stephenson (an INTP), Fingerprint: 66BE3A3B6EEE9A5B-48001A32901ECA21]
[Composed at 8:00:57a on 1998-04-10 (UTC) using PGPWave v1.24a Beta]
--- Maximus 2.01wb
---------------