flat assembler
Message board for the users of flat assembler.

flat assembler > Main > flat assembler 1.71.23

Goto page 1, 2, 3, 4  Next
Author
Thread Post new topic Reply to topic
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7064
Location: Kraków, Poland
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    
This new feature may also be helpful when operating on bit field equates:
Code:
BIT_FIELD_MASK = 0FFF000h

        dd      (value and BIT_FIELD_MASK shr bsf BIT_FIELD_MASK) shl bsf BIT_FIELD_MASK    
Post 21 Oct 2014, 19:31
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: 16226
Location: The West Pole
Using BSF and BSR is nice and saves me some coding. I usually do this:
Code:
MYFLAG_BIT      = 4
MYFLAG_MASK     = 1 shl MYFLAG_BIT    
However BSR/BSF are very specific to x86. People using Z80, ARM, MIPS etc. might find it a bit strange.
Post 21 Oct 2014, 19:45
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
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
Post 22 Oct 2014, 00:10
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16226
Location: The West Pole
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]    
And what about this:
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'    
Post 22 Oct 2014, 03:10
View user's profile Send private message Visit poster's website Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 518
Location: Munich
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) ?
Post 22 Oct 2014, 12:44
View user's profile Send private message Send e-mail Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7064
Location: Kraków, Poland
shutdownall wrote:
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
No, I left it for an unspecified future. Currently I'm doing only some small tweaks while I work on the fasm 2 design.

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) ?
This is not possible with fasm 1.x architecture.
Post 22 Oct 2014, 12:50
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
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
Post 22 Oct 2014, 15:27
View user's profile Send private message Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 518
Location: Munich
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 ?
Post 22 Oct 2014, 16:26
View user's profile Send private message Send e-mail Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
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
Post 22 Oct 2014, 16:48
View user's profile Send private message Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 518
Location: Munich
Okay, thanks. I will take a closer look at this postpone directive then.
Post 22 Oct 2014, 19:08
View user's profile Send private message Send e-mail Reply with quote
str8c



Joined: 14 Oct 2014
Posts: 8
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)    
Post 24 Oct 2014, 00:20
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7064
Location: Kraków, Poland
str8c wrote:
I would also like to suggest some features (they may have already been suggested).
The suggestions for inline macros have been repeatedly rejected over the years, as it does not fit into my idea of assembly language (some general formulation could look like: one statement is one instruction; and macroinstruction is just an user-defined instruction). I never perceived it to be tricky to implement, if I wanted it I probably could have it since the early versions. But I continue to defend fasm's right to be different in this aspect. I have not included this in the Design Principles, perhaps I should have.

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.
By "built-in instructions" you perhaps mean some of the preprocessor directives like REPT, IRP or MATCH, which are themselves macroinstructions (just "unnamed" ones). Your suggestion would mean to add the ability to define something like macroinstruction block when calling a macro - so it would be a different approach to the problem that is now usually solved by using the FIX with closing brace - and it would, in fact, solve it in a much nicer way. I may mark this as a possible future addition into fasm 1 (but, along with some other one, it is going to be left for an unspecified time in the future, no sooner than 1.73.x line).
Post 24 Oct 2014, 06:26
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
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
Post 27 Oct 2014, 14:26
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7064
Location: Kraków, Poland
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] }    
There is one minor break of backward-compatibility: if you have argument with a default value containing "&" character, you now need to enclose it with "<" and ">" to avoid "&" being interpreted as a use of this new feature.

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.
Post 27 Oct 2014, 14:46
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7064
Location: Kraków, Poland
l_inc wrote:
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?
The difference is mainly visual. The processing may be a tiny little bit faster with "&" and that's all, I think.
Post 27 Oct 2014, 14:57
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
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
Post 27 Oct 2014, 15:01
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7064
Location: Kraków, Poland
l_inc wrote:
Is the new feature really worth that?
Its implementation was really cheap, and I aimed here at introducing an alternate syntax that may one day become more important. Nothing really important right now, it is more like a tiny "probe" sent to investigate new areas.
Post 27 Oct 2014, 15:19
View user's profile Send private message Visit poster's website Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 518
Location: Munich
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 ? Wink


Last edited by shutdownall on 27 Oct 2014, 15:37; edited 1 time in total
Post 27 Oct 2014, 15:35
View user's profile Send private message Send e-mail Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7064
Location: Kraków, Poland
l_inc wrote:
Could you, please, elaborate on how this feature differs from using a group argument in a common block?
There are also some very subtle differences related to empty values and comma placement:
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    
Post 27 Oct 2014, 15:37
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7064
Location: Kraków, Poland
shutdownall wrote:
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 ? Wink
I hinted at the current state of matters in the other thread recently. And then I updated the terminology. The "fasm g" is in a design stage - I have a stack of notes where the definitions of a new language are intertwined with implementation schemes. This year I started the design from scratch again - many times before I had to abandon it after arriving at contradictions which showed that my initial assumptions were not consistent. It is a bit like solving an equation - I have a set of essential features that I really want to have there, and a larger set of features that want to have in one form or another, and I need to define them all in such a form, that they can work with each other and not contradict themselves.

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. Wink
Post 27 Oct 2014, 16:03
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2, 3, 4  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-2019, Tomasz Grysztar.

Powered by rwasa.