flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Compiler Internals > db 0. A bug or not a bug?

Goto page 1, 2, 3, 4  Next
Author
Thread Post new topic Reply to topic
l_inc



Joined: 23 Oct 2009
Posts: 867
db 0. A bug or not a bug?
Good day. I'd like to ask, if there is any reason to report an error on the following code:

Code:
org 100h
db ($+1and not 1 - $


It seems to be nothing more, than db 0. But fasm reports "error: value out of range".
Post 04 Jan 2012, 14:29
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3415
Location: Bulgaria
It seems to be a bug. dw and dd works properly.
Also, the following workaround works:

Code:

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


Post 04 Jan 2012, 14:39
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 867
JohnFound

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


They won't work properly if you try them with org 10000h and org 100000000h correspondingly. Thus the issue is related not only to db.
Post 04 Jan 2012, 14:45
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6179
Location: Kraków, Poland
In 8-bit calculation context provided by DB directive "not 1" equals to 0FEh, so (101h and not 1) - 100h = 1 - 100h = -0FFh, which is outside the byte range.

Read in the other thread my detailed explanation of how expressions are calculated and why some operations are context-dependent.
Post 04 Jan 2012, 19:40
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 867
Tomasz Grysztar
I think, your approach to differentiate operations, where the 8-bit context shall be applied and where not, just adds a set of (not documented) rules to be additionally kept in mind by the programmer instead of simplifying the programming process. Therefore it seems to me a bad design decision.

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


That's not quite right.
(101h and not 1) - 100h = 0 - 100h = -100h

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


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 (($+1and not 1 - $) / 2 + 80h

Post 04 Jan 2012, 21:12
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6179
Location: Kraków, Poland

l_inc wrote:

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 (($+1and not 1 - $) / 2 + 80h


You are right, that statement is true only for a simple single-operation expressions and not in case when the result is used for further calculations, as in your example.

Nevertheless, this "special treating" was added to follow the usual expectations of programmers - 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 thing is, the simple expressions for byte values (and other usual sizes) should work the same regardless whether assembler uses 33-bit, 64-bit, 65-bit or 129-bit values internally - this approach ensures that you do not need to know what is the size of values that assembler operates on in order to deduce what the result of your expression will be, instead it just follows naturally from the context of your expression (well, at least if there is enough context - when no size hint is provided, fasm uses default "qword" size for numerical expressions).

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.
Post 04 Jan 2012, 22:18
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 867
Tomasz Grysztar

Quote:
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


Well, now you have one more thread with the opposite behaviour reported to be a bug. Smile

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


Do you think, it's good to restrict the adequate behaviour only to the simple expressions? My experience says me, that normally much more problems arise from complicated expressions. For example, a syntactically simple expression can be preprocessed into something, what is not enough simple to get assembled in an expected way.

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.


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


129 bit would be nice. I actually already wanted to ask, if you were planning this in future releases.
Post 04 Jan 2012, 23:03
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6179
Location: Kraków, Poland

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

Even the check-less truncation method would not ensure the kind of consistency that I mentioned. 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.

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.


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

I certainly planned it for fasm 2. As for 1.x line, I'm not sure.
Post 04 Jan 2012, 23:31
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 867
Tomasz Grysztar

Quote:
and should not really need to know


Here I absolutely disagree. This is just not possible to hide this information from the programmer in a convenient way, because he's highly dependent on it. I was always relying on the knowledge of 64 bit arithmetic in fasm, and even did not really notice, that I got this knowledge empirically.

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.

Anyway, thank you for your explanation.
Post 04 Jan 2012, 23:57
View user's profile Send private message Reply with quote
aq83326



Joined: 25 Jun 2011
Posts: 21

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


I agree with this.
Post 05 Jan 2012, 07:43
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6179
Location: Kraków, Poland

l_inc wrote:

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.

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 (like with DQ directive), as this is very important for floating point values, too.
But this is a part of language specification that does not necessarily have to reflect the internal details of implementation (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).
Post 05 Jan 2012, 11:05
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4641
Location: Argentina

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?
Post 05 Jan 2012, 14:15
View user's profile Send private message Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 867
Tomasz Grysztar

Quote:
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


If you document = and db/dw/dd with all of the accompanying special cases like not, then I see no sense to change your arithmetic word size in the future (also internally). You either make no changes to the arithmetic, or you change it internally and logically, and you also document the changes, so that the programmers are aware of possible behaviour differences in their programs. In any case you don't have to be concerned about "the kind of consistency you mentioned":

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

Post 09 Jan 2012, 11:30
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6179
Location: Kraków, Poland
I prefer language specification that is less dependent on implementation details. For the common usage scenarios you can then expect some result without knowing anything at all about the internals of specific implementation you are using, while it is still possible to improve the implementation for specific scenarios when needed.
Post 09 Jan 2012, 12:38
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 867
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. If you provide a documented 64 bit arithmetic, it does not make sense to work with 129 bits internally, and it's also not possible to use only 33 bits internally to store 64 documented bits.

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).
Post 09 Jan 2012, 19:57
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6179
Location: Kraków, Poland

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

There is no such thing as "logical" word size there, there is just default size assumed when you do not provide size prefix in numerical constant definition, it does not really need to reflect the maximum possible size, for example if I allowed to define TBYTE numerical constant for purpose of floating point values, it would be required to prefix it with "tbyte" keyword, while default still would be "qword".


l_inc wrote:
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.
Post 09 Jan 2012, 20:16
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 867
Tomasz Grysztar

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


The point is not to find a good (my word was actually "best"), but at least a better solution. But fine. You won (let's disregard, who's the final decision right holder, and pretend I also had some chances to win the discussion). Smile
Post 09 Jan 2012, 21:02
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6179
Location: Kraków, Poland

LocoDelAssembly wrote:

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?

To get it done properly, the changes would be so extensive that I really feel overwhelmed every time I think about it. This is one of the terrible weaknesses of 1.x architecture that made me think about starting fasm 2 from scratch (the other thing being fasm 1.x terrible legacy memory management inherited from DOS times when it was possible to just use all available RAM for oneself).
Post 10 Jan 2012, 11:50
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6179
Location: Kraków, Poland
OK, after all I managed to overcome my concerns and I started working on it (I mean adding the additional sign bit to internal calculations).

I have already adapted the expression calculator's core (it has plenty of reserved space in its data structures, so it was easy there) and the most of its proxy interfaces (additional proxy variable had to be introduced, so that the 65-th bit of the value can be returned to the caller).
I also partially implemented the support for additional sign bit in the symbols management (here I used one of the reserved bits in the flags field of symbol structure), but it does not work with all the kinds of labels yet.
And there will be still a lot of work in directive handlers, I need to find a place for additional bit in the "virtual" block data structure (I found my dusty old notebook with fasm development notes and I'm peeking into it now - it seems that I can punch even a few more bits in there, even though structure is tightly packed already).

So - still a lot of work to get it done, but I think that I am able to finish it (I'm not sure how much time it is going to take, though).
If I succeed I may leave 1.69.40 as a stable release and start the 1.69.41.x development line for the purposes of testing fasm's core after these revisions.
Post 27 Feb 2012, 21:32
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4641
Location: Argentina
I'm glad to know about your progress on this, and also that you are planning to use a development branch again.
Post 27 Feb 2012, 22:29
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2, 3, 4  Next

< Last Thread | Next Thread >

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 © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.