flat assembler
Message board for the users of flat assembler.
Index
> Programming Language Design > On my new assembler Goto page Previous 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 Next |
Author |
|
Tomasz Grysztar 15 Sep 2016, 03:37
bitRAKE wrote: Yet, how can "ExitProcess" be defined outside of the namespaces? (Something I'd like to avoid - should only be PE.Kernel32.ExitProcess.) |
|||
15 Sep 2016, 03:37 |
|
Tomasz Grysztar 24 Sep 2016, 20:58
I have changed the version number to 0.99 with an update to interface that finally displays the content of line that caused an error. I try it with an algorithm that displays the line that came directly from source file and then, if an error happened inside a macro, also the final line at the deepest level that triggered an error. From my experience I think that this should provide needed information in most cases while not cluttering the error report too much.
When an error is triggered by ERR, that line is not shown. So when it is a macro that signals some error with ERR directive, the user is going to see the line that called the macro and the error message chosen by macro. In addition I could also display the preprocessed text of that final line, maybe as a switchable option, but I have decided to not do it at the moment, because this feature would have some peculiarities (in fasmg preprocessing is limited to expanding the parameters and not the symbolic variables) and I need some more time to decide whether is it worth exposing. Last edited by Tomasz Grysztar on 24 Sep 2016, 21:15; edited 1 time in total |
|||
24 Sep 2016, 20:58 |
|
jmg 24 Sep 2016, 23:38
Tomasz Grysztar wrote: I have changed the version number to 0.99 with an update to interface that finally displays the content of line that caused an error. I try it with an algorithm that displays the line that came directly from source file and then, if an error happened inside a macro, also the final line at the deepest level that triggered an error. From my experience I think that this should provide needed information in most cases while not cluttering the error report too much. Looks like a good improvement Can the error, also report the Column Number ? Some errors like name typos are easy to find, as the name is reported, but more cryptic ones like error: extra characters on line. would be helped greatly, with a Column indicator. |
|||
24 Sep 2016, 23:38 |
|
Tomasz Grysztar 25 Sep 2016, 07:37
jmg wrote: Can the error, also report the Column Number ? |
|||
25 Sep 2016, 07:37 |
|
zhak 25 Sep 2016, 07:37
Do lines wrapped with \ are treated as one line of source or multiple?
|
|||
25 Sep 2016, 07:37 |
|
Tomasz Grysztar 25 Sep 2016, 07:41
zhak wrote: Do lines wrapped with \ are treated as one line of source or multiple? |
|||
25 Sep 2016, 07:41 |
|
jmg 25 Sep 2016, 08:56
Tomasz Grysztar wrote:
It might one one statement per line, but that expression can have a great many terms, commas and braces, especially within macros. error: extra characters on line. really does not help find a misplaced brace. As the Column number is only needed when an error occurs, what about a system that re-token-counts just the error line, and reports a Char posn based on Token # ? That has no speed cost to the main assembly process. Failing that, even a Token Count reported, would be better than nothing in X. |
|||
25 Sep 2016, 08:56 |
|
Tomasz Grysztar 25 Sep 2016, 10:22
jmg wrote: It might one one statement per line, but that expression can have a great many terms, commas and braces, especially within macros. jmg wrote: As the Column number is only needed when an error occurs, what about a system that re-token-counts just the error line, and reports a Char posn based on Token # ? The lack of a column number has never really came up as a problem during more than a dozen years of development of very complex macros in fasm (and the ones of fasmg are much easier to keep well-structured and controlled) so I'm not willing to put any resources into it. I no longer have so much time on my disposal. |
|||
25 Sep 2016, 10:22 |
|
Tomasz Grysztar 25 Sep 2016, 18:30
The updated fasmg 0.99 shows the pre-processed content of line that caused an error. Now I need to back-port this feature to the console versions of fasm, because they still don't have it despite the fact that fasmw has had it in its error report window for ages.
|
|||
25 Sep 2016, 18:30 |
|
jmg 25 Sep 2016, 20:08
Tomasz Grysztar wrote: ...This is under the assumption that we have at least a token number, but this may not always be the case... OK, I was just checking there was no simple solution overlooked. Tomasz Grysztar wrote: The updated fasmg 0.99 shows the pre-processed content of line that caused an error. Yes, that works great, and is a significant improvement |
|||
25 Sep 2016, 20:08 |
|
Tomasz Grysztar 13 Oct 2016, 08:51
After the previously mentioned changes to the mechanics of recognizing the local symbols I gradually cleaned up the symbol recognition functions and it made the whole assembly a bit faster. This is not much, but on a big sources it may make some difference.
|
|||
13 Oct 2016, 08:51 |
|
jmg 13 Oct 2016, 20:05
Great.
I get these speed results in a simple test file ;0.99 ; Listing ON -> 2 passes, 2.4 seconds, 16547 bytes. 266k LST ; Listing OFF -> 2 passes, 0.4 seconds, 16547 bytes. 80 byte LST The listing here does a console redirect in the make.cmd, but that seems to be quite slow. ( one sixth the speed) (You can see why I asked for more digits on the time report.) Might be faster if the listing can open and report directly to a file, with a reasonable size file buffer ? Another question: I see manual.txt mention of proc/endp macros, which look like they can manage unused/dead code removal, via the multi-pass feature, but that is not explicitly stated ? Can something as universally useful as dead code removal structures, be included without needing slower macro includes ? |
|||
13 Oct 2016, 20:05 |
|
Tomasz Grysztar 13 Oct 2016, 20:25
jmg wrote: ;0.99 jmg wrote: Might be faster if the listing can open and report directly to a file, with a reasonable size file buffer ? jmg wrote: Another question: |
|||
13 Oct 2016, 20:25 |
|
jmg 14 Oct 2016, 00:47
Tomasz Grysztar wrote:
I think here you talk about some internal operations ? The listing file I finally see is not verbose, in the sense of not expanding the macros themselves. This is what it looks like : Code: 000000B1: 05 14 E8 6D qIF_Z qXOR 0AH,#05H WC 000000B5: 05 14 E8 6E qIF_Z qXOR 0AH,#05H WZ 000000B9: 05 14 E8 6F qIF_Z qXOR 0AH,#05H WZ,WC 000000BD: 05 14 E8 6F qIF_Z qXOR 0AH,#05H WC, WZ 000000C1: 05 14 68 6C qIF_Z qXOR 0AH,#05H NR 000000C5: 05 14 FC 6C qXOR 0AH,#05H 000000C9: 05 14 FC 6D qXOR 0AH,#05H WC 000000CD: 05 14 FC 6C qIF_ALWAYS qXOR 0AH,#05H 000000D1: 05 14 FC 6E qIF_ALWAYS qXOR 0AH,#05H WZ 000000D5: 05 14 FC 6F qIF_ALWAYS qXOR 0AH,#05H WZ, WC 000000D9: 05 14 7C 6F qIF_ALWAYS qXOR 0AH,#05H WZ, WC, NR Each of those lines, actually calls a 16 line then 9 line macro. |
|||
14 Oct 2016, 00:47 |
|
Tomasz Grysztar 16 Oct 2016, 16:10
I have made another update today, and among some other small bug fixes it brings an important correction to the algorithm of resolving the "if used" condition. Previously, if symbol was used inside a descendant namespace, fasmg was not able to detect it, because it assumed that this use applied just to a local symbol in that namespace. For example this snippet did not assemble:
Code: if used external external = 0 end if namespace proc use = external end namespace |
|||
16 Oct 2016, 16:10 |
|
Tomasz Grysztar 17 Oct 2016, 14:47
One more update, it's mostly cleanup and another very minor speedup as a result of it, but it also brings correction to ERR directive so that it allows the same syntax as DISPLAY, and the new -v command line switch that allows to show contents of all the lines from the stack when reporting an error. Combined with -e switch this can lead to very long error reports, so I have kept the concise default (which shows only the line from innermost macro and the line from source file that called the macros).
|
|||
17 Oct 2016, 14:47 |
|
tthsqe 08 Nov 2016, 14:37
omasz, how hard would it be to convert
https://github.com/tthsqe12/asm/tree/master/asmFish into the new fasmg and possibly get a version for the mac os? |
|||
08 Nov 2016, 14:37 |
|
Tomasz Grysztar 08 Nov 2016, 14:56
tthsqe wrote: omasz, how hard would it be to convert As for the version for Mac, you would need to write some Mach-O formatting macros, as there are none yet. The ELF macros could be used as a base. |
|||
08 Nov 2016, 14:56 |
|
Tomasz Grysztar 10 Nov 2016, 20:07
My work on fasmg and macros is currently on hiatus again, but when I find another opportunity to dedicate some time to it, I plan to make the AVX macros next.
|
|||
10 Nov 2016, 20:07 |
|
Goto page Previous 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.