Re: Paired Nested Macroses Support

[Jan Beulich <jbeulich@suse.com>]

(re-sending again, since you _again_ dropped the list from your reply;
I'm not going to further reply to private mails you may send on
technical matters)

On 16.02.2023 23:28, Dmytro Tarasiuk wrote:
> On 16.02.2023 18:31 Jan Beulich <jbeulich@suse.com> wrote:
>> (re-sending with the list added back - please don't drop the list when
>> replying to earlier list communication, unless there's a very specific
>> reason to do so)
>>
>> On 16.02.2023 16:06, Dmytro Tarasiuk wrote:
>>> on, 16.02.2023 10:04 Jan Beulich <jbeulich@suse.com> wrote:
>>>> On 16.02.2023 00:37, Dmytro Tarasiuk via Binutils wrote:
>>>>> Writing paired nested macros is not possible in the gas macro
>> assembler.
>>>>> For example, BEGIN/WHILE macros for loops, etc.  This is important to
>> me
>>>>> for writing portable pseudocode between different architectures that
>>>>> supports gas.
>>>>
>>>> Without explaining (perhaps by way of providing an example) it's unclear
>>>> what you mean here.
>>>>
>>>
>>> Excuse me. Here is an example of the macroses for nested cycles:
>>
>> Thanks for the example. My first conclusion is - there's no nesting
>> of macros here. Instead you want multiple macros to interact with
>> one another in a certain way. I think this can be achieved without
>> patching the assembler, using alternative macro mode (.altmacro) and
>> the special unary % operator that this mode supports. That may
>> require helper macros, yes, so the set of macros overall may end up
>> bigger (and uglier), but that's still not necessarily a reason to
>> extend gas.
>>
> 
> a:
> DO
>     [...]
>     b:
>     DO
>         [...]
>     DONE_WNEN
>     [...]
> DONE
> 
> Here is shown the pair (open/close) connected with one another macroses (DO
> ... DONE_WNEN) which are nested into another pair (open/close) connected
> with one another macroses (DO .. DONE). To work correctly there must be 2
> counters: one for the sequential pairs and one for the nested pairs in each
> sequential one. These counters allow generating unique labels in each pair.
> Current macro language including altmacro features looks weak to be happy
> with it. I have paid a lot of time to find a decision. Could you show me an
> example how it is possible to do without patching even if it looks ugly?.

I'm sorry, but no, I simply lack the time to invest into putting together
something I'm never going to use.

>> Furthermore ...
>>
>>>     .macro DO
>>>         LABEL_DO\(++DO)_start:
>>
>> ... while this syntax may indeed have a low chance of colliding with
>> anything people already use (simply because it is pretty unlikely
>> for anyone to use two + in a row), ...
>>
>>>     .endm
>>>
>>>     .macro DO_WHILE cond
>>>             j\cond LABEL_DO_WHILE\@continue
>>>             jmp LABEL_DONE\(DO)_end
>>
>> ... this is a problem: There's nothing wrong with somebody having a
>> construct like this in an existing macro, while at the same time
>> also having a macro somewhere with the name DO. If you wanted to
>> extend the language, you would need to make sure that this cannot
>> break existing code.
>>
> 
> There seems to be no new problem here. Macro conflicts can be resolved by
> scope area, etc.

How is

	.macro DO
	.endm

	.macro M pfx:req, sfx:req
\pfx\(DO)\sfx:
	.endm

suddenly changing behavior not a new problem? In what you propose
nothing in M identifies that \(DO) is meant to reference DO's local
counter. Right now the DO there is substituted in literally.

Jan