Resource compiler for console applications

[japheth]

It's not child's play, of course, but IMHO a pretty basic exercise (sorry, can't help you with C code....):

Even a macro that consists of just EXITM may not work, since the argument behind EXITM may be another macro. So you'll probably have to add recursion in your source sample ( which I cannot read, because I'm suffering from a severe BaSiCphobia , sorry! ).

[jj2007]

... your source sample ( which I cannot read,

Strange, very strange: JWasm has no problems to read my sources :icon_mrgreen:

[nidud]

deleted

[jj2007]

Hi nidud,

AFAICS the problem is mainly relevant for two cases: elseif macro() and or'ed macros like this:
   ; Let esi="This is a stupid test"
   .Break .if Instr_(esi, "stuupid")   ; works correctly
   ; both macros get expanded at the label, but only the second one gets tested
   .Break .if Instr_(esi, "stuupid") || Instr_(esi, "stupid")

There is, of course, a simple workaround for the latter case: two .Break .if lines.
Again, a warning for the noobs would be luxury, but Japheth seems not so eager to dig into it, so I'll pull out and leave him in peace  :icon14:

[nidud]

deleted

[jj2007]

The next trick is to halt expansion of these two:
.elseif macro
.while macro

Right, I forgot the .While macro() case in my post above.

[nidud]

deleted

[nidud]

deleted

[japheth]

I forgot..
The new declaration for ParseLine:

Code Select Expand


ret_code ParseLine ( char *line, struct asm_tok tokenarray[] )

Inserted below label function:

Code Select Expand


    /* expand the line */
    if ( CurrIfState == BLOCK_ACTIVE ) {
/* expand (text) macros. If expansion occured, rescan the line */
while ( Token_Count > 0 && ExpandLine( line, tokenarray ) == STRING_EXPANDED ) {
    DebugMsg1(("GetPreprocessedLine: expanded line is >%s<\n", line));
    Token_Count = Tokenize( line, 0, TRUE );
}
    }

    /* handle directives and (anonymous) data items */

I just copyed this in there, so this needs some help.

Brrr, what an ugly mess - just for such a VEEEEERRRRY minor issue!? If you mix preprocessor and parser functionality like in your proposal, you'll end in a totally unreadable and unmaintainable pile of sh...

btw, you don't want to query CurrIfState once the conditional assembly directives (IF, ELSE,...) have been handled in the preprocessor.

[nidud]

deleted

[japheth]

Good (or at least better)?

I don't dare to judge.

The only approach that has a faint chance to be implemented is to delay macro expansion by some kind of syntax extension. You can see this approach in effect in struct initialization, when a macro call is located within the initialization literal. Quite the same approach may be added to the hll directives, that is, the macro call has to be enclosed in <>:

    .if <whatever()>

with this approach, you just have to add a few lines in hll.c ( determine if there's a literal following the directive and if so, expand the rest of the line ), the rest of the code remains as it is.

[nidud]

deleted

[jj2007]

...but a regression test will probably tell a different story.

Unfortunately yes. My little testbed (attached) with the .While Instr_(esi, ... stuff reports plenty of errors, while the latest JWasm build (25-Oct-2012 04:03) works just fine.
Strangely enough, your modified version assembles my fat testbed without any problems. So it must really be the specific "warning" code.

In the meantime, I have instructed my editor (RichMasm, part of the MasmBasic package) to issue a warning for
.While mac()
and
.elseif mac()
- imho the most relevant cases. That was really hard work for a noob who understands only BASIC, but it seems to fit the purpose, and the performance loss is acceptable: overall build time with JWasm is 0.2% slower for the RichMasm source with its 14,000 lines

[nidud]

deleted

[nidud]

deleted