Submission: while / break / end while

Index > Compiler Internals > Submission: while / break / end while

Goto page Previous 1, 2, 3 Next

Author

Thread

Matrix

Joined: 04 Sep 2004
Posts: 1166
Location: Overflow

Matrix 29 Jul 2005, 09:42

if you have time you could add

'if ##'
{} else {} endif

'for tmp:=# (down)to ##'
{} ;begin end

'repeat'
;code
'until keypressed or ... '

and 'while ##'
{} ; begin end

to code generation too ;>

it whould be as high level asm Smile

29 Jul 2005, 09:42

MCD

Joined: 21 Aug 2004
Posts: 602
Location: Germany

MCD 29 Jul 2005, 09:49

I think we already have if ... elseif ... else ... end if in fasm, don't we?

29 Jul 2005, 09:49

Matrix

Joined: 04 Sep 2004
Posts: 1166
Location: Overflow

Matrix 29 Jul 2005, 09:54

sorry i say again:

for code generation, not just internal,
ex.: put for loop with variable in compiled program...

29 Jul 2005, 09:54

Tomasz Grysztar

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

Tomasz Grysztar 29 Jul 2005, 10:15

It's a matter of improving the IF.INC macros Wink

The "match" directive should allow to parse even the complex conditional expressions.

29 Jul 2005, 10:15

Tomasz Grysztar

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

Tomasz Grysztar 29 Jul 2005, 17:37

That's funny that actually any "repeat" can be simply rewritten using "while":

Code:

while %<=count ; the same as "repeat count"
end while

but it's good to have them both for better readability.

29 Jul 2005, 17:37

revolution
When all else fails, read the source

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

revolution 30 Jul 2005, 00:30

Code:

macro end type* {
        local j
        j equ type
        match =repeat,j \{j equ while\}
        end j
}
macro repeat count {while %<=count}

30 Jul 2005, 00:30

Tomasz Grysztar

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

Tomasz Grysztar 30 Jul 2005, 06:52

As for the redundant directives, I'm also considering adding the "for" directive in preprocessor (named after analoguous one in MASM), something like:

Code:

for param,1,2,3
{
; some code repeated for 1,2,3 values of param
; (forward, common and reverse directives allowed in usual meaning)
}

It can be described by the equivalent code done with current features:

Code:

macro a [param]
{
; the repeated code
}
match values,1,2,3 { a values }

but the "for" would make it much simpler. What do you think?

30 Jul 2005, 06:52

Tomasz Grysztar

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

Tomasz Grysztar 30 Jul 2005, 07:13

revolution wrote:

Code:

macro end type* {
        local j
        j equ type
        match =repeat,j \{j equ while\}
        end j
}
macro repeat count {while %<=count}

Simpler would be just:

Code:

repeat equ while
macro repeat count {while %<=count}

(reading manual section 2.3.7 highly recommended)
However these both emulations don't detect errors of blocks not closed in correct order.

30 Jul 2005, 07:13

revolution
When all else fails, read the source

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

revolution 30 Jul 2005, 10:57

Quote:

repeat equ while

okay, yeah, silly me, hehe.

Quote:

the "for" would make it much simpler. What do you think?

I think that is a good idea.

30 Jul 2005, 10:57

Matrix

Joined: 04 Sep 2004
Posts: 1166
Location: Overflow

Matrix 30 Jul 2005, 11:43

Tomasz Grysztar wrote:

As for the redundant directives, I'm also considering adding the "for" directive in preprocessor (named after analoguous one in MASM), something like:
Code:
for param,1,2,3
{
; some code repeated for 1,2,3 values of param
; (forward, common and reverse directives allowed in usual meaning)
}    
It can be described by the equivalent code done with current features:
Code:
macro a [param]
{
; the repeated code
}
match values,1,2,3 { a values }    
but the "for" would make it much simpler. What do you think?

hm
i think its a good idea too, but named something else,
for should be like in other languages
basically structure

Code:

for var=startvalue (down)to endvalue
{
mov ax,var
...
}

this way it is more comfortable to do example

Code:

for x1=0 to 319 {
for y1=0 to 199 {
plotpixel(x1,y1,100)
}
}

30 Jul 2005, 11:43

Tomasz Grysztar

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

Tomasz Grysztar 30 Jul 2005, 11:48

Look at the "for" in MASM. We should rather look at the syntax of other assemblers, not entirely different languages. What you wrote about is done in assemblers by the "rept"/"repeat" directives.

BTW, Bourne shell also uses syntax like "for i in 1 2 3 4 5" - there might be examples in other languages, too.

30 Jul 2005, 11:48

Tomasz Grysztar

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

Tomasz Grysztar 30 Jul 2005, 12:11

I have also an idea of more powerful syntax like that. Before the name of looping parameter the separator character would be specified. For example:

Code:

for ,a 1,2,3
{ }
for :a 1:2:3
{ }
for a 1 2 3
{ }

all would do the same thing.

I've got however problem with the grouping arguments. One would expect that

Code:

for ,a  1,<2,3>
{ }

will loop through two values, first "1" and then "2,3". But then also

Code:

for a 1<2 3>
{ }

would do the same thing. And this one

Code:

for <a 1<<2 3>
{}

begins a headache.

The other way would be to not allow grouping and just simply split parameters with given separator. Thus:

Code:

for ,a 1,<2,3>
{}

Would loop through "1", "<2" and "3>" values. But this would not be comforming to macroinstruction behavior. On the other hand, you could pass the list to macroinstruction if you needed such grouping and use "for" for raw splitting.

It's just a couple of rough ideas. What is your opinion?

30 Jul 2005, 12:11

tom tobias

Joined: 09 Sep 2003
Posts: 1320
Location: usa

tom tobias 30 Jul 2005, 15:27

Tomasz Grysztar wrote:

I have also an idea of more powerful syntax....Thus:
Code:
for ,a 1,<2,3>
{}    
Would loop through "1", "<2" and "3>" values. But this would not be comforming to macroinstruction behavior. On the other hand, you could pass the list to macroinstruction if you needed such grouping and use "for" for raw splitting.

It's just a couple of rough ideas. What is your opinion?

I think it is the exact opposite of what is useful: Clarity, simplicity, readability. You are substituting CODE, something you and a few others know, for PROGRAMMING. In essence you seek to return to the days of Telegraphs, using a sequence of dots and dashes to specify letters of the alphabet. NONSENSE. Enough with the code. Need to improve READABILITY, not further promote BREVITY. Next thing you know, there will be secret handshakes and even assorted sequences of smileys to signal special meaning that only a select few can comprehend. Sad

30 Jul 2005, 15:27

revolution
When all else fails, read the source

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

revolution 30 Jul 2005, 16:22

I think the comma separator is enough and allow for grouping inside <>. This is adequate for the macros and i think also adequte for FOR.

Code:

for a 2,6,0 {
mov eax,a
...
}

Is nice.

However, perhaps extensions could be like this:

Code:

for a,b,c <2,6,0>,<1,2,3> {
mov eax,a
mov ebx,b
mov ecx,c
...
}

Three variables used in the braces, a, b and c take the values a=2, b=6, c=0 on the first instance and a=1, b=2, c=3 on the second instance.

30 Jul 2005, 16:22

Tomasz Grysztar

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

Tomasz Grysztar 30 Jul 2005, 17:56

I think that to be analoguous to standard macro, it would have to be:

Code:

for a,b,c 2,6,0,1,2,3

I was considering allowing custom separator, because such feature would actually be very useful in my "proc" macro - currently I have to use recursive macros and "match" to split the list of registers.

I would either go with the sophisticated syntax construct (like I did with "match" directive) to give it wide abilities, or otherwise the most simple syntax (like "for a 1,2,3") to focus on simplicity and readability. I will leave it to be re-thought after the 1.64 - for now I have enough work documenting already existing features.

30 Jul 2005, 17:56

Frank

Joined: 17 Jun 2003
Posts: 100

Frank 31 Jul 2005, 07:52

Tomasz Grysztar wrote:

I will leave it to be re-thought after the 1.64 - for now I have enough work documenting already existing features.

Great

At the moment I don't fully comprehend the advantages and disadvantages of the various options. But the criterion: "We should rather look at the syntax of other assemblers, not entirely different languages" seems to signal that hard and binding decisions should not be made at present. That is because the criterion emphasises convention ("other assemblers do it") over stringence ("it is the best way of doing it").

Sorry if I misunderstood.

Regards

Frank

31 Jul 2005, 07:52

Tomasz Grysztar

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

Tomasz Grysztar 31 Jul 2005, 08:19

I meant that fasm already implements the REPT/REPEAT similarly to other assemblers, which does what Matrix expected to be done with FOR. This implies that to be consistent, fasm should either don't have any FOR at all (since REPT/REPEAT already do it for us), or implement it following the same path. Also, why do you assume that convention is not "the best way to do it"? Actually I would consider that if something is a convention, there is a high probability that it's a very good solution, verified by the time.

31 Jul 2005, 08:19

tom tobias

Joined: 09 Sep 2003
Posts: 1320
Location: usa

tom tobias 31 Jul 2005, 12:23

Tomasz Grysztar wrote:

... why do you assume that convention is not "the best way to do it"? Actually I would consider that if something is a convention, there is a high probability that it's a very good solution, verified by the time.
...

I doubt that it was Frank's intention to mention convention pejoratively.
Here's my take: Frank is properly challenging the notion that one is correct in offering to engage in some activity SIMPLY because it has always been done that way. FASM is a revolutionary tool. It offers capabilities unmatched by any other assembler. It has no peer. There is nothing intrinsically wrong or right with following convention. However, Tomasz' argument that JUST BECAUSE something has been done for a very long time, apparently successfully, justifies the CONTINUED practice with this well established tradition, is incorrect, in my opinion.
Whether astronomy, gene therapy for "incurable" diseases, or mathematics, there are MANY illustrations in all aspects of life where conformance to a tradition, sometimes dating back 2000 years, or more (in the case of Chinese building walls to keep people out!) is obsolete, and no longer functions effectively to guide our current behaviour. FASM has evolved since its debut. Now, a couple years later, a little more robust, a bit more mature, FASM's users seek additional features. This is natural. It is not a bad or good attribute, to offer CHANGE. It is practical. Without a lot of effort by some dedicated people, MASM, for instance, would not be still employed by anyone, after Microsoft abandoned it a decade ago. Assemblers need maintenance, modification, and improvement. So do we all. Smile

31 Jul 2005, 12:23

Tomasz Grysztar

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

Tomasz Grysztar 31 Jul 2005, 12:33

I agree, as you can see in my thought above I was actually thinking on how to improve the potential FOR syntax to make it better. However the point of mentioning the convention was that after having implemented other directives in the way I have done it, I have to try to follow it as consistently as possible when adding new ones. The fact that REPT is already implemented (following the TASM's convention) to do what in some other languages is sometimes called FOR, implied that implementing the FOR in such meaning would be pointless. And the FOR how is implemented in MASM is an example of nicely supplementing this convention, thus after already following it for the REPT I see it quite natural to consistently continue following it as a base for additional features - that doesn't mean I wouldn't want to seek improved solutions, however starting from consistent base will make it all less confusing and more justifiable.

It was not my intention to make an impression that convention is more important that making better solutions. Matrix mentioned the convention from some completely different languages and I pointed out the other convention which I followed - you in my place would perhaps argue with Matrix just on the "convention vs. stringence" basis, but I felt it worth to mention the actual convention that I used as a starting point for my design.

31 Jul 2005, 12:33

vid
Verbosity in development

Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia

vid 01 Aug 2005, 07:23

Quote:

The "match" directive should allow to parse even the complex conditional expressions.

any plans to do this?

01 Aug 2005, 07:23

Goto page Previous 1, 2, 3 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