[fasmg] Would a change to iterate be better?

Index > Programming Language Design > [fasmg] Would a change to iterate be better?

Author

Thread

bitRAKE

Joined: 21 Jul 2003
Posts: 3067
Location: vpcmipstrm

bitRAKE

Proposed change:

iterate should ignore trailing comma,

iterate A,
end iterate

...would not loop with A="". To do that would require:

iterate A,,
end iterate

This change would follow list definitions in many other languages and parallels whitespace-separated lists - trailing whitespace is not another item.

Present functionality has no way to iterate zero times without additional branching. Copy-Paste of lists always requires post paste editing when trailing item is modified.

repeat instruction already follows a zero-based pattern. So, this change would seem to align the functionality in fasmg.

How would it effect the existing code? Only the empty case would need to be changed.

_________________
¯\(°_o)/¯ unlicense.org

25 May 2020, 10:29

Tomasz Grysztar

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

Tomasz Grysztar

This specific trait was inherited from fasm 1, where IRP was supposed to behave similarly to a macro with repeated argument - this is why it was chosen that it should behave analogously to such macro and always process at least a single argument, even if empty one. Similarly macros in fasm 1 treat the additional comma at the end always as adding additional empty argument.

In general, I'm very reluctant to consider any backward-compatibility breaking changes at this point (otherwise I would be attempting changes to what I consider "not the best choices" in some other areas, which I would consider even more important - but still not important enough to consider breaking existing source bases now).

However, if we could be fairly sure that iteration over an empty item at the end of list is not really used anywhere (it is quite conceivable), this might be something to consider. Because yes, I believe that what you proposed would be unarguably better. There might be a small problem in case when there are multiple iterated parameters, but it should be solvable.

25 May 2020, 10:46

Tomasz Grysztar

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

Tomasz Grysztar

I prepared a patch, please test it if you have an opportunity:

Code:

--- source/directives.inc
+++ source/directives.inc
@@ -1843,31 +1843,35 @@
       iterator_parameters_declared:
        cmp     al,','
        jne     invalid_iterator
        mov     eax,[number_of_parameters]
        mov     [number_of_values],eax
-       xor     eax,eax
        mov     [value_index],eax
-       inc     eax
-       mov     [number_of_iterations],eax
+       and     [number_of_iterations],0
       collect_iterator_values:
        inc     esi
+       call    move_to_next_symbol
+       jc      initialize_iterator
        mov     edx,expression_workspace
        mov     ecx,sizeof.LineExcerpt
        call    reserve_workspace
        call    cut_argument_value
        add     edi,sizeof.LineExcerpt
        inc     [number_of_values]
        mov     ecx,[value_index]
-       sub     ecx,[number_of_parameters]
-       jc      iterator_value_collected
-       mov     [value_index],ecx
+       cmp     ecx,[number_of_parameters]
+       jne     iterator_value_collected
        inc     [number_of_iterations]
+       xor     ecx,ecx
       iterator_value_collected:
-       inc     [value_index]
+       inc     ecx
+       mov     [value_index],ecx
        cmp     al,','
        je      collect_iterator_values
+      initialize_iterator:
+       cmp     [number_of_iterations],0
+       je      inactive_iterator_block
        mov     dl,DBLOCK_CONTROL
        mov     ecx,5+sizeof.RepeatData
        call    add_directive_block
        mov     [edi+DirectiveBlock.subtype],CTRL_IRP
        or      [edi+DirectiveBlock.flags],CTRLF_BREAKABLE + CTRLF_HAS_REPEAT_DATA + CTRLF_HAS_WRITABLE_INDEX

I'm going to continue testing it myself on all fasmg projects that I can find - if it does not break anything, I may apply it to the trunk.

25 May 2020, 12:26

Tomasz Grysztar

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

Tomasz Grysztar

I tested many projects and it seems that this change is completely safe, I have not found a single source text that would actually rely on this behavior - which is yet another argument for this being a good change.

I'm going to just include this change in the official version then. Thank you for bringing it up! I was myself too stuck in "compatibility" thinking to notice this - nearly free - opportunity.

Also, this brings more symmetry between IRP and IRPV. And to iterate over an empty argument you can still do it like:

Code:

iterate A,<>

in addition to the double-comma variant you mentioned.

25 May 2020, 17:28

bitRAKE

Joined: 21 Jul 2003
Posts: 3067
Location: vpcmipstrm

bitRAKE

I don't expect you to entertain any of my crazy ideas, but this one seemed reasonable. Like I think all the legacy data sizes should go away, lol. The quick reply is awesome and works well.

_________________
¯\(°_o)/¯ unlicense.org

26 May 2020, 03:06

bitRAKE

Joined: 21 Jul 2003
Posts: 3067
Location: vpcmipstrm

bitRAKE

I'm writing a script to extract all the instructions from your implementation of x86:

Code:

file                    lines   labels

assembler.inc           3288    334
calm.inc                2343    222
conditions.inc           655     85
console.inc              331     44
directives.inc          4912    497
errors.inc               224     20
expressions.inc         4130    489
floats.inc              1165    115
map.inc                  227     27
messages.inc              52      0
output.inc               728     77
reader.inc               442     40
symbols.inc             1511    157
tables.inc               419      2
variables.inc            261      0
version.inc                1      0

80186.inc                317     51
80286.inc                 73      9
80287.inc                 10      0
80386.inc               2337    417
80387.inc                129     14
80486.inc                 52      5
8086.inc                1324    240
8087.inc                 502     76
p5.inc                    30      3
p6.inc                    51      5
x64.inc                 3030    554

adx.inc                   20      0
aes.inc                   28      0
avx2.inc                 448     26
avx512_4vnniw.inc         25      0
avx512_bitalg.inc         21      0
avx512bw.inc             404      0
avx512cd.inc              19      0
avx512dq.inc             390      0
avx512er.inc              30      0
avx512f.inc             2363    116
avx512_ifma.inc            8      0
avx512.inc                 7      0
avx512pf.inc              53      0
avx512_vbmi2.inc          44      0
avx512_vbmi.inc           13      0
avx512vl.inc               4      0
avx512_vnni.inc            8      0
avx512_vpopcntdq.inc       8      0
avx.inc                 1082     40
bmi1.inc                  88      0
bmi2.inc                  95      0
cet_ibt.inc                5      0
cet_ss.inc                88      0
f16c.inc                  26      0
fma.inc                   19      0
fsgsbase.inc              20      0
gfni.inc                  34      0
hle.inc                   11      0
invpcid.inc               13      0
mmx.inc                  132     16
movdir64b.inc             20      2
movdiri.inc               17      0
mpx.inc                  182      2
pclmulqdq.inc              9      0
ptwrite.inc               17      0
rdrand.inc                 9      0
rdseed.inc                 9      0
rdtscp.inc                 3      0
rtm.inc                   35      0
smx.inc                    3      0
sse2.inc                 551     10
sse3.inc                  64      0
sse4.1.inc               189      0
sse4.2.inc                49      0
sse.inc                  389     12
ssse3.inc                 23      0
vaes.inc                  26      0
vmx.inc                   56      0
vpclmulqdq.inc            25      0
xsave.inc                 29      0

...the relative number of labels kind of indicate calm conversion rate.

26 May 2020, 05:18

Tomasz Grysztar

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

Tomasz Grysztar

bitRAKE wrote:

I don't expect you to entertain any of my crazy ideas, but this one seemed reasonable. Like I think all the legacy data sizes should go away, lol.

This one is not even that crazy, they really should have been just a header file. But then most of the existing projects would need to additionally include such file to work. And, anyway, they can be re-defined and overridden easily (although if they were in a header file, they could be defined with ":=" then).

bitRAKE wrote:

I'm writing a script to extract all the instructions from your implementation of x86:

When I was converting the instructions to CALM, I had been using this simple trick to gather information on which of the instructions that are still not converted are used the most:

Code:

macro calminstruction?.display?! any&
end macro    

macro macro?! declaration&
        esc macro declaration
        display `declaration,10
end macro

It helped me prioritize the conversions.

26 May 2020, 08:17

bitRAKE

Joined: 21 Jul 2003
Posts: 3067
Location: vpcmipstrm

bitRAKE

Clever, extrapolating I came up with:

Code:

macro display? D&
        db `D,13,10
end macro

calminstruction calminstruction?! text&
        local B
        match B,text
        jno done
        arrange B,=display B
        assemble B
done:
        arrange B,=calminstruction text
        assemble B
end calminstruction

...for the others. Couple things to weed out, but the lists look good and take advantage of the groupings you've made.

_________________
¯\(°_o)/¯ unlicense.org

26 May 2020, 12:31

bitRAKE

Joined: 21 Jul 2003
Posts: 3067
Location: vpcmipstrm

bitRAKE

This is the stub.inc, I prepended to each file:

Code:

if __source__=__file__
macro display? D&
if __source__=__file__
        db `D,13,10
end if
end macro

macro macro?! all&
if __source__=__file__
        display all
end if
        esc macro all
end macro

macro calminstruction?.asmcmd? pattern&
        local   cmd
        arrange cmd, pattern
        assemble cmd
end macro

calminstruction calminstruction?! text&
        local B
        match B,text
        jno done
        arrange B,=display B
        assemble B
done:   arrange B,=calminstruction text
        assemble B
end calminstruction
end if

...and the batch file:

Code:

@ECHO OFF
:: depenancy chain requires these steps to be
:: preformed separately
SET BASEPATH="C:\fasmg\packages\x86\include\cpu\"
:: merge stub to each file
FOR /R %BASEPATH% %%G IN (*.inc) DO (
        copy /b .\stub.inc + %%G .\%%~nG.inc
)
:: then process them
FOR /R %BASEPATH% %%G IN (*.inc) DO (
        fasmg .\%%~nG.inc
)
:: remove temp files
FOR /R %BASEPATH% %%G IN (*.inc) DO (
        del .\%%~nG
)
ECHO ON

...x64.inc is the black sheep of the bunch as it's the only one needing files in \ext. And then there's mmx.inc needing asmcmd. So many paths lead to it that I've added it to the stub. Too lazy to code an include fix for x64.inc - I did that one manually.

_________________
¯\(°_o)/¯ unlicense.org

26 May 2020, 14:30

< 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