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 > 1.71.50 bug?

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
randall



Joined: 03 Dec 2011
Posts: 149
Location: Poland
1.71.50 bug?
var dd 0,0

; ...

Below line fails to compile (invalid operand size). It worked fine in previous fasm versions.

vcvtsi2sd xmm0,xmm0,[var]

To workaround this issue I have to use:

vcvtsi2sd xmm0,xmm0,dword[var]

_________________
https://github.com/michal-z
Post 06 Feb 2016, 22:12
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
Can you show the complete source that causes the bug to show up? When you define label with "var dd 0,0" there should be no difference between "[var]" and "dword[var]" constructions.
Post 08 Feb 2016, 15:22
View user's profile Send private message Visit poster's website Reply with quote
randall



Joined: 03 Dec 2011
Posts: 149
Location: Poland

Tomasz Grysztar wrote:
Can you show the complete source that causes the bug to show up? When you define label with "var dd 0,0" there should be no difference between "[var]" and "dword[var]" constructions.



https://github.com/michal-z/asmart/blob/master/amnestia/amnestia_audio.inc

Line 137

_________________
https://github.com/michal-z
Post 08 Feb 2016, 16:39
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
Thank you! This helped me find the bug. Please try 1.71.51.
Post 08 Feb 2016, 17:18
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 867
Seems like another non-recoverable error at the wrong place. Minimal reproducible:

Code:
vcvtsi2sd xmm0,xmm0,[var]
var dd 0,0



P.S. Rather seems like I'm too late. Smile

_________________
Faith is a superposition of knowledge and fallacy
Post 08 Feb 2016, 17:19
View user's profile Send private message Reply with quote
randall



Joined: 03 Dec 2011
Posts: 149
Location: Poland

Tomasz Grysztar wrote:
Thank you! This helped me find the bug. Please try 1.71.51.



Now it works fine. Thank you.

_________________
https://github.com/michal-z
Post 08 Feb 2016, 17:38
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:
Seems like another non-recoverable error at the wrong place.

It is worth mentioning here that my rationale for having non-recoverable errors in fasm 1 was not well-founded. In fasm g I have no errors that are not recoverable other than running out of memory or hitting the limit of allowed passes (for example "illegal instruction" error must be recoverable, because it may be a forward-referenced macroinstruction) and so far I have never had any trouble with it. I think I overestimated the potential problems when I decided that only some of the assembly-stage errors may be recoverable in fasm 1.
Post 08 Feb 2016, 17: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

Quote:
In fasm g I have no errors that are not recoverable other than running out of memory or hitting the limit of allowed passes


OK. It seems the err-directive also generates a recoverable error. And the difference to assert is only about what kind of an argument it takes.

_________________
Faith is a superposition of knowledge and fallacy
Post 08 Feb 2016, 17:53
View user's profile Send private message Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 867
Tomasz Grysztar
I think though, there are cases when the irrecoverable err is indispensable. Like this one, which is about debugging. I even wrote a little macro for that:

Code:
;allows to debug long running loops
;usage: mLimitLoops $100000
macro mLimitLoops limit=$100000
{
        macro while args&
        \{
                while args
                        if % > limit
                                display 'Error: too many iterations',13,10
                                err
                        end if
        \}
        macro repeat args&
        \{
                repeat args
                        if % > limit
                                display 'Error: too many iterations',13,10
                                err
                        end if
        \}
}


This macro wouldn't be of much help for debugging source code for fasmg.

_________________
Faith is a superposition of knowledge and fallacy
Post 08 Feb 2016, 21:59
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6179
Location: Kraków, Poland
You could adjust the macro to simply break out of the loop instead:

Code:
macro mLimitLoops limit=$100000
        macro while?! args&
                while args
                        if % > limit
                                err 'too many iterations'
                                break
                        end if
        end macro
        macro repeat?! args&
                repeat args
                        if % > limit
                                err 'too many iterations'
                                break
                        end if
        end macro
end macro


mLimitLoops 1000

while a = 0

end while

a = 0

The above sample shows the "too many iterations" error correctly, and when you change "a = 0" to "a = 1" it is going to assemble without an error - something that the variant with unrecoverable error would not allow.
Post 08 Feb 2016, 22:30
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:
The above sample shows the "too many iterations" error correctly,


Well, in this simple example yes, but in a larger code with many loops it's still gonna continue to execute other loops to the specified limit, and then do more passes and possibly even end up with "code cannot be generated".

Quote:
and when you change "a = 0" to "a = 1" it is going to assemble without an error - something that the variant with unrecoverable error would not allow


The purpose of the macro is debugging of compiler hanging. It's not meant be used in a code that correctly compiles.

_________________
Faith is a superposition of knowledge and fallacy
Post 08 Feb 2016, 22:39
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:
The above sample shows the "too many iterations" error correctly,


Well, in this simple example yes, but in a larger code with many loops it's still gonna continue to execute other loops to the specified limit, and then do more passes and possibly even end up with "code cannot be generated".

Yes, and this is what meant when I mentioned that I overestimated the potential problems caused by such approach - because my thinking was the same as yours and I really expected such things to happen in case of more complex sources. But the more I play with this new engine the more I see that it actually not as frequent as I imagined. While at the same time this improved ability of the assembler to jump over complex obstacles and still find a solution is a nice continuation of the fasm's ideals.


l_inc wrote:
The purpose of the macro is debugging of compiler hanging. It's not meant be used in a code that correctly compiles.

Still, if the assembler aborts at a later pass, when many of the values are better known, you may get a more informative debugging (especially considering what I noticed: that it is easy to forget oneself and create complex web of cross-references when writing for fasm g - just because you can). And in this variant such macro may actually help with some regular assembly, too (by skipping over the wrongly predicted long loops).
Post 08 Feb 2016, 22:58
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:
Yes, and this is what meant when I mentioned that I overestimated the potential problems caused by such approach


I understand that many (or even all) of the internal compiler conditions should be recoverable, but I don't feel like it's OK to not provide an interface for the user to generate unrecoverable errors. It's like you completely get rid of the concept of warnings internally, but the user still might be willing to write macros that display warnings in some cases.

Quote:
Still, if the assembler aborts at a later pass, when many of the values are better known, you may get a more informative debugging


I actually see it as less informative. And especially disadvantageous if the compiler somehow would manage to succeed with enforced loop limits, but not without them. The actual desired loop termination conditions would not be satisfied leading to inexpressive "better known" values.

Quote:
And in this variant such macro may actually help with some regular assembly, too (by skipping over the wrongly predicted long loops).


This is sort of black magic programming.

_________________
Faith is a superposition of knowledge and fallacy
Post 08 Feb 2016, 23:15
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:
I actually see it as less informative. And especially disadvantageous if the compiler somehow would manage to succeed with enforced loop limits, but not without them. The actual desired loop termination conditions would not be satisfied leading to inexpressive "better known" values.

As I said above, I am aware of the theoretical "bad case scenarios" and I used to worry about them - as it turns out, way too much. I found that the advantages of this approach outweigh the possible problems.
Post 08 Feb 2016, 23:30
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 I said above, I am aware of the theoretical "bad case scenarios"


My point is that we do not disagree about how rare the bad case scenarios are. We disagree about how to qualify particular scenarios. What you identify as good I call disastrous. Again:

Quote:
And in this variant such macro may actually help with some regular assembly, too (by skipping over the wrongly predicted long loops).


You try to present it as an advantage, but the point was to find the bug that led to long running loops. Not to make the source code somehow magically compile. And the result is that the bug was not found.

_________________
Faith is a superposition of knowledge and fallacy
Post 08 Feb 2016, 23:54
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:
You try to present it as an advantage, but the point was to find the bug that led to long running loops. Not to make the source code somehow magically compile. And the result is that the bug was not found.

The bug was not found because there was no actual bug to find. In a real situation we could actively look for solutions, but as long as we are both discussing hypothetical advantages and hypothetical disadvantages, we may keep this going for long. However I do speak from the experience when I say that I am much more satisfied with the new approach, and even positively surprised with the results.
Post 09 Feb 2016, 08:58
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:
The bug was not found because there was no actual bug to find.


From my point of view if the code induces unacceptably long loops than it is clearly a bug that should not be worked around by an artificial loop count limitation, which may or may not help.

Quote:
as long as we are both discussing hypothetical advantages and hypothetical disadvantages, we may keep this going for long


The example I gave a link to is not hypothetical. And afair it would result in "code cannot be generated" with your modification of the macro.

Quote:
However I do speak from the experience


Yes, but that's a different kind of experience. Your use cases are limited to finding a solution for the source code no matter what. And the use case I'm talking about is debugging. One thing is to not use unrecoverable errors internally and a completely different thing is to not provide a possibility to generate them at all. If I say to the compiler that I want it to stop at this particular point then it's really what I mean, and I prefer to have the possibility to say that.

_________________
Faith is a superposition of knowledge and fallacy
Post 09 Feb 2016, 12:13
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:
Yes, but that's a different kind of experience. Your use cases are limited to finding a solution for the source code no matter what. And the use case I'm talking about is debugging. One thing is to not use unrecoverable errors internally and a completely different thing is to not provide a possibility to generate them at all. If I say to the compiler that I want it to stop at this particular point then it's really what I mean, and I prefer to have the possibility to say that.

If the internal details of resolving process are not exposed to the user (as you argued for in the other thread, and I agreed with you), then one may have trouble defining that "particular point" in a meaningful way. And if you want to debug the assembly process, they you would be better adding some kind of "debug mode" to the assembler itself.
Post 09 Feb 2016, 13:50
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 867
Tomasz Grysztar
Defining a point does not require all the internal details, it requires a convenient user interface. And there cannot be any more meaningful point to stop than at the very moment something clearly goes wrong.

It's not unique to fasm resolution process that you'd be willing to stop the process as early as possible. It's the generally desired fail-fast property. E.g. if you experience heap corruption, you really wanna stop the process at the very moment of the misbehaving write, and not some time later when the heap corruption manifests itself at unrelated locations. It indeed would require you to have much more knowledge of the heap operation internals to find the root cause of the corruption.

_________________
Faith is a superposition of knowledge and fallacy
Post 09 Feb 2016, 14:08
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:
It's not unique to fasm resolution process that you'd be willing to stop the process as early as possible. It's the generally desired fail-fast property. E.g. if you experience heap corruption, you really wanna stop the process at the very moment of the misbehaving write, and not some time later when the heap corruption manifests itself at unrelated locations. It indeed would require you to have much more knowledge of the heap operation internals to find the root cause of the corruption.

This is all true and that's why I shared this discovery as something unexpected, because this was contrary to my intuition, too.
Post 09 Feb 2016, 15:11
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  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.