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
Quote from: HSE on June 30, 2015, 01:18:42 AM
(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.
Quote from: HSE on June 30, 2015, 01:18:42 AMbecause 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?
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.
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.
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,
_t textequ <t>
%echo ._t
JWasm will expand _t to t, but ML leaves it as _t.
Also see the thread "Weird MACRO behavior" (http://masm32.com/board/index.php?topic=4040.msg42729#msg42729) where jj and I discussed a similar problem.
/* in Masm, there's a nesting level limit of 20. In JWasm, there's
* currently no limit.
*/
Quote from: habran on July 01, 2015, 07:18:12 AMIn JWasm, there's currently no limit
Habran, my friend! No mention of "available RAM" etc?? :eusa_boohoo:
Quote from: globals.h#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.
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:
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 ..
qWord was right, this is written in globals.h:
#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:
/* 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
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. :eusa_clap:
Thanks. HSE
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.
Hi HSE
Could you post your code? Maybe we can find a way to simplify something to reduce the invocation depth.
Regards, Biterider
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
I found a little of bad practice: two macros were included in the working files, and not in the main file. :eusa_snooty:
Hi HSE
I'm not able to see something obviously wrong. Can specify the line that triggers the problem. Line 254 in AnimalModelo2 doesn't exist...
Have you tried to isolate the offending line? Maybe a splitting of a long calcaulation into single steps can reduce the macro interation depth.
Regards, Biterider
Hi Biterider!
There is nothing wrong. All work perfectly. But that is true when compiling with the old ML, because JWasm have some limitation to manage the high level of macros that I'm using. If only JWasm is available, then you need to make libraries of the objects (more complex but it's a posibilty if there is no choice).
Perhaps the compilation result in error because in the first zip I have omited 2 macros.
The question became what happens in JWasm. rrr found that the problem is not exactly the number of macro levels, but something related.
In the midtime I modify the old ForLp-Next macro for to use float numbers, not so good as the MasmBasic one, but work with ML.
Thanks. HSE
Just to note (I was forgetting to do that) that in SmplMath there are very usefull macros for .if float comparison. Surely I skip the page the first time I read the documentation, but I discover them in a second reading.
Thanks. HSE
Quote from: HSE on July 30, 2015, 01:59:00 AMin SmplMath there are very usefull macros for .if float comparison.
We had a thread about them in the old forum. (http://www.masmforum.com/board/index.php?topic=18529.msg156635#msg156635)
Thanks jj, very interesting :t