Grouping on symbolic stacks. Suggestion.

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

Author

Thread

l_inc

Joined: 23 Oct 2009
Posts: 881

l_inc 03 Jul 2013, 14:23

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

03 Jul 2013, 14:23

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20299
Location: In your JS exploiting you and your system

revolution 03 Jul 2013, 14:35

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.

03 Jul 2013, 14:35

l_inc

Joined: 23 Oct 2009
Posts: 881

l_inc 03 Jul 2013, 15:03

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

03 Jul 2013, 15:03

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20299
Location: In your JS exploiting you and your system

revolution 03 Jul 2013, 15:14

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.

03 Jul 2013, 15:14

l_inc

Joined: 23 Oct 2009
Posts: 881

l_inc 03 Jul 2013, 15:52

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

03 Jul 2013, 15:52

bitRAKE

Joined: 21 Jul 2003
Posts: 4020
Location: vpcmpistri

bitRAKE 05 Jul 2013, 21:52

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 \} }

05 Jul 2013, 21:52

l_inc

Joined: 23 Oct 2009
Posts: 881

l_inc 06 Jul 2013, 10:15

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

06 Jul 2013, 10:15

baldr

Joined: 19 Mar 2008
Posts: 1651

baldr 07 Jul 2013, 05:16

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.

07 Jul 2013, 05:16

bitRAKE

Joined: 21 Jul 2003
Posts: 4020
Location: vpcmpistri

bitRAKE 07 Jul 2013, 08:41

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)/¯ “languages are not safe - uses can be” Bjarne Stroustrup

07 Jul 2013, 08:41

l_inc

Joined: 23 Oct 2009
Posts: 881

l_inc 07 Jul 2013, 12:24

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

07 Jul 2013, 12:24

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8351
Location: Kraków, Poland

Tomasz Grysztar 01 Feb 2014, 17:02

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

01 Feb 2014, 17:02

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8351
Location: Kraków, Poland

Tomasz Grysztar 01 Feb 2014, 20:23

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.

01 Feb 2014, 20:23

< 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