Hi Tomasz,
let's do this again,
a = 10.125
b = 2; integer
c = 5 ;integer
d = c / b * a

Now, your parsing c and b, which are integers, but you get to a and it is a float, so now the whole expression will now evaluate to a float, and c / b will be converted to floats (using fild or whatever) and so d will now be a float. follow? If one variable is a float, then the whole expression will evaluate to a float, and integers get converted (temporarly) to float also, so the whole expression will work now (c and b will still be integers).

Now you've done all of the above, and now you have a float value for d, it is stored internally by fasmw using maximum precision of a 10byte value. Now d is used in the code, mov eax, d... so now you convert the 10byte float to a dword float and store the value at the correct place in the assembly.

forget what I said about "are going to be replaced with the text equivalent", that would be a waste of time doing it that way.

And finally, if this just isn't going to be possible without much trouble and/or breaking a lot of other things in fasm then I guess we can stop right here. What I really wanted to know was how hard would it be and would you have to change a lot of other things too.

I'll have another look at the macros suggested above also.
MadMatt

This would need a separate type of constants for the floats - in fact this would need to make HLL-like typing of the assembler symbols. Otherwise assembler wouldn't be able to remember that "a" was defined as a float value, not talking about storing it internally in different format.

However when I write "a = dword 1.0" I just want the single precision floating point value and so I get it, fitting in 32 bits, and on those 32 bits I can then do any operations (including logical ones). Any typing mechanism you propose would break it. Since this is the assembler, not HLL, it should be clear why I see no other solution than separating the operators - just like there are separated instructions for the integer and floating point operations in machine language.

Hehe, this would be a mess:
madmatt: you are wanting FASM to store extra information about the constants to indicate whether it is integer, SP or DP. Right now FASM only "remembers" the basic 64 bits after conversion of SP or DP. This is why without changes to the storage format FASM cannot "know" what a number like 0x123456789abcdef is supposed to be.

If we allow FASM to remember the type then what do we do here: What should FASM do? Convert 'a' to integer before doing xor? Keep 'a' in float format and convert 0x80000000 to float before doing the xor? Do not convert anything and do the xor? And for any option then what type is 'b' to become?

I don't know how the internals of fasmw works, so if you say that it couldn't be done easily without major modifications then i"ll have to use other methods. Fortunately I wouldn't use this feature too often, but on a few occasions it would've been sure nice to have. Thanks for taking the time to answer this question.
MadMatt

The point here is not that it couldn't be done or that it would be too much work. My point is - as usually when considering some extensions to fasm syntax - to keep the overall clear and simple. Typing is not simple, and there are many places where the behavior would be the choice of language, not just the logical consequence of basic rules. I prefer to keep the minimum set of rules and everything else as simple effects of those rules. And also, as revolution noted, in assembly we should be able to do everything with the binary values we define (the macros I propose work because of it), and any type-conversion etc. would be only the obstacle on the way.