Are there macros For- Next and If using REAL8?

[HSE]

Hi!

I'm using ObjAsm32 and SmplMath in the same project and, because Jwasm** don't support the great number of macro levels, I'm using ML. That prevent the use of MasmBasic (needed is to say that I can't run the example of MbFor-MbNext with floating numbers, but that is another subject, surely my fault).

I have some rustic ideas for the loop, and the "if" is not a true problem, but perhaps exist better thinked and readable ways.

** It is posible to use Jwasm compiling the objects and making libraries (apparently the maximum number of macro levels is not reached), but is not practical at all. 

Thanks. HSE

[HSE]

(needed is to say that I can't run the example of MbFor-MbNext with floating numbers, but that is another subject, surely my fault).

Of course my fault: I was using a 2014 version. Reinstalling with the last one work porperly.

Oh! I'm learning the JJ self dialog posting.

[jj2007]

because Jwasm** don't support the great number of macro levels, I'm using ML.

Interesting. I've had problems with JWasm in the past, but currently all MB macros work fine with it (and with ML 6.15 ... 10.0 - I haven't tested later versions). What kind of macros choke with JWasm?

[HSE]

Hi JJ!

Problem arise when using SmplMath macros inside a ObjAsm32, with JWasm v2.11. The object is a third degree one:
           Demo02      (Application)
                   Sim             (Integrator)
                        AnimalModelo2    (Model)

It's posible to compile AnimalModelo2 and to make a library. Demo02 compile correctly using the library.                           

Code Select Expand


d:\masm32\Projects\odm01\AnimalModelo2.inc(254) : Error A2100: Nesting level too deep
@TrimStr(7)[misc.inc]: Macro called from
  @MatchStrI(5)[misc.inc]: Macro called from
   FSLV_X86_FPU_ASSIGN_DEST(47)[x86_32_64_fpu.inc]: Macro called from
    FSBE_FNC(1)[backends.inc]: Macro called from
     MacroLoop(7): iteration 2: Macro called from
      ll_fSlv(376)[code_generator.inc]: Macro called from
       fSlv8(59)[SmplMath.inc]: Macro called from
        d:\masm32\Projects\odm01\AnimalModelo2.inc(254): Included by
         IncludeObjectSrc(4)[Objects.inc]: Macro called from
          MakeObjects(1)[Objects.inc]: Macro called from
           Demo02.asm(69): Main line code


There is no problem with ML 6.14. MS site say that ML nesting limit for text macros is 40. I don't know how many levels support JWasm nor if ML 6.14 have 40.

[rrr314159]

JWasm supports many levels of macros, a lot more than shown here: at least 40 no doubt. Since JWasm manual doesn't mention it, it should be same as ML.

JWasm Error codes:

x100 Nesting level too deep 
x101 Macro nesting level too deep 

error 100 does not say "macro nesting level", that's 101. And yet 100 is, in fact, often caused by macros. I get it pretty often, usually means infinite macro recursion (a bug).

Note that JWasm expands symbols more than ML. FWIW I would guess that's the problem here. This happens in a few contexts. For instance,

Code Select Expand

_t textequ <t>
%echo ._t

JWasm will expand _t to t, but ML leaves it as _t.

Also see the thread "Weird MACRO behavior" where jj and I discussed a similar problem.

[habran]

Code Select Expand

/* in Masm, there's a nesting level limit of 20. In JWasm, there's
* currently no limit.
*/

[jj2007]

In JWasm, there's currently no limit

Habran, my friend! No mention of "available RAM" etc?? 

[qWord]

#define MAX_MACRO_NESTING       40 /* macro call nesting  */

I guess the error comes from some other incompatibility, but that's hard to say without test case.

[rrr314159]

Habran, perhaps some version of JWasm had a higher limit, but the one I'm using - which I think is your latest 64-bit - apparently stops at 40. I wrote a simple test prog:

Code Select Expand

sum1toN MACRO NN
LOCAL N
    IF NN EQ 0
        EXITM<NN>
    ENDIF
    N = NN
    N = NN + sum1toN (N-1)
    EXITM<N>
ENDM

thenum$ textequ <18>
n$ TEXTEQU %Sum1toN (%thenum$)
%echo sum 1 to thenum$ = n$

; 18 works for ML64 but 19 gives error A1007 "nesting level too deep"
; 39 works for JWasm but 40 gives error A2100 "nesting level too deep"

.code
start PROC
    ret
start endp
end

JWasm goes all the way to 39: makes sense since it's called one last time for zero. But ML64 only goes to 18, so apparently there are 2 nesting levels for every call. Maybe it's the IF-ENDIF?

There are certainly incompatibilities, but usually (as in this case) in H/JWasm's favor.

BTW this doesn't entirely answer the question, it's possible that non-recursive macros could go deeper, even "unlimited" as Habran says. Because possibly the IF-ENDIF has something to do with it, and I can't see how to avoid it in a recursive macro. If someone has time on their hands they could check that ..

[habran]

qWord was right, this is written in globals.h:

Code Select Expand


#define MAX_IF_NESTING          20 /* IFxx block nesting. Must be <=32, see condasm.c */
//#define MAX_TEXTMACRO_NESTING   20
#define MAX_SEG_NESTING         20 /* limit for segment nesting  */
#ifdef __I86__
#define MAX_MACRO_NESTING       20
#else
#define MAX_MACRO_NESTING       40 /* macro call nesting  */
#endif
#define MAX_STRUCT_NESTING      32 /* limit for "anonymous structs" only */


In hll.h it is written:

Code Select Expand


/* in Masm, there's a nesting level limit of 20. In JWasm, there's
* currently no limit.
*/

#ifdef DEBUG_OUT
static unsigned evallvl;
static unsigned cntAlloc;  /* # of allocated hll_items */
static unsigned cntReused; /* # of reused hll_items */
static unsigned cntCond;   /* # of allocated 'condlines'-buffer in .WHILE-blocks */
static unsigned cntCondBytes; /* total size of allocated 'condlines'-buffers */
#endif


[HSE]

Hi!

Take a couple of hours eliminate some doubts (I have removed all the conecctions between objects and compiled all the libraries). When I abandon JWasm the model was no functional yet. Perhaps Jwasm compile the libraries with errors?...

                   No. The model compiled by JWasm work perfectly. This means that there is no fundamental diferences involved in the interpretation of this macros.

If the problem is to change the limits in the next compilation of JWasm, the solution look pretty simple.

Thanks. HSE

[qWord]

It would be helpful if you break down the problematic code into a small test program. This would allow to find the cause of the problem.

[Biterider]

Hi HSE
Could you post your code? Maybe we can find a way to simplify something to reduce the invocation depth.

Regards, Biterider

[HSE]

Hi!!

I remove a lot of thing (90% of variables and equations, and model make nothing) but the structure it's the same.  Apparently size matter because the errors report is not the same. Demo02.asm is the main file.

In  objects.zip there is two little objects, in the application only buttonW is needed. The files must be copied to ObjAsm32\code\objects. They are wrappers of MS controls that for some good reason Biterider don't use, but I do. 

Regards, HSE

[HSE]

I found a little of bad practice: two macros were included in the working files, and not in the main file.