flat assembler
Message board for the users of flat assembler.
![]() Goto page Previous 1, 2, 3 Next |
Author |
|
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} |
|||
![]() |
|
Tomasz Grysztar 30 Jul 2005, 07:13
revolution wrote:
Simpler would be just: Code: repeat equ while macro repeat count {while %<=count} ![]() However these both emulations don't detect errors of blocks not closed in correct order. |
|||
![]() |
|
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? |
|||
![]() |
|
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: 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) } } |
|||
![]() |
|
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. |
|||
![]() |
|
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? |
|||
![]() |
|
tom tobias 30 Jul 2005, 15:27
Tomasz Grysztar wrote: I have also an idea of more powerful syntax....Thus: 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. ![]() |
|||
![]() |
|
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 ... } 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. |
|||
![]() |
|
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. |
|||
![]() |
|
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 |
|||
![]() |
|
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.
|
|||
![]() |
|
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. ![]() |
|||
![]() |
|
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. |
|||
![]() |
|
vid 01 Aug 2005, 07:23
Quote: The "match" directive should allow to parse even the complex conditional expressions. any plans to do this? |
|||
![]() |
|
Tomasz Grysztar 01 Aug 2005, 08:54
Well, not really. I just wanted to signalize that it's possible to make such macro even someone really wanted to try. But the main problem with such expressions is that generating a good code out of them is actually the same as HLL compiling with optimizations - since this is the assembly language, the low-level solutions (simple "brick" commands) are better in my opinion.
|
|||
![]() |
|
Tomasz Grysztar 01 Aug 2005, 10:24
Nickolay has just reminded me that FOR was earlier called IRP in MASM and it goes in TASM the same way. So maybe better would be to call this IRP? Especially that REPT in MASM has been called REPEAT at the same time when IRP became FOR.
Also there was an IRPC directive to loop through all the characters. With fasm's preprocessor it wouldn't make sense, since it doesn't operate on text - but instead I could implement something like IRPS, which would loop through all the symbols and provide me with that nice symbol splitter I wanted to have for "proc" macro. And thus the IRP would be implemented to go just with the commas and grouped arguments. OK, so it would be like: Code: irp a, 1,2,3 { reverse display `a } ; Will display 321 irps a, eax ebx ecx { xor a,a } Note that the syntax is at the same time very analoguous to "match". I like this solution the most from the all the ideas so far - I even think I will try implementing it now. |
|||
![]() |
|
revolution 01 Aug 2005, 15:49
Can we keep the name FOR, IRP is not nice.
|
|||
![]() |
|
Tomasz Grysztar 01 Aug 2005, 16:29
Well, there are adherents for both of them, however I noticed that by calling it this way I will get it more consisent with TASM-basing principle.
Look at this small juxtaposition (taken from here): Code: MASM 6.1 MASM 5.1/TASM EXTERN EXTRN FOR IRP FORC IRPC REPEAT REPT STRUCT STRUC Since fasm already used EXTRN, REPT and STRUC names for its analogs of those directive, it's natural to choose the IRP over FOR. |
|||
![]() |
|
Nikolay Petrov 01 Aug 2005, 20:00
The assembler is a nice programing language. The symbolically is simple and possible to exchange without create a problems for compiler. My opinion is that it doesn't matter how name it, and what job do it.
in tasm/masm have a very useful macro directives, that make possible to use compilers for create a libraries for HLL. |
|||
![]() |
|
Goto page Previous 1, 2, 3 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2023, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.