Author 
Thread 


Tomasz Grysztar
Assembly Artist
Joined: 16 Jun 2003
Posts: 6179
Location: Kraków, Poland

l_inc wrote: 
The question arises from the normal expectation to behave multiplication with 2 and left shift by 1 the same way.


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 64bit composite range is the guaranteed one (that is, from 2^63 up to 2^641).

04 Mar 2012, 17:39 

Tomasz Grysztar
Assembly Artist
Joined: 16 Jun 2003
Posts: 6179
Location: Kraków, Poland

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 tradeoff 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.

07 Dec 2014, 19:20 

l_inc
Joined: 23 Oct 2009
Posts: 867

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).
Quote: 
and this way it avoided problems with overflowing NOT without adding additional complexities to how the expressions are evaluated


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.
_________________ Faith is a superposition of knowledge and fallacy

07 Dec 2014, 22:27 

Tomasz Grysztar
Assembly Artist
Joined: 16 Jun 2003
Posts: 6179
Location: Kraków, Poland

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


Exactly like fasm calculates it now:
Code: 
value = not 80h
if value<0
db value ; 129, since value = 129
end if


As the fasm's manual states, the numeric operations "are usually processed as if they operated on infinite precision 2adic numbers". If you negate an infinitely zeroextended number, you get a number extended with an infinite sequence of ones (that is: a negative number). Thus "not 80h" equals 81h.
l_inc wrote: 
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.


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 notsobizarre sources would not longer assemble.

07 Dec 2014, 22:38 

l_inc
Joined: 23 Oct 2009
Posts: 867

Tomasz Grysztar
Quote: 
the numeric operations "are usually processed as if they operated on infinite precision 2adic numbers"


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 padic numbers apply here.
Quote: 
Thus "not 80h" equals 81h


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.
Quote: 
If I chose this variant, it would get more noticed


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.
_________________ Faith is a superposition of knowledge and fallacy
Last edited by l_inc on 07 Dec 2014, 23:44; edited 1 time in total

07 Dec 2014, 23:29 

Tomasz Grysztar
Assembly Artist
Joined: 16 Jun 2003
Posts: 6179
Location: Kraków, Poland

l_inc wrote: 
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 padic numbers apply here.


The fasm's tutorial that I never finished was starting with explanation of how the 2adic 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.
l_inc wrote: 
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.


Yes, this is exactly what it does mean to allow extended range like TASM does, and this is what I meant by a "tradeoff". You could assemble "db 129" with TASM (but not "db 257").
l_inc wrote: 
Quote: 
If I chose this variant, it would get more noticed


That's actually an argument. But noticing that something that compiled before does not compile now is much better then 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.


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 TASMlike 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.

07 Dec 2014, 23:43 

l_inc
Joined: 23 Oct 2009
Posts: 867

Tomasz Grysztar
Did you decide to leave shr context dependent, so that (2) shr 1 equals 127 rather than 1?
_________________ Faith is a superposition of knowledge and fallacy

08 Dec 2014, 21:37 

Tomasz Grysztar
Assembly Artist
Joined: 16 Jun 2003
Posts: 6179
Location: Kraków, Poland

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...

08 Dec 2014, 21:48 

l_inc
Joined: 23 Oct 2009
Posts: 867

Tomasz Grysztar
Oh, sorry. I just downloaded the new version, but forgot to unpack it into the old location.
_________________ Faith is a superposition of knowledge and fallacy

08 Dec 2014, 21:56 

l_inc
Joined: 23 Oct 2009
Posts: 867

Tomasz Grysztar
The change has also affected this behaviour. The 64bit size context should no longer apply for all the numeric calculations passed to the control directives, right?
_________________ Faith is a superposition of knowledge and fallacy

12 Dec 2014, 23:00 

Tomasz Grysztar
Assembly Artist
Joined: 16 Jun 2003
Posts: 6179
Location: Kraków, Poland

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.

12 Dec 2014, 23:07 

l_inc
Joined: 23 Oct 2009
Posts: 867

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.
_________________ Faith is a superposition of knowledge and fallacy

23 Dec 2014, 20:35 

l_inc
Joined: 23 Oct 2009
Posts: 867

Tomasz Grysztar
l_inc wrote: 
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 padic numbers apply here.


I'd like to resurrect this discussion. 2adic numbers in the sentence (" calculations are usually processed as if they operated on infinite precision 2adic 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 2adic numbers.
Q: In what way do the properties of 2adic numbers differ from, say, plain integers?
A: Well, 2adic numbers have higher cardinality and therefore extend integers. The set of integers is actually a subset of 2adic integers, which are a subset of rationals, which are in turn a subset of 2adic numbers.
Q: But fasm calculates with integers only. Are there other differences?
A: Well, yes. 2adic 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 2adic absolute values or 2adic 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 3adic numbers?
A: Integers are a subset of any set of padic numbers (and padic integers), whatever p is chosen.
Q: So you mean that in the fasm context the difference between padic numbers and integers is only representational?
A: Yes.
Q: Should the user then specify numbers in the 2adic 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 2adic 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 32bit 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 2adic numbers is to say the arithmetic is traditional (not modular), in which case it doesn't make any difference whether to call them 2adic, 3adic or 87049adic, 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 2adic numbers only?
_________________ Faith is a superposition of knowledge and fallacy

03 Mar 2016, 16:53 

l_inc
Joined: 23 Oct 2009
Posts: 867

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 representationagnostic, then talking about 2adic numbers indeed refers to 2adic 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.
_________________ Faith is a superposition of knowledge and fallacy

03 Mar 2016, 17:15 



Forum Rules:
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum






Powered by phpBB © 20012005 phpBB Group.
