Author Topic: Never a compiler for SmplMath  (Read 2151 times)

HSE

  • Member
  • ****
  • Posts: 533
  • <AMD>< 7-32>
Never a compiler for SmplMath
« on: August 03, 2016, 12:51:22 AM »
Hi qWord!!

Don't work:
Code: [Select]
fSlv8 TSFAF = VTSFAF*(ebw^0.75)*TSDEG*T3/(1.0+(CFA/K1TSFA)^EXP10+(KTSFAF/CTS)^THETA1)


Work:
Code: [Select]
fSlv8 TSFAF = (VTSFAF*(ebw^0.75)*TSDEG*T3)/(1.0+((CFA/K1TSFA)^EXP10)+((KTSFAF/CTS)^THETA1))

Take me some time to find what the problem was: parenthesis. I don't know if it's the expected behaviour.

Assembled with HJWasm

Thanks.

edited: I lost the missing parenthesis when pasting, it's in the code.

qWord

  • Member
  • *****
  • Posts: 1454
  • The base type of a type is the type itself
    • SmplMath macros
Re: Never a compiler for SmplMath
« Reply #1 on: August 03, 2016, 01:26:14 AM »
The second expression has unbalanced brackets: the last ')' is misplaced. MASM has problems with unbalanced brackets and throws errors on its own, independent on the detection mechanisms of the macros. That the reason why will get difference error messages with JWasm. (And yes, it should not assemble)

Pleas remarks that I cannot give any support for HJWasm, because this assembler is not MASM compatible.

regards


BTW: "Don't work " it no good description
MREAL macros - when you need floating point arithmetic while assembling!

HSE

  • Member
  • ****
  • Posts: 533
  • <AMD>< 7-32>
Re: Never a compiler for SmplMath
« Reply #2 on: August 03, 2016, 02:19:48 AM »
The first expression result is NaN or infinite (ftst  C3=1 and C0 =1). The second give the expected value (I think).

This expression also need additional parenthesis before the division:
   fSlv8 RTOX1 = (CGL*(CAC+KACCD))/(CAC*(CGL+KGLCD/AHOR))


AsmC is MASM compatible?

Thanks.

qWord

  • Member
  • *****
  • Posts: 1454
  • The base type of a type is the type itself
    • SmplMath macros
Re: Never a compiler for SmplMath
« Reply #3 on: August 03, 2016, 02:51:18 AM »
I can't reproduce your problem (MASM,JWasm) - you might upload an minimized example that shows the behavior.

AsmC is MASM compatible?
I guess yes, but I'm the wrong person to ask that.
MREAL macros - when you need floating point arithmetic while assembling!

HSE

  • Member
  • ****
  • Posts: 533
  • <AMD>< 7-32>
Re: Never a compiler for SmplMath
« Reply #4 on: August 03, 2016, 12:44:57 PM »
I can't reproduce your problem (MASM,JWasm) 


I also fail to reproduce in little examples with plain masm, OOP masm, ml, hjwasm. In the full program there is around 800 equations in almost 2500 lines (some equations are very long but not very complex). Some equations with problems need aditional parenthesis and others some rearrangement. Perhaps it's related to "storing expressions between parenthesis for reuse" (something like that say the documentation) or other thing that exceed some capacity.

 

qWord

  • Member
  • *****
  • Posts: 1454
  • The base type of a type is the type itself
    • SmplMath macros
Re: Never a compiler for SmplMath
« Reply #5 on: August 03, 2016, 10:14:58 PM »
The generated code differs slightly with and without brackets, but that is intended.
From your description it is that there are no warnings or errors while assembling, but the runtime result are wrong, resp. depends on using brackets(?). Did you trace the evaluation with a debugger? Or can you post the disassembly of the expressions with and without brackets? Does the same problem occurs with MASM/JWasm?
One possibility is that there are not enough free registers and the detection mechanism for that fails...

Other thought:  split your current source into several modules and see if the problem still occurs.
MREAL macros - when you need floating point arithmetic while assembling!

HSE

  • Member
  • ****
  • Posts: 533
  • <AMD>< 7-32>
Re: Never a compiler for SmplMath
« Reply #6 on: August 03, 2016, 11:05:13 PM »
Thanks qWord! I will try to debug a little.
 
MASM not work with long lines, I only used HJWasm for full program.


HSE

  • Member
  • ****
  • Posts: 533
  • <AMD>< 7-32>
Re: Never a compiler for SmplMath
« Reply #7 on: August 13, 2016, 04:44:59 AM »
Hi qWord!

At first glance I don't see what the problem is.

Code: [Select]
Full error
0040DC3B    DD86 BC260000   FLD QWORD PTR DS:[ESI+26BC]
0040DC41    DC86 1C1D0000   FADD QWORD PTR DS:[ESI+1D1C]
0040DC47    DC8E EC280000   FMUL QWORD PTR DS:[ESI+28EC]
0040DC4D    DD86 EC280000   FLD QWORD PTR DS:[ESI+28EC]
0040DC53    DD86 241D0000   FLD QWORD PTR DS:[ESI+1D24]
0040DC59    DCB6 042C0000   FDIV QWORD PTR DS:[ESI+2C04]
0040DC5F    DEC1            FADDP ST(1), ST
0040DC61    DC8E BC260000   FMUL QWORD PTR DS:[ESI+26BC]
0040DC67    DEF9            FDIVP ST(1), ST
0040DC69    DD9E B42E0000   FSTP QWORD PTR DS:[ESI+2EB4]

Full extra brackets - Well
0040DC3B    DD86 BC260000   FLD QWORD PTR DS:[ESI+26BC]
0040DC41    DC86 1C1D0000   FADD QWORD PTR DS:[ESI+1D1C]
0040DC47    DC8E EC280000   FMUL QWORD PTR DS:[ESI+28EC]
0040DC4D    DDD9            FSTP ST(1)
0040DC4F    DD86 EC280000   FLD QWORD PTR DS:[ESI+28EC]
0040DC55    DD86 241D0000   FLD QWORD PTR DS:[ESI+1D24]
0040DC5B    DCB6 042C0000   FDIV QWORD PTR DS:[ESI+2C04]
0040DC61    DEC1            FADDP ST(1), ST
0040DC63    DC8E BC260000   FMUL QWORD PTR DS:[ESI+26BC]
0040DC69    D8F9            FDIVR ST, ST(1)
0040DC6B    DD9E B42E0000   FSTP QWORD PTR DS:[ESI+2EB4]
0040DC71    DDC0            FFREE ST

Test without extra brackests
004010F5    DD46 18         FLD QWORD PTR DS:[ESI+18]
004010F8    DC46 20         FADD QWORD PTR DS:[ESI+20]
004010FB    DC4E 10         FMUL QWORD PTR DS:[ESI+10]
004010FE    DD46 10         FLD QWORD PTR DS:[ESI+10]
00401101    DD46 28         FLD QWORD PTR DS:[ESI+28]
00401104    DC76 30         FDIV QWORD PTR DS:[ESI+30]
00401107    DEC1            FADDP ST(1), ST
00401109    DC4E 18         FMUL QWORD PTR DS:[ESI+18]
0040110C    DEF9            FDIVP ST(1), ST
0040110E    DD5E 38         FSTP QWORD PTR DS:[ESI+38]


Test brackets
004010F5    DD46 18         FLD QWORD PTR DS:[ESI+18]
004010F8    DC46 20         FADD QWORD PTR DS:[ESI+20]
004010FB    DC4E 10         FMUL QWORD PTR DS:[ESI+10]
004010FE    DDD9            FSTP ST(1)
00401100    DD46 10         FLD QWORD PTR DS:[ESI+10]
00401103    DD46 28         FLD QWORD PTR DS:[ESI+28]
00401106    DC76 30         FDIV QWORD PTR DS:[ESI+30]
00401109    DEC1            FADDP ST(1), ST
0040110B    DC4E 18         FMUL QWORD PTR DS:[ESI+18]
0040110E    D8F9            FDIVR ST, ST(1)
00401110    DD5E 38         FSTP QWORD PTR DS:[ESI+38]
00401113    DDC0            FFREE ST

later1: Apparently extra brackets make free 2 unused fpu registers (without evident purpose). Perhaps there is a previous operation that fill registers and not make free?

later2: finit before the equation solve the problem, somewhere something is filling registers.

later3: I found I'm misusing function "min" (I forget to create "min4" for 4 arguments) and here fpu registers are filling. 
« Last Edit: August 13, 2016, 11:53:42 PM by HSE »

qWord

  • Member
  • *****
  • Posts: 1454
  • The base type of a type is the type itself
    • SmplMath macros
Re: Never a compiler for SmplMath
« Reply #8 on: August 16, 2016, 08:49:49 AM »
later3: I found I'm misusing function "min" (I forget to create "min4" for 4 arguments) and here fpu registers are filling.
So the problem was your code?

regards
MREAL macros - when you need floating point arithmetic while assembling!

HSE

  • Member
  • ****
  • Posts: 533
  • <AMD>< 7-32>
Re: Never a compiler for SmplMath
« Reply #9 on: August 16, 2016, 12:48:26 PM »
Yes, my error (of course  :biggrin: )

But there is an error using extra brackets. You can lost 2 fpu register contents, without  consequences if results are stored in variables. Perhaps a problem when storing results in fpu registers. For now only need a warning: "never use extra brackets".

Thanks.

qWord

  • Member
  • *****
  • Posts: 1454
  • The base type of a type is the type itself
    • SmplMath macros
Re: Never a compiler for SmplMath
« Reply #10 on: August 18, 2016, 08:39:28 AM »
But there is an error using extra brackets. You can lost 2 fpu register contents, without  consequences if results are stored in variables. Perhaps a problem when storing results in fpu registers. For now only need a warning: "never use extra brackets".
Sorry, but I can't do anything as long as you do not show me a piece of code that reproduce that behavior.
Other thought: Did you save/store values on the FPU stack and then call fSlv-macros? If so, you must inform that macro-calls about the stack usage by using the attribute {stck:N}, where N is the number of values already pushed on the FPU stack. Otherwise the values might be overwritten, e.g. to save the result of an bracket expression.

regards
MREAL macros - when you need floating point arithmetic while assembling!

HSE

  • Member
  • ****
  • Posts: 533
  • <AMD>< 7-32>
Re: Never a compiler for SmplMath
« Reply #11 on: August 18, 2016, 10:31:59 AM »
In "extra brackets" (http://masm32.com/board/index.php?topic=5565.msg59545#msg59545)

Code: [Select]
0040DC4D    DDD9            FSTP ST(1)

is emptying 1 FPU registers (I thought were emptied 2 registers by equation but surely I have 2 similar equations next)

In the models I'm using only SmplMath without storing in FPU stack. In integration mathematics part I mainly use FPU instructions, with very elemental SmplMath use (ej. fSlv8 xc = x + h / 5.0). Never was a problem, just now in some way "hide" my error. In this particular equation extra brackets are totally unnecessary (they are "extra").

attribute {stck:N}
Very good remainder  :t (I forgot totally that possibility).   
 

qWord

  • Member
  • *****
  • Posts: 1454
  • The base type of a type is the type itself
    • SmplMath macros
Re: Never a compiler for SmplMath
« Reply #12 on: August 18, 2016, 10:58:28 AM »
In "extra brackets" (http://masm32.com/board/index.php?topic=5565.msg59545#msg59545)

Code: [Select]
0040DC4D    DDD9            FSTP ST(1)

is emptying 1 FPU registers
The instruction is useless but (unfortunately) intended and is definitely not a bug (... except in terms of performance). The reason is that results of bracket expressions are saved above all pushed values (because of that there are these free-instructions at end of produced code).

AFAICS the problem is somewhere else...

MREAL macros - when you need floating point arithmetic while assembling!

HSE

  • Member
  • ****
  • Posts: 533
  • <AMD>< 7-32>
Re: Never a compiler for SmplMath
« Reply #13 on: August 18, 2016, 11:52:39 PM »
I can tell you the same I say to JJ: give me at list a couple of years to understand your macros and we will talk  :lol:

(I found the test in the directory "test", how I will think to search inside!!)

qWord

  • Member
  • *****
  • Posts: 1454
  • The base type of a type is the type itself
    • SmplMath macros
Re: Never a compiler for SmplMath
« Reply #14 on: August 19, 2016, 02:40:32 AM »
Code: [Select]
        fld1
        fld1
        fSlv8 RTOX1 = (CGL*(CAC+KACCD))/(CAC*(CGL+KGLCD/AHOR))
        ;...
That's wrong macro usage. The macro assumes an empty FPU stack.
Should be -->
Code: [Select]
        fld1
        fld1
        fSlv8 RTOX1 = (CGL*(CAC+KACCD))/(CAC*(CGL+KGLCD/AHOR)) {stck:2}  ; <=== two values pushed on stack
        ;...
MREAL macros - when you need floating point arithmetic while assembling!