flat assembler
Message board for the users of flat assembler.
![]() Goto page Previous 1, 2, 3 ... , 9, 10, 11 Next |
Author |
|
VEG
Tomasz Grysztar wrote: These additions open up a way for the option of generating multiple files from one source, which I've been planning for years. It would be limited to declaring the extensions of the produced files, analogously to the main file. |
|||
![]() |
|
jacobly
The addition of format affected the forward referenceability of a format macro I wrote, and while trying to fix it, I realized that a nice solution would be to redirect format? type args& to format?.type args. It seems like this would be a useful feature to have in fasmg natively, similar to how the end directive is implemented, which would make defining custom formats easier.
|
|||
![]() |
|
Tomasz Grysztar
jacobly wrote: The addition of format affected the forward referenceability of a format macro I wrote, and while trying to fix it, I realized that a nice solution would be to redirect format? type args& to format?.type args. It seems like this would be a useful feature to have in fasmg natively, similar to how the end directive is implemented, which would make defining custom formats easier. PS. I have update the Windows headers package to use this variant, forward-referenced FORMAT does work correctly there. I guess I need to make this a documented feature then. |
|||
![]() |
|
jacobly
Indeed it does work correctly, I just forgot to search for the next occurence of format in tables.inc...
|
|||
![]() |
|
Tomasz Grysztar
I have made another tiny addition to the language, which addresses two separate but similar problems.
First is the problem with defining a variable named like one of the instructions. The trick with a trailing dot often works, but the explanation of why it helps is quite complex, and this does not reliably work in all cases - for example trying to define case-insensitive "irp" as a variable with "irp?." identifier would still fail. Second, much less important problem is related to the recent addition of a support for numeric names inside identifiers. While this allowed to define such named symbols inside explicitly specified namespaces, there is no way to directly define or access such symbol from inside such namespace unless the parent symbol of the namespace is known. I have introduced a new syntax variant - with added "?" character right at the start of an identifier - that helps to define symbols with problematic names as mentioned above: Code: ?IRP equ 0007h ; defines case-sensitive symbol IRP namespace IRP ?1 = 'test' end namespace display IRP.1 |
|||
![]() |
|
Tomasz Grysztar
The addition of VIRTUAL AS has also pushed me to enable a feature that was long lurking from under the surface of fasmg engine, but I was postponing its inclusion because I was not sure what syntax should it use.
That feature is the ability to "continue" previously closed VIRTUAL block, allowing to append new data definitions at the end of such block. I decided to use the simplest possible syntax for it, just VIRTUAL followed by the area label that needs to refer to a previously defined VIRTUAL block: Code: virtual at 0 as 'log' Log:: end virtual virtual Log db 'Hello!',13,10 end virtual Not only does it allow to easily build auxiliary files piece after piece, this feature also makes it much easier to implement things like switching back and forth between definitions for code segment and data segment, etc. Multiple program segments can be assembled in parallel in virtual blocks, and only when they are finished they may be copied into an actual output. This is something that was very hard to do in the fasm 1 architecture, but is really easy within the design of fasmg. |
|||
![]() |
|
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.
|
|||
![]() |
|
jacobly
Nice, all of my ez80 tests pass and I'm seeing a 0.1 second speedup on my 8910 instruction tests.
|
|||
![]() |
|
Tomasz Grysztar
I uploaded it a bit prematurely, there was still one thing I forgot to correct. Please try the i0jae instead.
![]() |
|||
![]() |
|
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 |
|||
![]() |
|
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.
|
|||
![]() |
|
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.
|
|||
![]() |
|
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.
|
|||
![]() |
|
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 |
|||
![]() |
|
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). |
|||
![]() |
|
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).
|
|||
![]() |
|
Tomasz Grysztar
Interesting, may have something to do with memory layout then.
|
|||
![]() |
|
jacobly
Surprisingly fossil bisect says:
1 BAD 2017-12-10 11:15:16 aac1e59856e7f5dc so it was somehow introduced from i0j8x to i0jae. |
|||
![]() |
|
Tomasz Grysztar
This looks like a code alignment issue. I think I managed to reproduce it, now I need to take a better look.
|
|||
![]() |
|
Goto page Previous 1, 2, 3 ... , 9, 10, 11 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.
Website powered by rwasa.