flat assembler
Message board for the users of flat assembler.
Index
> Compiler Internals > db 0. A bug or not a bug? Goto page Previous 1, 2, 3, 4 
Author 

Tomasz Grysztar
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
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
l_inc wrote: How exactly is then db not $80 calculated, so that the resulting $FF...FF7F still fits into [256 to 255] ? Code: value = not 80h if value<0 db value ; 129, since value = 129 end if 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. 

07 Dec 2014, 22:38 

l_inc
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
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. 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. l_inc wrote:
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
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
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
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
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
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
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
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
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 

Goto page Previous 1, 2, 3, 4 < Last Thread  Next Thread > 
Forum Rules:

Copyright © 19992020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.
Website powered by rwasa.