the following works:

 .data
  xyz     real8 23423.32423
the following doesn't:

 .code
  mov real8 ptr , 23423.32423 <---because it's ALIVE!
doesn't masm convert floating number into hexadecimal? i mean, it's much easier with:

 mov real8 ptr , 23423.32423
than:
                  
                        +-----------+
                        |           |
  mov dword ptr ,  0C02F2F98h  |
  mov dword ptr ,40D6DFD4h   |
                        |           |
                        +----+------+
                             |
                             +--you think you can convert floating
 number into hex value like that? well, i can't. and even if i know
 the rule for doing that, i still wouldn't sit and do it by hand.
so, my question is: is there any other way around this problem? or do i have no choice and have to stick with this:

  mov dword ptr ,  0C02F2F98h
  mov dword ptr ,40D6DFD4h
format?
Posted on 2001-07-05 22:24:00 by disease_2000
macro?
Posted on 2001-07-05 22:57:00 by bitRAKE
macro? hmm... i don't play with macro that much. therefore, my knowledge is not up to the level of coding such.
Sounds like it would be a great oportunity to have a learning experience? ;) I'd be glad to provide commentary. :D Oh, hell - I'll give it go - it's on my To MACROize list. :D I'll be thinking about it at work, so it could take some time to finish.
Posted on 2001-07-05 23:25:00 by bitRAKE
I just don't like using the same icon all the time. Posted on 2001-07-06 00:09:00 by bitRAKE
disease: There is an easy workaround for your problem. Create a macro that first codes a full mov instruction with any number, and make sure the number of bytes you move are the same as the size of the floating point value, like this:

blah  REAL4 ? 
mov dword ptr , 88888888h 
This assembles to (in my case): C7055230400088888888 mov d,[000403052],088888888h As you can see the last 4 bytes are the dword value you move into the variable. The only thing you have to do is make masm overwrite this value with a real4 value you define. This can be done with the ORG instruction, which sets the current address in the data or code etc.

mov dword ptr , 88888888h 
org $-4 ;means: this offset($) - 4 bytes
REAL4 12345.6789
This assembles to: C70552304000B7E64046 mov d,[000403052], 0B7E64046h So the macro code would be something like:

memfloat4 MACRO mem:REQ, value:REQ
   mov dword ptr , 088888888h
   org $-4
   REAL4 value
ENDM
You can extend it with an extra parameter to handle real8 or real10s, or create multiple macros. Thomas
Posted on 2001-07-06 02:48:00 by Thomas
wonderful, Thomas. last night when i was in bed, i tried to come up a solution. i still haven't got the solution, but my solution is near yours... i would say 35% near. ------------------------------------------------------------ i just read your msg. it's pure logic which works quite well. This message was edited by disease_2000, on 7/6/2001 5:59:56 AM
Posted on 2001-07-06 05:54:00 by disease_2000
hold on, there seemed to be a problem. (still testing that macro. i'll post comment once i'm done analyzing it. stay tune.)
Posted on 2001-07-06 06:09:00 by disease_2000
here's my version:

movr4     macro mem:REQ, value:REQ
          db 0c7h, 05h
          dd offset mem
          real4 value
endm
i test it and use hiew to check the hex code. here's what i get:
C7050C10400000002040  mov  d,[00040100C],040200000
C7050C10400000002040  mov  d,[00040100C],040200000

and the asm code where:

 movr4 myreal, 2.5
 mov dword ptr , 40200000h
it works. :) if you understand how that macro works, then you can code another one for r8, and r10. which i believe you have no problem in doing so. ------------------------------------------------------------ at the moment i'm trying to code one for r8, r10. i don't think it's as easy as: db ... offset mem... real4... real8 = QWORD (you need 2 32bit quantity...) post yours if you got it done before me. This message was edited by disease_2000, on 7/6/2001 7:12:17 AM
Posted on 2001-07-06 07:02:00 by disease_2000
(still working on the solution, it's possible. HEEHEH) ------------------------------------------------------------ hmm... i don't think i have more brain cell to continue.... i think i need help on this now. here's my plan of doing it.


movr8     macro mem:REQ, value:REQ
          local stack       ;make it local so there's
                            ;no conflict. :)

          stack equ dq value;save value temporary for
                            ;later use. this won't
                            ;increase your exe size if
                            ;not use

          db 0c7h, 05h      ;mov dword ptr
          dd offset mem-32  ;first operand<--address
                            ;of mem (low or high? i'm
                            ;not sure if the order i'm
                            ;doing is correct..

          db stack-32       ;second operand <--take
                            ;low or high of stack...

          db 037h, 05h      ;mov dword ptr
          dd offset mem-08  ;first operand
                            ;same here...

          db stack-08       ;second operand
                            ;same here..

endm
hope that help. note: the above code doesn't (doesn't compile either). that's just my idea of solving the problem, maybe you can look at it and come up with your own. have a good day. This message was edited by disease_2000, on 7/6/2001 7:51:22 AM This message was edited by disease_2000, on 7/6/2001 10:08:22 PM
Posted on 2001-07-06 07:38:00 by disease_2000
I forgot there where no mov instructions for 8 and 10 byte values... But I've nearly found a solution:

movr8	MACRO memloc:REQ, val:REQ
  db    0C7h, 05h
  dd    offset memloc+4
  REAL8 val
  org   $-4
  db	0C7h, 05h
  REAL8 val
  org   $-8
  dd    offset memloc
  org   $+4
ENDM
I'm not sure if the first offset memloc+4 should be swapped with the other one, because the macro still doesn't work perfectly. Somehow, and I have really NO IDEA how this is possible, masm thinks the second 'offset memloc' = 0. If anyone knows why this happens please tell me.. Thomas
Posted on 2001-07-06 08:15:00 by Thomas
Hmm I saw your reply after I've replied.. but I don't think yours will work:

dd offset mem-32  ;first operand<--address
                  ;of mem (low or high? i'm
                  ;not sure if the order i'm
                  ;doing is correct..
Correct me if I'm wrong, but I think this just puts a dword in the code with the value (offset mem - 32 bytes)... If that strange error in my code would be solved it will work, but I don't know how to get rid of that problem. Thomas btw Please don't delete posts, they might be usefull for others.. This message was edited by Thomas, on 7/6/2001 8:19:38 AM
Posted on 2001-07-06 08:18:00 by Thomas
alright. i'll keep those msg above intact. (i was deciding of wiping out those msg, cause i think it might annoy some people. :D ) thomas, even if there's a work around for
 offset memloc 
there's another problem that you have to face. take for exmaple:

memfloat4 MACRO mem:REQ, value:REQ
   mov dword ptr , 088888888h
   org $-4
   REAL4 value
ENDM
the problem i found is that masm is dumb (no offense. :) ) the code above will just generate 088888888h and then comes real4 value (org $-4) is ignore. another problem is this: having two
 REAL8 val 
inside movr8 is a disaster... (note: i didn't test.. at the moment, i'm speaking with my mind). the reason for that is because memloc is already real8, what you have to do is break it down into two MOVE instruction (rakesion will have no problem with this, you can actually do this in one MMX instruction, but that's not what i'm looking for..) -----------------------------------------------------------------


movr8   MACRO memloc:REQ, val:REQ
  db    0C7h, 05h           ;mov dword ptr
  dd    offset memloc+4
  REAL8 val                 ;this might cause problem.
  org   $-4
  db   0C7h, 05h
  REAL8 val                 ;so will this
  org   $-8                 ;masm ignore org backward
  dd    offset memloc
  org   $+4                 ;this might work. but no use
                            ;cause every thing in the back
                            ;is messed up with both real8
ENDM

 analyze:
 xyz      real8 2.5 <--- will assembled into:
 40200000 00000000  <--- represent 2.5

 now, if  you have both real8 val in your code, this is what you'll
 get:

 40200000 00000000 +--
 40200000 00000000 +------both of those value will be in the exe.
 and how are you going to remove it?
============================================================ through my observation, i found that org cannot erase value when you go backward with the org... and whenever you declare value, it will stays there. that's why i decided to have: local stack stack equ dq value <--- doesn't generate any code unless used. example of what i mean:


 let xyz = 2.5
 stack equ dq value
 ;stack will then holds: 40200000 00000000
                             L       H ;or the reverse, i'm
                                        not sure.

 so, that code is just there. but masm will not include it
 into your exe unless you actually use it with real code.
 ----------------------------------------------------------
 here's asm code sample that might help you to understand
 my explaination:

 .data
  xzy real8 ?

 .code
 ; move 2.5 into xyz
 mov dword ptr ], 0
 mov dword ptr , 40200000h


This message was edited by disease_2000, on 7/6/2001 9:18:03 AM
Posted on 2001-07-06 08:56:00 by disease_2000
the problem i found is that masm is dumb (no offense. ) the code above will just generate 088888888h and then comes real4 value (org $-4) is ignore
I don't understand this, it works fine for me, the values are overwritten properly. The only problem is that the second offset is written as 0... Also, I am braking it down into two movs. Here's the right analysis:

(assumed quadword value is at 403123h, and that the real8
 should be stored in memory as: 88 77 66 55 44 33 22 11.)

before macro:
bytes: ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 
db    0C7h, 05h           ;mov dword ptr
C7 05 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 
dd    offset memloc+4
C7 05 27 31 40 00 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 
REAL8 val                 ;this might cause problem.
C7 05 27 31 40 00 88 77 66 55 44 33 22 11 ?? ?? ?? ?? ?? ?? 
org   $-4
C7 05 27 31 40 00 88 77 66 55 44 33 22 11 ?? ?? ?? ?? ?? ?? 
                              ^ points back to here
db   0C7h, 05h
C7 05 27 31 40 00 88 77 66 55 C7 05 22 11 ?? ?? ?? ?? ?? ?? 
                              ^^^^^ 2 bytes overwritten
  REAL8 val                 ;so will this
C7 05 27 31 40 00 88 77 66 55 
C7 05 88 77 66 55 44 33 22 11 
      ^^^^^^^^^^^^^^^^^^^^^^^ 2 bytes overwritten, 8 bytes added

  org   $-8                 ;masm ignore org backward (no it doesn't :-)
C7 05 27 31 40 00 88 77 66 55 
C7 05 88 77 66 55 44 33 22 11 
      ^ points back to here
dd    offset memloc
C7 05 27 31 40 00 88 77 66 55 
C7 05 23 31 40 00 44 33 22 11 
      ^^^^^^^^^^^ 4 bytes overwritten with mem loc
org   $+4   
C7 05 27 31 40 00 88 77 66 55 
C7 05 23 31 40 00 44 33 22 11 
                             ^ points forward to the end.
ENDM
The final bytes stand for:

mov [00403127h], 55667788h
mov [00403123h], 11223344h
And I know realize the offset and offset+4 should be swapped :rolleyes: but that's no problem. If they are swapped there would be this:

mov [00403123h], 55667788h
mov [00403127h], 11223344h
which produces this output:

00403123h: 88 77 66 55 44 33 22 11
Which is what we want. And i've checked the macro, it does work with the backward orgs but the problem is that the second 'dd offset' produces a 0 DWORD, and I still don't know why. And of course the two DWORD values should be swapped to get the right qword order. Thomas This message was edited by Thomas, on 7/6/2001 9:19:23 AM
Posted on 2001-07-06 09:17:00 by Thomas
Here's the updated code:

movr8	MACRO memloc:REQ, val:REQ
 db	0C7h, 05h
 dd     offset memloc
 REAL8  val
 org    $-4
 db	0C7h, 05h
 REAL8  val
 org    $-8
 dd     offset memloc+4
 org    $+4
ENDM
This macro would be correct if masm handled the offset properly. I tested it with the value REAL8 123454235.354, which is stored in memory as:

FA 7E 6A 6D 0C 6F 9D 41
To test it, I just call the macro, assemble the file and open the exe in hiew to see the output assembly code. when the macro is called like this:

movr8 tempdat, 123454235.354
This is the output hiew gives:

C70504454000FA7E6A6D         mov       d,[000404504],06D6A7EFA
C705040000000C6F9D41         mov       d,[000000004],0419D6F0C
Which is nearly correct, because as you can see, the second memory location is wrong. Somehow, this line:

 dd     offset memloc+4
Is seen by masm as:

 dd     0+4
I think it has something to do with the orgs, maybe a bug in masm... If the mem loc would be correct, it would output:

mov       d,[000404504],06D6A7EFA
mov       d,[000404508],0419D6F0C
and when executed:

0404504: FA 7E 6A 06 0C 6F 9D 41
And this is the right value.. Thomas This message was edited by Thomas, on 7/6/2001 9:33:40 AM
Posted on 2001-07-06 09:30:00 by Thomas
(it's 4:47pm here, just woke up. my brain cell finally recharge). finally, i think i have the solution... :) it's 93.9% from finish. just a note thomas: ORG $-X is not compatible... i'm using masm6.15 and i analyze it VERY CAREFULLY through *.LST file and it just doesn't overlapp. try this:

 .code
  db 0AAh, 0BB, 0CCh, 0DDh
  org $-1
  db 0EEh
compile that and see if 0DDh got overlapp by 0EEh. cause on my computer it doesn't. that's why my movr4 codec is different than yours. (i'll go and eat now, i hope to have the movr8 codec finish later today)
Posted on 2001-07-06 16:44:00 by disease_2000
I think I see what the problem is, this is my listing:

 00000000  AA BB CC DD		  db 0AAh, 0BBh, 0CCh, 0DDh
				  org $-1
 00000003  EE			  db 0EEh
But as you can see, the EE byte is put at offset 3. So although all values are listed, the DD IS overwritten. When you link the object file, you will also see that in the output file, it works too. My masm version is also 6.15. But there's still the weird problem with the offset... :( Anyway it's a different timezone here, it's about 00:05 so I'm going to bed now :).. Thomas
Posted on 2001-07-06 18:02:00 by Thomas
:) i never knew that *.lst are different than *.obj file... now i think this really messed up my mind. i've tried various combination and what i look for the result was my listing file... i think i have to redo :D
Posted on 2001-07-06 18:15:00 by disease_2000
here''s the code i''ve modified into after realizing that *.obj is the file that has the actual codec once masm assembled the *.asm file.


 movr8  macro mem:req, val:req

        db 0c7h, 05h
        dd offset mem
        real8 val
        org $-4
        db 0c7h, 05h
        real8 val
        org $-8
        dd offset mem
        org $+4
 endm
Posted on 2001-07-06 19:27:00 by disease_2000
thomas, and everyone who view this thread, don''t try to run the code above that i post. it, however will crash your system deadly. (cool! another crash routine!) it works perfectly when you look through *.obj file. all data are organized the way they should be. but once run, your system will halt and you WILL have to restart. just a warning... thomas, your method works. the problem is that the second move attempts to write into ds: (that''s what my modified version based on your original does... i haven''t test your original code yet). right now, i''m trying to find another method (back to my old one. :) )
Posted on 2001-07-06 22:14:00 by disease_2000