Yes, fasm now guarantees that the results of these two operations are consistent - as it is claimed that result should always be as if it was computed with infinite precision. If because of the limitations of its current implementation fasm is not able to provide that correct result, it signalizes an error - it is similar situation to the "code cannot be generated" error, which may happen when assembler is not able to produce correct code even though the correct solution may nevertheless exist. Thus this error is a "failsafe" mechanism, by which fasm guarantees that as long as you get the result, it is correct according to the specification.

Of course this would not be very useful if it was not guaranteed to always work at least on the numbers in standard ranges. As the maximum size where you can put the result right now is QWORD, the 64-bit composite range is the guaranteed one (that is, from -2^63 up to 2^64-1).

I've been thinking again about the issue that started this thread, and now I think that while defining the expression results to be independent from the internal precision of fasm's implementation was a right choice, it was not really a good move to make select operations (namely NOT and XOR with negative number) depend on the "context size" and whether the arguments fit into range. I should have looked back at TASM again, because from current perspective I think what it did was a better trade-off than mine. It allowed values to fit into extended negative range, for example DB allowed values in range from -256 to 255, and this way it avoided problems with overflowing NOT without adding additional complexities to how the expressions are evaluated.

Should I tweak it once again, though? I don't know. But it wouldn't really be that much of a compatibility break, while it would clean up these few peculiarities. I could try it in a development release to see how users would react.

Tomasz Grysztar
For the standard bit lengths of kind 2^n (where n belongs to {3, 4, ...}), which are used for data definition, the concept of composite ranges seems to me more appropriate. As for the numbers with bit lengths of kind 2^n+1, which you use in the algebraic calculations, the signed integer ranges seem to be more appropriate (because that +1 is actually meant for the sign).

How exactly is then db not $80 calculated, so that the resulting $FF...FF7F still fits into [-256 to 255] ?

P.S. As for me it's not that big of an issue to require a programmer to explicitly truncate the result: db not $80 and $FF . The requirement is not quite convenient, but it fits into the intuitive notion very well.

Exactly like fasm calculates it now:
As the fasm's manual states, the numeric operations "are usually processed as if they operated on infinite precision 2-adic numbers". If you negate an infinitely zero-extended number, you get a number extended with an infinite sequence of ones (that is: a negative number). Thus "not 80h" equals -81h.

Yes, that's another option. And, to be honest, I don't have any good arguments against it. If stated this way: "db 0FFh and not 80h" it even sounds like a nice logical sentence. If I chose this variant, it would get more noticed, though - because some not-so-bizarre sources would not longer assemble.

Tomasz Grysztar

I read this sentence so many times and every time went again and again to the wiki. I know about your mathematical background and therefore every time try to convince myself that it should make some sense, but it still doesn't. I can't understand how the properties of the p-adic numbers apply here.

I agree with that, but -81h does not equal 81h, which is what you demonstrate in the listing (if you want "not 80h" to compile as 129). So, I'm not sure how to understand the listing, but from the cited statement I assume, you just want to truncate the negative number and completely disregard that the result would not have the sign bit set. I.e. if one does "db -129" and then loads the data with movsx, the result would be inconsistent.


That's actually an argument. But noticing that something that compiled before does not compile now is much better than not noticing that something that compiled before now compiles differently. Not sure if the latter would be the case to a greater extent for one or another decision though.

The fasm's tutorial that I never finished was starting with explanation of how the 2-adic arithmetic relates to computing. I have never really read again what I wrote there, but from a few positive comments I received over the ten years I presume that it is not all that bad.

Yes, this is exactly what it does mean to allow extended range like TASM does, and this is what I meant by a "trade-off". You could assemble "db -129" with TASM (but not "db -257").

If something compiles differently, it is going to be an effect of removing special treatment of some operators depending on size context. The range checking will only have an effect of triggering an error or not.

Let me start it slow - first I will remove the incosistent treatment of some operators while loosening the range checks to TASM-like ones to ease the transition. Later I may bring back current range checks. And I think I like to emphasize fasm's ideological connection to its TASM roots, with a small details like this one.

Tomasz Grysztar
Did you decide to leave shr context dependent, so that (-2) shr 1 equals 127 rather than -1?

No, I did not leave the context dependence there either, so SHR is now always as an arbitrary precision one, thus it is always an equivalent of x86 SAR instruction.

PS Assembling "db (-2) shr 1" to $ff is - again - exactly what TASM did...

Tomasz Grysztar
Oh, sorry. I just downloaded the new version, but forgot to unpack it into the old location.

Tomasz Grysztar
The change has also affected this behaviour. The 64-bit size context should no longer apply for all the numeric calculations passed to the control directives, right?

Yes, the expressions now always give the same result, not depending on size context (I consider it to be the main advantage of the recent changes). The only case where the size context should still affect the result is the floating point number.

Tomasz Grysztar
The floating point numbers do not seem to be documented well enough. I can see that x = qword 1.0, x = dword 1.0 and x = word 1.0 all assign different values, but I didn't find any mentionings of double/single/half precision formats used. Nor there's anything about the possibility of size context specification.

Tomasz Grysztar

I'd like to resurrect this discussion. 2-adic numbers in the sentence ("calculations are usually processed as if they operated on infinite precision 2-adic numbers") did not make sense to me, but after reading the tutorial you linked I think in fasm context they generally do not make sense. And I think the problem here is the lack of differentiation between number properties (semantics) and number representation (syntax).

Q: So what actually is the bold sentence supposed to state?
A: That the properties of numbers reflected by fasm calculations should resemble properties of 2-adic numbers.
Q: In what way do the properties of 2-adic numbers differ from, say, plain integers?
A: Well, 2-adic numbers have higher cardinality and therefore extend integers. The set of integers is actually a subset of 2-adic integers, which are a subset of rationals, which are in turn a subset of 2-adic numbers.
Q: But fasm calculates with integers only. Are there other differences?
A: Well, yes. 2-adic numbers define the metric differently. Larger powers of 2 have lower absolute values than smaller powers of 2.
Q: But there's no operator in fasm to find 2-adic absolute values or 2-adic distances. How does this affect the basic arithmetic operations fasm supports?
A: It doesn't.
Q: Would it functionally change anything if the bold sentence was referring to 3-adic numbers?
A: Integers are a subset of any set of p-adic numbers (and p-adic integers), whatever p is chosen.
Q: So you mean that in the fasm context the difference between p-adic numbers and integers is only representational?
A: Yes.
Q: Should the user then specify numbers in the 2-adic representation when calculating with fasm?
A: No. You specify numbers in a typical binary, octal, decimal or hexadecimal integer representation.
Q: Does it make any sense then to talk about 2-adic numbers if the only difference is representational and the user doesn't even see it?

So I come to the conclusion that the bold sentence provides zero information about the features of fasm calculations and facilitates nothing but confusion. It's like saying that fasm calculations are done as if they were operating on complex numbers. But as long as fasm supports integer calculations only, this gives no better idea than saying that it operates on integers, but at the same time leads to confusion. It would be totally different to say that fasm operates on 32-bit integers with modular artihmetic (which is obviously wrong, but would at least make sense), because this has direct implications on the arithmetic like 2147483647 + 1 = -2147483648 (in case of the least absolute remainder definition). In case the only purpose of mentioning 2-adic numbers is to say the arithmetic is traditional (not modular), in which case it doesn't make any difference whether to call them 2-adic, 3-adic or 87049-adic, then it's totally enough to formulate it like: "The arithmetical and bit–logical calculations are performed with integers of unspecified length, and assembler signalizes an overflow error if because of its limitations it is not able to perform the required calculation". Or do I just miss some property inherent to 2-adic numbers only?

Tomasz Grysztar
OK. I've probably just got it. If you define bitwise operations as operations on binary representations, which you didn't do explicitly and which should not necessarily be done this way, because the operations are actually representation-agnostic, then talking about 2-adic numbers indeed refers to 2-adic representations of the integers. But this is then equivalent to simply referring to binary representations having infinite width. So I find the bold statement bad formulated. A good description of the bitwise operations needs a more elaborated definition for them.