News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

real or BCD number not allowed

Started by Ficko, July 02, 2010, 04:13:13 PM

Previous topic - Next topic

Ficko

How can you push or mov a real4 number in MASM? ::)


push 3.4              ;bad
push real4 ptr 2.0    ;bad


Ficko

All right MASM sucks can JWASM do that? :P

jj2007

Zooba's macro is quite a good option:

movr4 MACRO dest:REQ, src:REQ
    mov dest, 0BADF00Dh
    ORG $-4
    REAL4 src
ENDM


The same in function format would be great, but it seems not so straightforward. Unless we can do the REAL4 to DWORD conversion in assembly time calculations.

As an intermediate solution:
pushr4 MACRO src:REQ
push 0BADF00Dh
ORG $-4
REAL4 src
ENDM



Just saw that Ultrano had it already:
pushfl macro float1
  db 68h ; "push immediate dword"
  real4 float1
endm

dedndave

i like the last one   :P
nothing like writing pure machine language

Ficko

Quote
Zooba's macro is quite a good option:

Yes but I need some enhancement.  :bg

I have this:

%echo VarConst
-10*2


now I have to push it as a real4.

How I can get the calculation back in assembler time  (-20) So I can add ".0"  - VarConst CATSTR -20,<.0> - before pushr4 ?  ::)



Ficko

Never mind figured out.


Tmp EQU VarConst
%CatStr(<%Tmp>)


gives -20  :dance:

Rockoon

I am still saddened that none of the assemblers that I am aware of can do simple math on floating point preprocessor variables.
When C++ compilers can be coerced to emit rcl and rcr, I *might* consider using one.

dedndave

i don't think it's that simple   :P
i'd love to see what you have, though   :U

raymond

I've always wondered why some people do not adhere to the KISS principle.

In this example, why not simply initialize it as a global variable in the .data section and get it from there??? :dazzled: For all practical purposes, it's about the same amount of typing!!!

.data
   fl3p4   REAL4   3.4

.code
   push   fl3p4

When you assume something, you risk being wrong half the time
http://www.ray.masmcode.com

jj2007

Quote from: raymond on July 04, 2010, 02:39:51 AM
I've always wondered why some people do not adhere to the KISS principle.

Raymond, the goal is a direct invoke MyProc, 123.456, -12.45e3 in the sense of
push an immediate dword aka -12.45e3
push an immediate dword aka 123.456
call MyProc

i.e. posters don't want to push a memory reference but rather the number itself as an "immediate real4".
If I were a lot better at maths, I'd be tempted to do the translation from123.456 to its hex equivalent in a macro :bg

jj2007

Rockoon's remark on preprocessing inspired me to teach RichMasm something useful: Calculate the hex equivalent.
Imagine you have the following full-fledged Win32 application in PureMasmTM:
include \masm32\MasmBasic\MasmBasic.inc
MyTest PROTO :REAL4, :REAL4

Init
invoke MyTest, r4(-12.34567e-9=-1303111467), r4(987.654=1148643803)
Exit

MyTest proc arg1:REAL4, arg2:REAL4
  Print Str$("The args are %f and ", s:arg1), Str$(s:arg2)
  ret
MyTest endp

end start


Output: The args are -1.234567e-08 and 987.6540

How does it work?
1. Select the red part in invoke MyTest, r4(-12.34e5=?), r4(987.654=1148643803)
2. Press F1
3. See invoke MyTest, r4(-12.34e5=-912874880), r4(987.654=1148643803) - ready for assembly

:bg

The r4 macro is part of MasmBasic:
r4 MACRO arg
LOCAL is
  is INSTR <arg>, <=>
  if is
EXITM @SubStr(<arg>, is+1)
  else
EXITM <arg>
  endif
ENDM

raymond

QuoteIf I were a lot better at maths, I'd be tempted to do the translation from123.456 to its hex equivalent in a macro

BUT, it's so much easier to let the assembler transform it in the data section, and you don't need to know any of the required math. :bdg You then refer to it as a pointer to it's address or as it's actual value, whichever suits your needs.
When you assume something, you risk being wrong half the time
http://www.ray.masmcode.com

jj2007

Quote from: raymond on July 05, 2010, 12:18:47 AM
BUT, it's so much easier to let the assembler transform it in the data section, and you don't need to know any of the required math. :bdg You then refer to it as a pointer to it's address or as it's actual value, whichever suits your needs.

The "direct" push saves 5 bytes per float... we are stingy here :green

Rockoon

Quote from: jj2007 on July 05, 2010, 01:37:28 PM
Quote from: raymond on July 05, 2010, 12:18:47 AM
BUT, it's so much easier to let the assembler transform it in the data section, and you don't need to know any of the required math. :bdg You then refer to it as a pointer to it's address or as it's actual value, whichever suits your needs.

The "direct" push saves 5 bytes per float... we are stingy here :green

..and an entire cache line

These sorts of hacks sadden me, because even though they "work" in this specific case, you still cant do preprocessor math.

As a simple for-instance, you might have the constant pi=3.1415 and then (as is common) you also might want to derive 2*pi as another constant. Later you could change pi to = 3.14159265 and that 2*pi constant would reflect the change.

I realize that in this case, the case-specific argument would be "just define pi accurately the first time" .. but what about all the cases where it isnt some universal constant?
When C++ compilers can be coerced to emit rcl and rcr, I *might* consider using one.