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
Thread Post new topic Reply to topic
bitRAKE



Joined: 21 Jul 2003
Posts: 4024
Location: vpcmpistri
bitRAKE 15 Sep 2016, 01:53
Quote:
Note that "namespace" by itself does not create a namespace.
Thank you. Past use in other languages has impacted my perspective on this.

Interesting use of double colon in:
Code:
PE::
namespace PE    
I just need to back up and start working with smaller code fragments until I understand the semantics better - too many assumptions based on past experience. In some places I'm over-complicating, while oversimplifying in others, lol.
Code:
;@REM use windows CMD processor to build Wink
;@..\fasmg\fasmg.exe -e 5 %~nx0 %~n0.exe
;@PAUSE
;@GOTO:EOF

A::
macro _ X,Y,Z
  namespace A.X
    R='O'
    namespace A.X.Y
      Q='k'
    end namespace
  end namespace
end macro


_ B,C,?

display A.B.R
display A.B.C.Q    
Very powerful syntax.
Post 15 Sep 2016, 01:53
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8351
Location: Kraków, Poland
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.)
It is possible to create a symbolic link with "define" or "equ" and use it for the purpose of defining a symbol outside of the namespaces you are in. Perhaps this is what troubles you here - by using symbolic variables you may have unintentionally created symbolic links to global variables. If this is your problem, please read about "rmatch" in the manual.
Post 15 Sep 2016, 03:37
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8351
Location: Kraków, Poland
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
Post 24 Sep 2016, 20:58
View user's profile Send private message Visit poster's website Reply with quote
jmg



Joined: 18 Sep 2016
Posts: 62
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.

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.


Looks like a good improvement Smile

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.
Post 24 Sep 2016, 23:38
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8351
Location: Kraków, Poland
Tomasz Grysztar 25 Sep 2016, 07:37
jmg wrote:
Can the error, also report the Column Number ?
fasmg, just like fasm, operates on the pre-tokenized source that is far removed from the column numbers of the original text. Tracking the column numbers for every token would be very costly. I always thought that column numbers are not essential for a language like assembly which has one statement per line.
Post 25 Sep 2016, 07:37
View user's profile Send private message Visit poster's website Reply with quote
zhak



Joined: 12 Apr 2005
Posts: 501
Location: Belarus
zhak 25 Sep 2016, 07:37
Do lines wrapped with \ are treated as one line of source or multiple?
Post 25 Sep 2016, 07:37
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8351
Location: Kraków, Poland
Tomasz Grysztar 25 Sep 2016, 07:41
zhak wrote:
Do lines wrapped with \ are treated as one line of source or multiple?
Something inbetween. They are still multiple lines after passing through the first layer of tokenization, but on the second one (the preprocessing) they merge into a continuous sequence of tokens.
Post 25 Sep 2016, 07:41
View user's profile Send private message Visit poster's website Reply with quote
jmg



Joined: 18 Sep 2016
Posts: 62
jmg 25 Sep 2016, 08:56
Tomasz Grysztar wrote:
jmg wrote:
Can the error, also report the Column Number ?
fasmg, just like fasm, operates on the pre-tokenized source that is far removed from the column numbers of the original text. Tracking the column numbers for every token would be very costly. I always thought that column numbers are not essential for a language like assembly which has one statement per line.


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.
Post 25 Sep 2016, 08:56
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8351
Location: Kraków, Poland
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.
When there are complex constructions converted with macro, they end up being split up and processed by many small statements in macro processing. From the stack of macro calls you get more information, especially when the preprocessed macro statement is added at the end, like in fasmw.

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 # ?

That has no speed cost to the main assembly process.
This is under the assumption that we have at least a token number, but this may not always be the case, and making sure that all cases are covered would need a review of entire source. Since reporting column number was never needed, the assembler has not been designed with such an assumption in mind.

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.
Post 25 Sep 2016, 10:22
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8351
Location: Kraków, Poland
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.
Post 25 Sep 2016, 18:30
View user's profile Send private message Visit poster's website Reply with quote
jmg



Joined: 18 Sep 2016
Posts: 62
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 Smile
Post 25 Sep 2016, 20:08
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8351
Location: Kraków, Poland
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.
Post 13 Oct 2016, 08:51
View user's profile Send private message Visit poster's website Reply with quote
jmg



Joined: 18 Sep 2016
Posts: 62
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 ?
Post 13 Oct 2016, 20:05
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8351
Location: Kraków, Poland
Tomasz Grysztar 13 Oct 2016, 20:25
jmg wrote:
;0.99
Please use the complete version number when reporting anything. The "0.99" is just the umbrella, the true version is determined by the timestamp that comes next.

jmg wrote:
Might be faster if the listing can open and report directly to a file, with a reasonable size file buffer ?
The main reason why listing macros add so much time to the assembly is that every single line gets expanded into this long macro (since "macro ?" intercepts almost all the source lines). The othet option could be to make this macro as short as possible, only collecting the values that could then be processed into a listing text in the postponed block. Also, if the redirected display is not buffered properly in your environment, then in the postponed listing the entire text may be generated into a VIRTUAL block and then displayed as a single block. I may try such a variant later, when I get some free time.
jmg wrote:
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 ?
This is one of the classic features of fasm 1 which got directly copied into fasmg. I have not yet prepared a fully-featured "proc" macro set for fasmg that would implement everything that the ones written for fasm 1 have, but a minimal macro that only provides the "if used" functionality can be useful for the purpose you mentioned, and this macro is so simple that it should cost next to nothing in terms of the assembly performance.
Post 13 Oct 2016, 20:25
View user's profile Send private message Visit poster's website Reply with quote
jmg



Joined: 18 Sep 2016
Posts: 62
jmg 14 Oct 2016, 00:47
Tomasz Grysztar wrote:

jmg wrote:
Might be faster if the listing can open and report directly to a file, with a reasonable size file buffer ?
The main reason why listing macros add so much time to the assembly is that every single line gets expanded into this long macro (since "macro ?" intercepts almost all the source lines). The othet option could be to make this macro as short as possible, only collecting the values that could then be processed into a listing text in the postponed block. Also, if the redirected display is not buffered properly in your environment, then in the postponed listing the entire text may be generated into a VIRTUAL block and then displayed as a single block. I may try such a variant later, when I get some free time.


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.
Post 14 Oct 2016, 00:47
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8351
Location: Kraków, Poland
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    
With the correction in place, the "IF USED" is going to correctly detect symbol usage even when it is at larger depth in the namespace tree.
Post 16 Oct 2016, 16:10
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8351
Location: Kraków, Poland
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).
Post 17 Oct 2016, 14:47
View user's profile Send private message Visit poster's website Reply with quote
tthsqe



Joined: 20 May 2009
Posts: 767
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?
Post 08 Nov 2016, 14:37
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8351
Location: Kraków, Poland
Tomasz Grysztar 08 Nov 2016, 14:56
tthsqe wrote:
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?
I think it would be more tedious than hard, the macros are easy to convert but there are many of them. Also some label names would need to be altered, since "?" is a special character in fasmg. And you would need me to finish my AVX macros first. Wink

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.
Post 08 Nov 2016, 14:56
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8351
Location: Kraków, Poland
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.
Post 10 Nov 2016, 20:07
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 Previous  1, 2, 3, 4, 5, 6, 7, 8, 9, 10  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-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.