flat assembler
Message board for the users of flat assembler.
![]() Goto page 1, 2, 3, 4 Next |
Author |
|
Tomasz Grysztar 21 Oct 2014, 19:31
I have made a new release with a couple of late tweaks.
First, I decided to get rid of the traditional restriction that disallowed to forward-reference value of numeric constant inside its own definition. I used to think that it would be strange to allow such construction, and that disallowing it would help to catch programmer's mistakes. But finally I came to a conclusion that since fasm will not allow it anyway unless the definition is self-consistent, this is not a big issue. This restriction was implemented with an additional code, so removing it cleans the fasm's source up a little. And the ability to define self-dependent values directly can be used to demonstrate fasm's code resolving philosophy in an even simpler way than before, for instance the equation resolving example can now be presented with one line: Code: x = (x-1)*(x+2)/2-2*(x+1) And there is a small addition of two new unary operators for numerical expressions: the BSF and BSR. They perform the same task as their x86 instruction counterparts. I realized that this can be useful when using some sets of equates that define flags as single bit values (Windows API has many of them, among others). Such constants are usually used with instructions like TEST/OR, but if one wants to use BT/BTS/BTR/BTC instead, the constant needs to be converted into a bit index. Having BSF implemented as operator in fasm does not cost much, but it simplifies code and may ensure that programmer does not calculate bit indexes manually: Code: SOME_FLAG = 800h bts [flags],bsf SOME_FLAG Code: BIT_FIELD_MASK = 0FFF000h dd (value and BIT_FIELD_MASK shr bsf BIT_FIELD_MASK) shl bsf BIT_FIELD_MASK |
|||
![]() |
|
l_inc 22 Oct 2014, 00:10
Tomasz Grysztar
Thank you for allowing forward-referencing within the same expression. It may seem, that this is just a beautification of the architecture, but this improvement has also it's practical value of allowing to stabilize a value of a constant across multiple passes. One simple example is reduction of a number of file accesses during a multipass compilation: Code: if ~defined x virtual file '%comspec%' load x byte from $$ end virtual else x = x end if Such a trick is especially useful if the file is a random number generator (such as "/dev/urandom"). _________________ Faith is a superposition of knowledge and fallacy |
|||
![]() |
|
revolution 22 Oct 2014, 03:10
Perhaps a feature request? Since these new operators are very similar to inline macros can we have more?
Code: MYCONSTANT = 1000 imul eax,MYCONSTANT ;good for integer operands mov [some_float],float MYCONSTANT ;good for float operands also ;instead of mov [some_float],MYCONSTANT ;can't do conversion to float here fild [some_float] fstp [some_float] Code: MYDEFAULT equ 33 imul eax,MYDEFAULT ;good for operations message db 'The default is ',string MYDEFAULT,',13,10 ;good as a string also ;instead of match x, MYDEFAULT {message db 'The default is ',`x,'.;,13,10} ;using the backtick outside of a match only returns 'MYDEFAULT' not '33' |
|||
![]() |
|
shutdownall 22 Oct 2014, 12:44
By the way one question:
Is this feature in the meantime implemented ? "Save Virtual Block as File" http://board.flatassembler.net/topic.php?t=16889&postdays=0&postorder=asc&start=20 Or does this (a previous version) allow forward references to access data with load/store directive, defined in an address space not already compiled (allowed forward references on access of data with load/store) ? |
|||
![]() |
|
Tomasz Grysztar 22 Oct 2014, 12:50
shutdownall wrote: By the way one question: shutdownall wrote: Or does this (a previous version) allow forward references to access data with load/store directive, defined in an address space not already compiled (allowed forward references on access of data with load/store) ? |
|||
![]() |
|
l_inc 22 Oct 2014, 15:27
Tomasz Grysztar wrote: This is not possible with fasm 1.x architecture Well, there's the postpone directive, that together with the constant forward referencing allows that for a large subset of situations. _________________ Faith is a superposition of knowledge and fallacy |
|||
![]() |
|
shutdownall 22 Oct 2014, 16:26
l_inc wrote: Well, there's the postpone directive, that together with the constant forward referencing allows that for a large subset of situations. As I am not experienced right now with the postpone directive, do you think this is a practicable approach to transfer complete codeblocks of up to a few kbytes into another place somewhere in code ? |
|||
![]() |
|
l_inc 22 Oct 2014, 16:48
shutdownall
Quote: do you think this is a practicable approach to transfer complete codeblocks of up to a few kbytes into another place somewhere in code Isn't that, what you were asking for? I'm not sure, if "practicable" is a sort of germanism here. Thus to avoid ambiguity: the transfer is possible, but not really sensible and not really efficient. Regarding the data forward referencing in general, in fact I never met a situation where it's impossible to design co-macros in a way that does not require data forward referencing (warning: triple negation). _________________ Faith is a superposition of knowledge and fallacy |
|||
![]() |
|
shutdownall 22 Oct 2014, 19:08
Okay, thanks. I will take a closer look at this postpone directive then.
|
|||
![]() |
|
str8c 24 Oct 2014, 00:20
I would also like to suggest some features (they may have already been suggested).
1. Macros with a multi-line argument. Many built-in instructions take a multiline block as an argument, it would be fitting if macros could also take a multiline block as an argument. To illustrate: Code: macro proc name, [saveregs], @content { ;here '@' means the argument is a multiline block common name: forward push saveregs common content ;pastes the multiline block here reverse pop saveregs common ret } ;then we can do something like this proc main, rbx { ;some code mov ebx, eax mov eax, ebx } 2. This one is a bit more tricky to implement. Inline macros using a return value or instruction. To illustruate: Code: macro htons x { return (x shr 8) or ((x and 0xFF) shl 8) ;"return" this expression } ;here inline macros are delimited using () ;simple: (htons, 10) gets replaced by the "return value" of the htons macro mov eax, (htons, 10) ;now the tricky part, what happens when the macro has instructions in it? ;answer: the instructions in the macro are inserted above the current instruction, ; (when there more than one inline macro on the same line, the instructions ; are inserted in the order that the macros are "evaluated") ;example macro: macro htons x { local lo, hi lo = (x shr 8) hi = ((x and 0xFF) shl 8) return lo or hi } ;example 1 mov eax, (htons, 10) ;becomes equivalent to lo?0 = (10 shr 8) hi?0 = ((10 and 0xFF) shl 8) mov eax, lo?0 or hi?0 ;example 2 mov eax, (htons, (htons, 10)) or (htons, 20) ;becomes equivalent to ;(htons, 10) is the first that needs to be evaluated lo?0 = (10 shr 8) hi?0 = ((10 and 0xFF) shl 8) ;replace argument by the result of (htons, 10) lo?1 = ((lo?0 or hi?0) shr 8) hi?1 = (((lo?0 or hi?0) and 0xFF) shl 8) lo?2 = (20 shr 8) hi?2 = ((20 and 0xFF) shl 8) mov eax, (lo?1 or hi?1) or (lo?2 or hi?2) |
|||
![]() |
|
Tomasz Grysztar 24 Oct 2014, 06:26
str8c wrote: I would also like to suggest some features (they may have already been suggested). str8c wrote: Many built-in instructions take a multiline block as an argument, it would be fitting if macros could also take a multiline block as an argument. |
|||
![]() |
|
l_inc 27 Oct 2014, 14:26
Tomasz Grysztar
Quote: In the definition of macroinstruction the last argument can now be followed by "&" character to indicate that this argument can be filled with all the remaining contents of line that called the macro Could you, please, elaborate on how this feature differs from using a group argument in a common block? _________________ Faith is a superposition of knowledge and fallacy |
|||
![]() |
|
Tomasz Grysztar 27 Oct 2014, 14:46
Another tiny update today. This time I've added support for another special character in the definition of macro arguments. The "&" character after the name of last argument now marks it as "greedy" argument that will swallow all the rest of values in the line containing macro call. This can be useful when you plan to process the syntax with MATCH or IRPS, and perhaps in other specific situation.
As an example, the classic "invoke" macro and its equivalent created with an alternate syntax: Code: macro invoke proc,[arg] { common if ~ arg eq reverse pushd arg common end if call [proc] } macro invoke proc,args& { if ~ args eq irp arg,args \{ reverse pushd arg \} end if call [proc] } Disclaimer: this does not mean that I'm in a middle of some serious development of fasm 1. This is another one of features that I initially came up with when planning for fasm 2, and then I realized that I can introduce it in fasm 1 easily. Over the many years that passed since I started thinking about fasm 2, the designs were repeatedly dropped and started again from scratch, but many of the ideas born in this process were applicable to fasm 1. Some of them required a lot of work but I implemented them anyway - like additional sign extension bit, or addressing space labels*. The ones I implement now are the small knick-knocks that were born on the margins of this whole process and I add them when I see that it is not costly. ____ * If you've ever seen my talk about fasm 2 from fasmcon 2009, these features were mentioned there as planned for fasm 2, not fasm 1. |
|||
![]() |
|
Tomasz Grysztar 27 Oct 2014, 14:57
l_inc wrote: Tomasz Grysztar |
|||
![]() |
|
l_inc 27 Oct 2014, 15:01
Tomasz Grysztar
But... how much of the visual difference is there? I mean, your example: Code: macro invoke proc,args& { if ~ args eq irp arg,args \{ reverse pushd arg \} end if call [proc] } basically differs in a single token from what was possible before: Code: macro invoke proc,[args] { common if ~ args eq irp arg,args \{ \reverse pushd arg \} end if call [proc] } Is the new feature really worth that? Fast processing is good in general, but it's an implementation detail, that seems to be feasible to achieve with the group arguments as well. _________________ Faith is a superposition of knowledge and fallacy |
|||
![]() |
|
Tomasz Grysztar 27 Oct 2014, 15:19
l_inc wrote: Is the new feature really worth that? |
|||
![]() |
|
shutdownall 27 Oct 2014, 15:35
Tomasz Grysztar wrote: This is another one of features that I initially came up with when planning for fasm 2, and then I realized that I can introduce it in fasm 1 easily. Just for information, is there any timeline when we could expect FASM2 ? Is it just an idea what could be done if you would have time enough one day or are you already working on it ? ![]() Last edited by shutdownall on 27 Oct 2014, 15:37; edited 1 time in total |
|||
![]() |
|
Tomasz Grysztar 27 Oct 2014, 15:37
l_inc wrote: Could you, please, elaborate on how this feature differs from using a group argument in a common block? Code: macro tester1 [arg*] { } macro tester2 arg*& { } tester1 , ; error because of empty value tester2 , ; value consist of comma, no error macro tester3 [arg=0] { common db arg } macro tester4 arg=0& { db arg } tester3 , ; default value used, twice tester4 , ; comma is non-empty value, so no default used here |
|||
![]() |
|
Tomasz Grysztar 27 Oct 2014, 16:03
shutdownall wrote: Just for information, is there any timeline when we could expect FASM2 ? What is important, is that I never planned fasm 2 to be compatible with fasm 1. During the years of fasm 1 development I noticed that some of its features have a lot of potential, which I could not fully explore unless I created something completely new. For this reason I focus on the "fasm g" idea now, to emphasize that it is not going to be a direct successor to fasm 1. And I don't even know how interesting may it be to others. But I'm pretty sure that if one day I have it working, I'm going to have a lot of fun with it. ![]() |
|||
![]() |
|
Goto page 1, 2, 3, 4 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.