Ok.. RECORD is implemented, TEXTEQU and EQU <Literal> is done. Code substitution for them and to form the basis of expanding macros is done, CRC checking and duplicate include file testing is done.
At this point I realized I can't continue without fully supporting IF/IFDEF etc as most of the test files I use define EQU's within these blocks, which breaks my parser rules of not allowing EQU redefinition.
While looking at these expressions and bearing in mind a lot of things still to come.. I think I have to completely refactor the expression system and parser.
The parser is just getting a bit out of hand being monolithic, so I want to separate it into different files and blocks:
IE: PARSER_HLL.inc, PARSER_INSTR.inc, PARSER_MISC.inc, PARSER_MACRO.inc ..
That should be fairly easy.
In addition, and this is quite a major change I want to try and make as much common logic generic and built into each parser production rule.. I already have macros that do things like:
LOOKUP_ADD_SYMBOL,PARSER_RESET, PARSER_RESTART <ptr>, NOT_VALID_IN_ENUM, NOT_VALID_IN_STRUCT etc which sit inside the various blocks to tidy up the code for handling all that common stuff, but I want to take it further with expressions.
At the moment the expression evaluator deals with simple numerical expressions and a few operators/functions like SIN,COS,TAN,ATAN, OFFSET... So it's ideal for calculation values used by variables and equs.
It handles all the different numerical types, integer/float and promotes an expression to the correct type.
Now here's my thinking.. sanity check required...:
By creating a expression result structure
and implmenting a load of other operators and logic... the one system could evaluate numerical expressions, as well as logical constructs and memory addresses?
So..
mov eax,[esi+(10+20)]
(10+20) would be handled currently... the [ ] operators would set a flag to say memory indirection.. esi would be set as the base.. any identifiers would be looked up, relocation generation flag would be set if
required.. if it found a : operator, the previous seg reg token would be set as the override...
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
Something along those lines...
So in a parse rule to deal with MOV EAX,EBX
EAX and EBX will both be assumed to be expressions, fed to this system, and the two results will be of type EXPTYPE_REG..
Does this make sense?
If anyone is interested I'd be happy to post up the full source of whats done so-far... maybe some one else is sick in the head enough like me to help out :) :)