flat assembler
Message board for the users of flat assembler.

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

Goto page Previous  1, 2, 3  Next
Author
Thread Post new topic Reply to topic
Matrix



Joined: 04 Sep 2004
Posts: 1171
Location: Overflow
Matrix
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
Post 29 Jul 2005, 09:42
View user's profile Send private message Visit poster's website Reply with quote
MCD



Joined: 21 Aug 2004
Posts: 604
Location: Germany
MCD
I think we already have if ... elseif ... else ... end if in fasm, don't we?
Post 29 Jul 2005, 09:49
View user's profile Send private message Reply with quote
Matrix



Joined: 04 Sep 2004
Posts: 1171
Location: Overflow
Matrix
sorry i say again:

for code generation, not just internal,
ex.: put for loop with variable in compiled program...
Post 29 Jul 2005, 09:54
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
It's a matter of improving the IF.INC macros Wink
The "match" directive should allow to parse even the complex conditional expressions.
Post 29 Jul 2005, 10:15
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
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.
Post 29 Jul 2005, 17:37
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17717
Location: In your JS exploiting you and your system
revolution
Code:
macro end type* {
        local j
        j equ type
        match =repeat,j \{j equ while\}
        end j
}
macro repeat count {while %<=count}    
Post 30 Jul 2005, 00:30
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
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?
Post 30 Jul 2005, 06:52
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
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}    

Wink (reading manual section 2.3.7 highly recommended)
However these both emulations don't detect errors of blocks not closed in correct order.
Post 30 Jul 2005, 07:13
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17717
Location: In your JS exploiting you and your system
revolution
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.
Post 30 Jul 2005, 10:57
View user's profile Send private message Visit poster's website Reply with quote
Matrix



Joined: 04 Sep 2004
Posts: 1171
Location: Overflow
Matrix
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)
}
}
    
Post 30 Jul 2005, 11:43
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
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.
Post 30 Jul 2005, 11:48
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 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?
Post 30 Jul 2005, 12:11
View user's profile Send private message Visit poster's website Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
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
Post 30 Jul 2005, 15:27
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17717
Location: In your JS exploiting you and your system
revolution
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.
Post 30 Jul 2005, 16:22
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 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.
Post 30 Jul 2005, 17:56
View user's profile Send private message Visit poster's website Reply with quote
Frank



Joined: 17 Jun 2003
Posts: 100
Frank
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 Very Happy

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
Post 31 Jul 2005, 07:52
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7802
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 31 Jul 2005, 08:19
View user's profile Send private message Visit poster's website Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
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
Post 31 Jul 2005, 12:23
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7802
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 31 Jul 2005, 12:33
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Quote:
The "match" directive should allow to parse even the complex conditional expressions.

any plans to do this?
Post 01 Aug 2005, 07:23
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
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


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.