flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > fasmg tests and bugs

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



Joined: 16 Jun 2003
Posts: 7958
Location: Kraków, Poland
Tomasz Grysztar
I have managed to improve the parsing of fasmg's macros a little bit more. Please try the i0j8x release and let me know how it performs. As far as I know the name-caching changes I made should not break anything, but still I could have introduced some new bugs.
Post 10 Dec 2017, 10:50
View user's profile Send private message Visit poster's website Reply with quote
jacobly



Joined: 04 Feb 2016
Posts: 44
jacobly
Nice, all of my ez80 tests pass and I'm seeing a 0.1 second speedup on my 8910 instruction tests.
Post 10 Dec 2017, 11:07
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7958
Location: Kraków, Poland
Tomasz Grysztar
I uploaded it a bit prematurely, there was still one thing I forgot to correct. Please try the i0jae instead. Wink
Post 10 Dec 2017, 11:14
View user's profile Send private message Visit poster's website Reply with quote
jacobly



Joined: 04 Feb 2016
Posts: 44
jacobly
With i0jae the tests still pass but they are all 1.5 to 2 times slower.
Edit: I reran the tests and it's still slower, but by less than 0.5 times.


Last edited by jacobly on 10 Dec 2017, 11:33; edited 1 time in total
Post 10 Dec 2017, 11:25
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7958
Location: Kraków, Poland
Tomasz Grysztar
Are you sure there is nothing else interfering? Such a huge difference is unexpected. In all my tests i0jae is slightly faster than i0j8x but these are not large differences, they should be around 5%, 10% at most.
Post 10 Dec 2017, 11:29
View user's profile Send private message Visit poster's website Reply with quote
jacobly



Joined: 04 Feb 2016
Posts: 44
jacobly
Running the tests locally more carefully, and comparing to hykpg (I never actually saved i0j8x anywhere) I'm seeing one that is 26% slower, one that is 10% slower, and the rest are the same or faster.
Post 10 Dec 2017, 11:46
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7958
Location: Kraków, Poland
Tomasz Grysztar
Could you send me one that is noticeably slower? So far I have not found anything that would be slower with i0jae on my machine, but this may also be environment-dependent.
Post 10 Dec 2017, 12:01
View user's profile Send private message Visit poster's website Reply with quote
jacobly



Joined: 04 Feb 2016
Posts: 44
jacobly
So I tracked down what was causing the regression, and it turns out that every failing match is about 2-4 times slower from hykpg to i0jae, and my test case happened to execute over 140000 unsuccessful matches.
Edit: In comparison, successful matches are only 5% slower.


Last edited by jacobly on 10 Dec 2017, 13:11; edited 1 time in total
Post 10 Dec 2017, 12:48
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7958
Location: Kraków, Poland
Tomasz Grysztar
Interesting, as MATCH should not even be affected by any of the changes made recently. Could be some misalignment in code but then it would be curious that the difference is so large. Or perhaps some memory cache issue. What do these matches look like?

I tried with a few simple ones, but on my machine they work exactly as fast with the i0jae as with hykpg (as expected, because MATCH implementation has not been changed).
Post 10 Dec 2017, 13:11
View user's profile Send private message Visit poster's website Reply with quote
jacobly



Joined: 04 Feb 2016
Posts: 44
jacobly
The form of the match appears to make no difference, however it was not reproducible on either the mac or windows versions (under wine or vm), but I did reproduce it on three very different linux machines (native and vm).
Post 10 Dec 2017, 13:52
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7958
Location: Kraków, Poland
Tomasz Grysztar
Interesting, may have something to do with memory layout then.
Post 10 Dec 2017, 14:05
View user's profile Send private message Visit poster's website Reply with quote
jacobly



Joined: 04 Feb 2016
Posts: 44
jacobly
Surprisingly fossil bisect says:
1 BAD 2017-12-10 11:15:16 aac1e59856e7f5dc
so it was somehow introduced from i0j8x to i0jae.
Post 10 Dec 2017, 14:12
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7958
Location: Kraków, Poland
Tomasz Grysztar
This looks like a code alignment issue. I think I managed to reproduce it, now I need to take a better look.
Post 10 Dec 2017, 14:20
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7958
Location: Kraków, Poland
Tomasz Grysztar
Turns out that Linux version was missing alignment for the data segment and the addresses of all the variables were moving in and out of alignment depending on the exact size of the preceding code/text segments. MATCH is probably vulnerable because it uses many variables that should be aligned.

Please try it out with the alignment added in i0jhl.
Post 10 Dec 2017, 14:52
View user's profile Send private message Visit poster's website Reply with quote
jacobly



Joined: 04 Feb 2016
Posts: 44
jacobly
I'm now seeing the same 0.1 second speedups in i0jhl that I saw in i0j8x.
Edit: Also all the tests are the same speed or faster than hykpg.
Post 10 Dec 2017, 20:08
View user's profile Send private message Reply with quote
jacobly



Joined: 04 Feb 2016
Posts: 44
jacobly
In commit 24c8171d7f the variable clearing at the top of assembly_init was optimized, but unfortunately, it now also clears the trace_mode variable that is stored to immediately before. Additionally, at least on linux and libc, the variables in fasmg.asm are out of alignment again.
Post 02 Sep 2020, 04:59
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7958
Location: Kraków, Poland
Tomasz Grysztar
jacobly wrote:
Additionally, at least on linux and libc, the variables in fasmg.asm are out of alignment again.
The libc version has always been missing alignment (I added it now), however the final result might have been dependent on linker's choices.
Post 02 Sep 2020, 08:10
View user's profile Send private message Visit poster's website Reply with quote
jacobly



Joined: 04 Feb 2016
Posts: 44
jacobly
If I have code like this:
Code:
path = '/does/not/exist'
include path    

Which outputs an error like this:
Code:
flat assembler  version g.j1gh
source_file_not_found.asm [2]:
        include path
Processed: include path
Error: source file not found.    

It would be helpful if the error message contained the non-existing path, which would normally be a literal in the processed line, but if a variable is used it is hard to tell what file wasn't found.
Post 21 Sep 2020, 13:13
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7958
Location: Kraków, Poland
Tomasz Grysztar
jacobly wrote:
It would be helpful if the error message contained the non-existing path, which would normally be a literal in the processed line, but if a variable is used it is hard to tell what file wasn't found.
I tried adding this in the latest release. It is not perfect, it actually shows just the last of the paths that were tried. It should still be helpful, though.
Post 22 Sep 2020, 17:13
View user's profile Send private message Visit poster's website Reply with quote
jacobly



Joined: 04 Feb 2016
Posts: 44
jacobly
Tomasz Grysztar wrote:
I tried adding this in the latest release. It is not perfect, it actually shows just the last of the paths that were tried. It should still be helpful, though.
Yep that was plenty, the important part is the part of the path passed to include.

This creates a file with a funny name:
Code:
virtual as ''
end virtual    
I don't actually need to do this, but I happened to notice it in the middle of trying to use '' as a sentinel to mean don't output a separate file.

Is there a way to parse a conditional expression stored in a variable from calm since check only supports normal expressions inside variables? I can't just assemble an if since I'm trying to jump based on the result.
Post 02 May 2021, 09:08
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  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


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.