FPU instructions ...
Real numbers declarations examples:
[Real1: R§ 65478 Real2: 0.628 Real3: 0.11123E-12]
'R$' size definition is nothing but Qword. It allows you to declare '55478' as an integer stored real (instead of more procedural syntax like: '65478.0' or 'Q$ r65478', for example).
>>>>>>>>>>> Real numbers must be expressed in Decimal ASCII . <<<<<<<<<
For composed number (ex: F$ 12-3) and multiple negative numbers, apply the same rules as for code numbers. This is to say that the parser strips any space before a +/- sign and that you have to either specify a comma or to precede your signed number by a zero:
[Real1: R§ 0-65478, -12 0+24] ; Either ',' or '0' to prevent Parser space stripping.
Here too, I recommend the leading zero version as the preferred cleaner one.
Available size specifiers for Data declarations are:
- F$ > Real 4 (32 bits) - Same size as D$ -
- R$ > Real 8 (64 bits) - Same size as Q$ -
- T$ > Real 10 (80 bits)
For Code Reals-immediates, syntax is, for example:
push F§0.01
mov eax F§45
... a bit out of logic but, on one hand, much simpler for the compiler than having to check ALL immediates to know if they are Reals or Integers and, on the other hand, simpler for the user than having to memorize a syntax convention different from the Data/Mem syntax convention.
Clean clear writing should avoid immediate Real in code Statements and Equates, and should use Data. If you feel you need this feature, you have review the FPU design.
Math processor instructions have some specifics:
FPU registers are noted ST0, ST1, ..., ST7 (without parenthesis)
ST, instead of ST0, does NOT exist.
In most instructions that require a register as parameter, you can omit it if you mean the usual one. for example, all following statements are good and equivalent:
FDIV | FDIV ST1 | FDIV ST0 ST1
or:
FDIV ST2 | FDIV ST0 ST2
this is to say that, if a register is required and you do not specify any, it is supposed to be ST1 as source register (ST0 as destination, of course). This is a bad feature. You should avoid this, and conform to the NASM standard, which is to never assume any register. Your source will be more readable, and easier to debug and maintain, if you always specify all the registers.
Some FPU instructions need particular pre-defined memory areas:
FSAVE >>> 108 bytes mem
FLDENV >>> 28 bytes mem
FRSTOR >>> 180 bytes mem
FSTENV >>> 28 bytes mem
I previously chose to NOT assume these formats and to refer to them as dWords. From V.2.07 on, I introduce ''X$'' notation to resolve all these weird cases (and others in future), at once, in code:
In Data, just set the desired room. Example:
[FPU_State: B§ 0 #108]
fsave X§FPU_State
In all others cases when FPU instructions have a memory parameter, RosAsm fully controls fitting sizes.
~~~~~~~