Would it be possible to add floating point calculations?
something like this:


and / or



or does this feature already exist, and I just haven't read the manual good enough yet.

If you read the FPU section in the documentation [page 36 in my version], fldpi will load PI into the register stack for you so you don't have to declare it, you then use FPU operands (fadd,fsub,fmul,fdiv etc) on registers st0 - st7 to perform all normal operations.

HTH

Yeh, I know that stuff already. But In many cases it would be easier to use equates, like when you need to change a value, you won't have to go though all your code and change every occurance of that value.
thanks anyways for your help.

i usually precompute it myself ("calc.exe"), and define it as constant, with equate in comment so i can easily recompute (of course there are dependancy issues, but they are problems only in som extreme cases)

Hi,
maybe this will help you: http://board.flatassembler.net/topic.php?t=3947

Vid:
Most of the time I do this too. In some case though It would be nice to define an equation and use a standard macro to calculate the value.
an example of the c snip that caused me to ask this question:

Id like to be able to do the same with FASM and a macro define

Polygon7:
Those macro's might work, but It would be better to have this as a standard feature for a future release of FASM. I don't think this would be much harder to implement than FASMs integer parser/calculator. I'll try the macro's and see if they will work for me. thanks.

madmatt: you would end up having both whole-number constants (including labels) and floating constant, which wouldn't be distinguishable, so it will be just mess.

naaa, these caculations would be all done internally and only the final result would be actual data:
mov eax, D3DXToRadian degree
OR
myvalue dd D3DXToRadian degree

anyways, If this would be to much trouble, I'll just find some work arounds. Just thought I would ask anyways

ah, so you are talking about inline-macros, sorry, i didn't read carefully. I wanted to say that FASM doesn't allow FP calculations, so even 4.0/2.0 wouldn't work.

Maybe in the next version of fasm Tomasz would look into adding this feature?

i think not, it will cause mess with whole number constants. or you would allow somehting like "label jozo at 4.5"?

I don't think it would be too much trouble to find the difference between a float and an integer. And where only an integer would be allowed and a fp number. Your example above would be flaged as an error in fasm, only floats would be allowed to be defined with equ, =, macro, data definitions, and direct loading of registers, (mov eax, 1.5). I think that covers about everything.

The operations performed by fasm are the integer operations, and thus:

always means an integer operation, even if you defined alpha with a floating point value, since it is anyway stored as a binary representation, and then the integer operations are performed on this binary form. Thus this works the same as:

and in this case it's even more obvious that the operation is performed on binary.

To enable the floating point operations, they would have to be distinguished from the integer operations, and this means the floating point multiplication would have to get some other symbol than just the "*" like integer multiplication - in the same way like the floating point and integer arithmetics have separate instruction sets.

Maybe this? and simillarly we could have ++, --, //

But on what fp precision would it operate? You can define constants of various precisions, like:

Would it needs separate operators for each precision, too? Is this feature worth such mess at all? That's why I suggested the macro solution - at least it's clear what's going on there.

Okay, good point. The messyness factor might be an issue, but it is possble

revolution:
or how about beta == alpha * 2
everything behind the '==' would be float, or get converted to floats.

tomasz:
as far as size, use the best percision available, and scale down too what ever the data element needs, like dd beta, or dq beta, or mov eax, beta, etc.

The size becomes a problem like Tomasz Grysztar mentioned. The problem is how to distinguish between a float constant and an integer constant. eg. what is 0x12345678? Is it decimal 305419896, single precision 5.690457e-28 or double precision 1.588974781700064e-315?

Hello Revolution,
Require floats to have a decimal point in them, or else it gets treated like an integer. All the values calclulated are going to be replaced withe the text equivalent, so the type of instruction and/or data define would determine the size, all internal fasmw calculations would be done using the highest precision possible (tword).
MadMatt

Consider this:

Do you see what I mean? At least right now this sample doesn't cause any problems, since the * and + always mean the integer calculations in fasm, and when you know this it's simple to predict what the above definition will do.

And what do you mean by "are going to be replaced with the text equivalent"? In fasm it doesn't work this way; preprocessor works on text, assembler works on binary values.