flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > Grouping on symbolic stacks. Suggestion.

Author
Thread Post new topic Reply to topic
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
Hello guys. I finally have some time to talk about fasm.

The feature I'd like to suggest does not allow to implement any previously impossible things, but could potentially simplify existing things. Thus it's not something absolutely necessary and superb like addressing space labels.

The symbolic constants are stacks in fasm. Thus it would probably be nice to be able to easily enumerate all values in such a stack. As a solution the following extended macro syntax seems to be appropriate:

Code:
symbol equ 'Hello'
symbol equ ', '
symbol equ 'world',13,10

macro show (arg)
{
        forward display arg ; displays "Hello, world" using 3 display directives
        common display arg ; displays "Hello, world" using 1 display directive
}

show symbol    

This is analogous to the argument groups, but just works with the symbolic constant stack. E.g., the same could be done for multiple arguments:
Code:
macro show (arg1, arg2, arg3)
{
        ...
}    

In this case the number of iterations is the depth of the longest stack, and other arguments get an empty value for non-existing correpsonding values of the stacks. All the regular things like mandatory arguments (*) or default values are applicable here.

Everybody is welcome to comment on the usefulness of the suggested feature. And the author is also welcome to comment on the probability of implementing it. Smile

_________________
Faith is a superposition of knowledge and fallacy
Post 03 Jul 2013, 14:23
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17716
Location: In your JS exploiting you and your system
revolution
I think if you showed a current necessary situation where this solution would be clearly best then you would have a better chance of getting it considered for inclusion. Right now I have trouble envisaging what sort of code construct this is used with.

You do know that you can already "build" up EQUed symbols and extend them, right? Your example above can be done by simply progressively extending the symbol at each line.
Post 03 Jul 2013, 14:35
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
revolution
Quote:
a current necessary situation where this solution would be clearly best

As I said. It's not a necessary feature. But a nice one. Like if you need to know current stack depth of some symbolic constant, then you don't need to create another (extendible) symbolic constant to count the depth.
Quote:
Your example above can be done by simply progressively extending the symbol at each line.

Sure. But consider all the situations, when you need to build long lists of symbols or strings (like when you need to automatically merge duplicated strings). Instead of pushing a pyramid like this into a symbol:
Code:
"SomeString1"
"SomeString1" "SomeString2"
"SomeString1" "SomeString2" "SomeString3"    

you can just create a list based on the stack:
Code:
"SomeString1"
"SomeString2"
"SomeString3"    

Linear memory requirement instead of square.
Quote:
Right now I have trouble envisaging what sort of code construct this is used with.

I actually expected, that most users could imaging situations, when they needed such a feature for simplification of macro development.

_________________
Faith is a superposition of knowledge and fallacy
Post 03 Jul 2013, 15:03
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17716
Location: In your JS exploiting you and your system
revolution
l_inc wrote:
Instead of pushing a pyramid like this into a symbol:
Code:
"SomeString1"
"SomeString1" "SomeString2"
"SomeString1" "SomeString2" "SomeString3"    

you can just create a list based on the stack:
Code:
"SomeString1"
"SomeString2"
"SomeString3"    

Linear memory requirement instead of square.
I posted some list building macros for linear memory usage. They were a bit clunky but I think it meets similar requirements.

I'm not trying to discourage you, but merely to help you to formulate a strong argument for inclusion. I feel that without a strong argument it tends to get pushed away if there are other ways to solve problems with the existing syntax.
Post 03 Jul 2013, 15:14
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
revolution
Quote:
I posted some list building macros for linear memory usage.

You needed an additional symbolic constant to count the list size, right? Anyway the least possible memory overhead is achieved by using the symbolic stacks. I mean, additional bookkeeping is not something really terrible, but is not welcome also.
Quote:
I'm not trying to discourage you

I understand that. But I didn't have situations where I can't live without this feature. Therefore if someone else will find it nice, good. If not, then it's not necessary for me either.

_________________
Faith is a superposition of knowledge and fallacy
Post 03 Jul 2013, 15:52
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3055
Location: vpcmipstrm
bitRAKE
It intrigued me if this was possible with the current macro implementation. Not the list generation, but the depth processing of EQU. Seems a little tricky.
Code:
macro U [A] { common display "Depth Exceeded.",13,10
  err }
macro U [A] { common
  _ equ
  match =A,A \{
    restore _
    _ equ ,
  \}
  match ,_ \{
    match ch,A \\{
      display \\`ch
    \\}
    restore A
    U A
  \}
  restore _
}

...several copies of U macro...    
I couldn't find a way around using several copies of U. Maybe there is some way to delay the evaluation of the symbol that I'm missing.

Can test it with the following:
Code:
V equ 0
V equ 1
V equ 2
V equ 3
U V    
...with at least five copies of U.

Another level of indirection doesn't work for example,
Code:
; U invokes T instead of itself.
rept 5 { macro T [A] \{ common U A \} }    
Post 05 Jul 2013, 21:52
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
bitRAKE
It's not tricky, but rather wasteful. You don't need to define multiple macros explicitly. Just use recursive macros:
Code:
macro dispSym sym* { match \sym,sym \{ display \`\sym,13,10 \} }
macro def_CountDepth
{
        struc CountDepth sym*
        \{
                \. = 0
                define matched +
                define matched -
                match =sym,sym \\{ restore matched \\}
                match -,matched
                \\{
                        dispSym sym
                        restore matched
                        x equ sym
                        restore sym
                                def_CountDepth
                                \. CountDepth sym
                                purge CountDepth
                        \. = \. + 1
                        sym equ x
                        restore x
                \\}
                restore matched
        \}
}
def_CountDepth    

This won't even destroy the stack (because of the double stack inversion via x):
Code:
ops equ +
ops equ -
ops equ *
ops equ /

depth CountDepth ops
display 'Total depth: ','0' + depth,13,10
;we can count the depth again and therefore check
;if the previous count destroyed the stack:
depth CountDepth ops 
display 'Total depth: ','0' + depth,13,10    

Unfortunately, even this is not guaranteed to work correctly:
Code:
ops equ +
ops equ -
ops equ *
ops equ /
define ops ops
ops equ ^

depth CountDepth ops
display 'Total depth: ','0' + depth,13,10    

_________________
Faith is a superposition of knowledge and fallacy
Post 06 Jul 2013, 10:15
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr
bitRAKE,

There is no (documented) way to distinguish undefined symbol from symbol equ symbol, sadly. Apart from that, recursion is a way to go. Probably Tomasz would provide explicit method to extend macro scope to include itself; otherwise, recursion is all about redefinition.
Post 07 Jul 2013, 05:16
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3055
Location: vpcmipstrm
bitRAKE
It could be viewed as a feature that undefined symbol is equivalent to itself, or try to restore it a few times to be sure? I haven't read the preprocessor code really, so I don't know if these copies hang around in memory during the assembly phase. Seems like purge/restore/restruc would free up memory usage.

Could move the "\.=0" inside the "=sym" match; since it's always first -- no problem with multiple assignments to zero though.

The proposed syntax seems unusual. What would happen if arg were not a symbol? Error: symbol expected - I suppose. Could they be combined with regular arguments? Syntactically, I'm assuming it would be positioned like the current [] argument grouping.

_________________
¯\(°_o)/¯ unlicense.org
Post 07 Jul 2013, 08:41
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
bitRAKE
Quote:
Seems like purge/restore/restruc would free up memory usage.

I normally try to avoid reading fasm source codes, but from my experience memory usage is even increased by that. Unfortunately I just can't allow myself to leave dirt, even if it's just a logical dirt.

Quote:
Could move the "\.=0" inside the "=sym" match

Yes. But single line macroblocks look nicer. Smile Especially because my coding style requires relatively high overhead for arranging multiline macroblocks.

Quote:
The proposed syntax seems unusual.

I'm very unsure regarding the syntax. As well as regarding the importance of the feature at all. Smile

Quote:
What would happen if arg were not a symbol?

I assume you mean "not a symbolic constant". In fact, anything except symbol characters, strings and preprocessor directives can be (and kinda is) a symbolic constant.

Quote:
Could they be combined with regular arguments?

Sure. Same as normal grouped arguments. Probably even combined together with the normal argument groups:
Code:
macro show arg0,(arg1, arg2, arg3),[arg4, arg5, arg6]
{ 
    ...
}    

I don't see any practical usefulness here though.

_________________
Faith is a superposition of knowledge and fallacy
Post 07 Jul 2013, 12:24
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7802
Location: Kraków, Poland
Tomasz Grysztar
The idea in general is quite good, it should be easy to implement something like it in fasm's core and perhaps it could come handy from time to time. Though I'm not convinced by that extended macro syntax, it mixes to many things in one place, for my taste. What I would prefer would be a kind of IRP-like directive to iterate through the values of symbolic variable, let's say IRPV.

Even though I could add it quickly and at least play with this feature for some time, I'm still hesitating, as it would add to preprocessor something I actually didn't want - a way to distinguish whether some symbol was already defined as a symbolic variable or not. The way it is currently implemented, there is no difference between not defining a variable or defining it with a value containing nothing more and nothing less than its exact name. This way one could theoretically think of all the name symbols in fasm as being symbolic variables with values initially set to the names themselves.

But, that being said, it is still possible that I'm going to implement something like IRPV. It wouldn't really hurt that much. Would it be useful? I don't know yet. Smile
Post 01 Feb 2014, 17:02
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7802
Location: Kraków, Poland
Tomasz Grysztar
I have made a version with IRPV support and I'm testing it now. It seems to be working well. I still haven't put it into a good use anywhere, but it can at least make some things simpler.

And the fact that it allows to distinguish whether a symbolic variable was defined or not, even though it was causing me to hesitate, can be actually considered a new feature.
Post 01 Feb 2014, 20:23
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:  


< 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.