I would like to extend the support in MASM32 for handling floating point values in a convenient manner. What I propose is the folowing set of macros to handle both on the fly FP values and direct insertion of FP values into instructions.
These allow the usage as follows,
Comments and suggestions would be appreciated.
Regards,
hutch@movsd.com
MACROS
These allow the usage as follows,
FLOAT10 MyFloat1,1234.5678901234
FLOAT10 MyFloat2,432.19876435678
fld MyFloat1 ; load 1st floating point value
fld MyFloat2 ; load 2nd floating point value
With the direct insertion of FP values,
fld FP80(1234.5678)
fld FP80(9876.5432)
Comments and suggestions would be appreciated.
Regards,
hutch@movsd.com
MACROS
FLOAT4 MACRO name,value
.data
name REAL4 value
.code
ENDM
FLOAT8 MACRO name,value
.data
name REAL8 value
.code
ENDM
FLOAT10 MACRO name,value
.data
name REAL10 value
.code
ENDM
FP4 MACRO value
LOCAL vname
.data
vname REAL4 value
.code
EXITM <vname>
ENDM
FP8 MACRO value
LOCAL vname
.data
vname REAL8 value
.code
EXITM <vname>
ENDM
FP10 MACRO value
LOCAL vname
.data
vname REAL10 value
.code
EXITM <vname>
ENDM
Hutch--, there is no reason not to use my macro, which does much more. Check it out at Thomas's snippet library, and feel free to add it to MASM32:
http://www.madwizard.org/snippets/viewSnippet.php?s_ID=15
http://www.madwizard.org/snippets/viewSnippet.php?s_ID=15
Ricky,
Interesting macro but I am not sure its doing what I want. I am particularly after simplicity and easy to read macros that correlate to the REAL4/8/10 data sizes.
Do you have any documentation on its use ?
Regards,
hutch@movsd.com
Interesting macro but I am not sure its doing what I want. I am particularly after simplicity and easy to read macros that correlate to the REAL4/8/10 data sizes.
Do you have any documentation on its use ?
Regards,
hutch@movsd.com
Sorry, I am lacking in this area. Let me see if I can hit the big points here. Actually, I'm using this version in my code:
The macro assumes if your using the macro then you mean to create an FPU constant, so no trailing period and zero is required on values. What else do you want to know?
Doesn't really meet your requirements, but it offers IMO features which MASM itself should have internally, but doesn't. It would be convenient to programmer to use it. I have an MMX one, too.
Edit: When I write FPU values, it is usually to a structure or pointer that exists. So, I have no need to defined named writable values inline - as your macros allow. Same goes for MMX.
__DEFAULT_FPU_SIZE__ EQU <REAL4>
;; examples:
;; fmul fpc(10)
;; fld fpc(<REAL8 -8>)
fpc MACRO val:REQ
LOCAL w,x,y,z
;; split type and value, defaulting to REAL4
z INSTR 1,<&val>,<! > ;; TAB doesn't work!
IF z EQ 0
y TEXTEQU __DEFAULT_FPU_SIZE__
x TEXTEQU <&val>
ELSE
;; REAL4 REAL8 or TBYTE
y TEXTEQU @SubStr(<&val>,1,z-1) ;; Type
x TEXTEQU @SubStr(<&val>,z+1,) ;; Value
ENDIF
;; should trim x of zeroes
;; replace . with _
z INSTR 1,x,<!.>
IF z EQ 0
w TEXTEQU x
x CATSTR x,<.0> ;; prevent error message
ELSE
w CATSTR @SubStr(%x,1,z-1),<_>,@SubStr(%x,z+1,)
ENDIF
;; replace - with _
z INSTR 1,w,<!->
IF z NE 0
w CATSTR @SubStr(%w,1,z-1),<_>,@SubStr(%w,z+1,)
ENDIF
;; figure out global name for constant
z SIZESTR y ;; use last char for size distiction
w CATSTR <__>,w,<r>,@SubStr(%y,z,1)
IF (OPATTR(w)) EQ 0 ;; not defined
CONST$fp SEGMENT
w y x
CONST$fp ENDS
ENDIF
EXITM w
ENDM
The addition is __DEFAULT_FPU_SIZE__ - which I use in other FPU macros for the default percision. If you don't specify a size for the constant then it defaults to the size defined by __DEFAULT_FPU_SIZE__. :P Here are some examples:fld fpc(REAL4 2.5)
fmul fpc(REAL4 2.5)
fld fpc(REAL8 2.5)
fld fpc(REAL4 2.5)
fld fpc(10) ; no error for no period
The macro creates a global name for each constant that is created and attempts to reuse that constant if it is specified again. For example, above the constant value REAL4 2.5 is only created once, not each time it is used. All the values are defined in the segment named CONST$fp which keeps all the FPU constants together in the program, and also allows the programmer to do something like:MyPI dd fpc(REAL10 3.14)
...which I guess isn't exactly useful, but basically means the macro doesn't interfere with the state of MASM and makes the macro very universal. :P
The macro assumes if your using the macro then you mean to create an FPU constant, so no trailing period and zero is required on values. What else do you want to know?
Doesn't really meet your requirements, but it offers IMO features which MASM itself should have internally, but doesn't. It would be convenient to programmer to use it. I have an MMX one, too.
Edit: When I write FPU values, it is usually to a structure or pointer that exists. So, I have no need to defined named writable values inline - as your macros allow. Same goes for MMX.
Hello hutch
i coded a little app in the past days that uses float point and real 4 values.
I?ll analyse it in order to built a macro example for you.
When i come home i?ll see if in what i can help.
Regards
Beyond2000!
i coded a little app in the past days that uses float point and real 4 values.
I?ll analyse it in order to built a macro example for you.
When i come home i?ll see if in what i can help.
Regards
Beyond2000!
Hutch,
The FP Macros would be a welcome addition. Any chance of supporting all of the data types? I.E. Real, Int, Packed BCD.
The Packed BCD is great for converting Reals, and Int's to and from Ascii.
The FP Macros would be a welcome addition. Any chance of supporting all of the data types? I.E. Real, Int, Packed BCD.
The Packed BCD is great for converting Reals, and Int's to and from Ascii.
Guys,
Thanks for your feedback, I have already implemented the ones above in the upgraded Prostart I posted a few days ago but I am interested in what the other data types would be.
The design of MASM32 was built around generic ASM data types and unless I have missed something, we have the integer and FP types covered. I have not addressed MMX or XMM yet.
Perhaps a QUAD type could be done in macros as it matches QWORD with no problems but I do not see any advantage in complicating the existing generic asm data types with a multitude of equates as you have in C/C++.
The other problem is that assembler data types are always SIZE related where concepts like INT, SHORT, FLOAT etc .... are dependent on the OS architecture, something that assembler is free from assuming.
With integer data sizes, I have seen the distinction between signed and unsigned but I saw over time that it caused more problems than it fixed.
I am inclined to leave these distinctions to the programmer on a normal needs basis and not implement them in the current system.
Regards,
hutch@movsd.com
Thanks for your feedback, I have already implemented the ones above in the upgraded Prostart I posted a few days ago but I am interested in what the other data types would be.
The design of MASM32 was built around generic ASM data types and unless I have missed something, we have the integer and FP types covered. I have not addressed MMX or XMM yet.
Perhaps a QUAD type could be done in macros as it matches QWORD with no problems but I do not see any advantage in complicating the existing generic asm data types with a multitude of equates as you have in C/C++.
The other problem is that assembler data types are always SIZE related where concepts like INT, SHORT, FLOAT etc .... are dependent on the OS architecture, something that assembler is free from assuming.
With integer data sizes, I have seen the distinction between signed and unsigned but I saw over time that it caused more problems than it fixed.
I am inclined to leave these distinctions to the programmer on a normal needs basis and not implement them in the current system.
Regards,
hutch@movsd.com