Index
> Compiler Internals > fasmg tests and bugsGoto page 1, 2 Next |
| Author |
|
|
jacobly 10 Dec 2017, 11:07
Nice, all of my ez80 tests pass and I'm seeing a 0.1 second speedup on my 8910 instruction tests.
|
|||
10 Dec 2017, 11:07 |
|
|
Tomasz Grysztar 10 Dec 2017, 11:14
I uploaded it a bit prematurely, there was still one thing I forgot to correct. Please try the i0jae instead.
 |
|||
|
10 Dec 2017, 11:14 |
|
|
jacobly 10 Dec 2017, 11:25
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 |
|||
|
10 Dec 2017, 11:25 |
|
|
Tomasz Grysztar 10 Dec 2017, 11:29
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.
|
|||
|
10 Dec 2017, 11:29 |
|
|
jacobly 10 Dec 2017, 11:46
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.
|
|||
|
10 Dec 2017, 11:46 |
|
|
Tomasz Grysztar 10 Dec 2017, 12:01
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.
|
|||
|
10 Dec 2017, 12:01 |
|
|
jacobly 10 Dec 2017, 12:48
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 |
|||
|
10 Dec 2017, 12:48 |
|
|
Tomasz Grysztar 10 Dec 2017, 13:11
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). |
|||
|
10 Dec 2017, 13:11 |
|
|
jacobly 10 Dec 2017, 13:52
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).
|
|||
|
10 Dec 2017, 13:52 |
|
|
Tomasz Grysztar 10 Dec 2017, 14:05
Interesting, may have something to do with memory layout then.
|
|||
|
10 Dec 2017, 14:05 |
|
|
jacobly 10 Dec 2017, 14:12
Surprisingly fossil bisect says:
1 BAD 2017-12-10 11:15:16 aac1e59856e7f5dc so it was somehow introduced from i0j8x to i0jae. |
|||
|
10 Dec 2017, 14:12 |
|
|
Tomasz Grysztar 10 Dec 2017, 14:20
This looks like a code alignment issue. I think I managed to reproduce it, now I need to take a better look.
|
|||
|
10 Dec 2017, 14:20 |
|
|
Tomasz Grysztar 10 Dec 2017, 14:52
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. |
|||
|
10 Dec 2017, 14:52 |
|
|
jacobly 10 Dec 2017, 20:08
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. |
|||
|
10 Dec 2017, 20:08 |
|
|
jacobly 02 Sep 2020, 04:59
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.
|
|||
|
02 Sep 2020, 04:59 |
|
|
Tomasz Grysztar 02 Sep 2020, 08:10
jacobly wrote: Additionally, at least on linux and libc, the variables in fasmg.asm are out of alignment again. |
|||
|
02 Sep 2020, 08:10 |
|
|
jacobly 21 Sep 2020, 13:13
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. |
|||
|
21 Sep 2020, 13:13 |
|
|
Tomasz Grysztar 22 Sep 2020, 17:13
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. |
|||
|
22 Sep 2020, 17:13 |
|
|
jacobly 02 May 2021, 09:08
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. This creates a file with a funny name: Code: virtual as ''
end virtual 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. |
|||
|
02 May 2021, 09:08 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|