org 100h
db ($+1) and not 1 - $    

org 100h
A= ($+1) and not 1 - $
db A
    

It seems to be a bug. dw and dd works properly.

so (101h and not 1) - 100h = 1 - 100h = -0FFh

And it never happens that some expression that would be allowed anyway gives a different result.

org 100h
db (($+1) and not 1 - $) / 2 + 80h    

Do I understand it right, that according to my example this statement is not correct? Considering the following example the value expected to be without special treatment of not is 80h. But the really compiled value is 0.

Code:

org 100h
db (($+1) and not 1 - $) / 2 + 80h    

as you can see in the other thread, the overflowing "db (-1) shr 1" was reported as bug, and so would be "db not 80h" if it was overflowing

the simple expressions for byte values (and other usual sizes) should work the same regardless

This way even if the future fasm calculates on 129-bit values, it will give you the same results for byte, word or dword expressions, as it does now.

Anyway a consistent behaviour (e.g., always calculate in 64 bit and then truncate to 8 bit without reporting an error) is always better, than embedding special cases.

129 bit would be nice. I actually already wanted to ask, if you were planning this in future releases.

and should not really need to know

x = 1 shl 32
dd x/2    

And when one writes something like "mov eax,(not 1)/5", the most usual expectation is that the calculations are done in the same way as if you performed them on the register where you want to put the result - as the programmer does not know (and should not really need to know) how assembler stores the intermediate values of those calculations.

Code:

x = 1 shl 32
dd x/2    

The result will depend on, what word length is used internally by the assembler. Therefore it should always be clearly defined and documented.

(and, in fact, implementation should be at least 65 bits internally, since fasm's qword calculations are flawed currently and do not always behave like their dword, word or byte counterparts).

I agree it should be documented that when no size hint is specified for "=" directive, the value is calculated as it would be for 64-bit context

For example "dd (not 1) shr 37" could in such case give different results depending on whether assembler did calculations on 64-bit or 129-bit values.

I prefer language specification that is less dependent on implementation details.

Tomasz Grysztar

Quote:

I prefer language specification that is less dependent on implementation details.

Me too, but in this case documenting (i.e. including into the language specification) a "logical" word size is as you admitted unavoidable. The "logical" word size does not have to reflect the internal implementation, but it just does not make sense to make it different.

IMHO you add a set of not-really-obvious special treatment rules to achieve a fictitious implementation independence. And providing expected results for common use cases can also be achieved with simple truncation as previously suggested (which is however not claimed to be the best solution).

So, as the truncation is not a good option, I stay with the only other solution that makes results meet the programmer's intention in usual cases.

Tomasz Grysztar wrote:

(and, in fact, implementation should be at least 65 bits internally, since fasm's qword calculations are flawed currently and do not always behave like their dword, word or byte counterparts).

Do you have an estimate of how much work is needed to add the missing bit?