Author Topic: Expression Evaluation  (Read 2007 times)

johnsa

  • Member
  • ****
  • Posts: 589
    • Uasm
Expression Evaluation
« on: July 05, 2012, 07:08:10 PM »
Hey all,

So based on the work i've been doing on my assembler, I have a stack based expr. evaluator which takes in tokens, does postfix conversion and evaluation.
At present it only deals with numbers and built in functions..
IE: ((10+2)*3-2)*-2+SIN(20.0)
It will promote types to decimal automatically etc.

I'm now realizing that I can do some huge refactoring in my parser and make my life easier in the long run, assuming I extend the expression evaluation to ANY type of expression..
So for example
mov eax,ebx

Would be seen by the parser as

mov expr1,expr2

Where expr1 and 2 are simply of type register.
In theory then the expression can contain all the namespace, scope, struct member, operators, <type> ptr and memory addressing components..

The reason I think this helps is the volume of code necessary to handle Namespace, Scoping, Reference, Symbols etc is huge and fiddly.. so to refactor I'd like to not have to duplicate that code per parser rule and the expression evaluation seems like a good place to have it and be able to deal with memory expressions at the same time.

Obviously for HLL conditionals I'd need a separate version that spits out ASM code instead of actually evaluating the expression, but it's internals are basically the same.

So based on this theory.. does it make sense?

I have taken the operator precedence info from MASM and extended it as follows:

;1 ( ), [ ]
;2 LENGTH, SIZE, WIDTH, MASK, LENGTHOF, SIZEOF
;3 :: (namespace resolver)
;4 . (structure-field-name or enum field operator)
;5 : (segment-override operator), PTR
;6 LROFFSET, OFFSET, SEG, THIS, TYPE
;7 HIGH, HIGHWORD, LOW, LOWWORD
;8 + ,– (unary)
;9 *, /, MOD, SHL, SHR
;10 +, – (binary)
;11 EQ, NE, LT, LE, GT, GE
;12 NOT
;13 AND
;14 OR, XOR
;15 OPATTR, SHORT, .TYPE

I would then use a struct like this to represent the outcome of an expression evaluation:

Code: [Select]
EXPTYPE_SYMBOL equ 1
EXPTYPE_CONST  equ 2
EXPTYPE_MEM    equ 3
EXPTYPE_LOGIC  equ 4
EXPTYPE_HLL    equ 5
EXPTYPE_REG    equ 6

EXPRESULT struct
expType     db ?
isEvaluated db ?
isTrue      db ?
iValue      dq ?
fValue      REAL8 0.0
segOvr      dd ?
regPtr      dd ?
symPtr      dd ?
scopePtr    dd ?
bAddr       dq ?
baseReg     dd ?
idxReg      dd ?
scale       dd ?
emitReloc   db ?
EXPRESULT ends

I want some other opinions on this.. as a sounding board and to see how the postfix conversion helps to resolve the memory addressing aspects
For examples we could have something as simple as

mov eax,dword ptr [esi]

right up to

mov eax,(dword ptr (MYSTRUCT ptr (NAMESPACE::Array[esi+eax*4+(10*2-3)]).member)