flat assembler
Message board for the users of flat assembler.

Index > Main > flat assembler 1.69

Author
Thread Post new topic Reply to topic
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7709
Location: Kraków, Poland
Tomasz Grysztar
The new development line has been started with the release of 1.69.00 today. I'm starting with some experimental features - first, some rearrangements in core code, that allowed to break the 64K barrier for DOS unREAL mode version (yes, I still don't plan to get rid of it).

And the true new feature is the extension of REPT directive, which is my attempt to compensate the inabilities of fasm's preprocessor to deal with numerical calculations. Now REPT directive is able to pre-calculate numerical expressions given in its arguments. Since it is done at the preprocessing stage, only numbers known at this stage can be used in such expression. However, you can use any symbolic variable in the expression, and the contents of this variable will get pre-calculated as well, and its value will be substituted into the expression.

It may sound complicated, but it's actually quite simple - let's go to some examples. The simplest one:
Code:
rept 2+3
{
 nop
}    
The preprocessor of 1.69 is now able to calculate this expression and produce 5 copies of the block (5 NOP instructions in this case).
The expression will also be calculated if placed as a base for counter, and this allows to use REPT in a different way, to simply compute some value:
Code:
rept 1 x:1+(3+5) shl 1
{
 label#x:
}    
This will create definition of "label17" label.

And now some example with use of symbolic variables substitution:
Code:
define a 2
define b a+3

rept 1 x:a*b
{
 define my_value x
}    
This is going to define "my_value" with value "10". Note that value for each symbolic variable is pre-calculated before substituting it into expression.

And now some small clever macro to ease doing the calculations on symbolic variables:
Code:
macro precalc var,expr { rept 1 _tmp_:expr \{ define var _tmp_ \} }

define a 2+3
define b 2*a

precalc my_value,b ; same effect as "define my_value 10"    

However, be careful, when using the EQU directive. Like here:
Code:
macro precalc var,expr { rept 1 _tmp_:expr \{ define var _tmp_ \} }

a equ 2+3
b equ 2*a ; this defines "2*2+3" value

precalc my_value,b ; same effect as "define my_value 7"    
Post 24 Jun 2009, 21:55
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
This is really interesting and will be very useful, especially for calculating stuff in the preprocessor with rept 1 expr Smile

I have a suggestion, I'm not sure how reasonable it is, but here goes:

sometimes with very deep nesting, it becomes less clear to use so many '\\\\' in preprocessor when escaping certain special directives or {} characters.

Can't you just count the number of '{' used and use that as the default for any such nesting directive? Of course you can still nest them manually, which is useful in certain situations. But those are few exceptions and it would make code much clearer if you didn't have to do it normally.

For instance:
Code:
macro foo
{
  match any, bar
  \{
    ; ...
  \}
}    
could be
Code:
macro foo
{
  match any, bar
  {
    ; ...
  }
}    
and
Code:
macro foo
{
  match any, bar
  {
    local var
  }
}    
would be equivalent with:
Code:
macro foo
{
  match any, bar
  \{
    \local var
  \}
}    


However, if you want to make local part of the original macro nesting, obviously using '\' will not work, e.g this will do nothing:
Code:
macro foo
{
  match any, bar
  {
    \local var
  }
}    


so we have to come up with something else, like for instance '\/' symbols to represent no '\' at all, or you can just use a number after the '\' representing how many there are, like:

Code:
macro foo
{
  match any, bar
  {
    \0local var
  }
}    
would be equivalent to:
Code:
macro foo
{
  match any, bar
  \{
    local var
  \}
}    


what do you say? is it possible to keep count of them?

_________________
Previously known as The_Grey_Beast
Post 24 Jun 2009, 23:31
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7709
Location: Kraków, Poland
Tomasz Grysztar
Borsuc wrote:
However, if you want to make local part of the original macro nesting, obviously using '\' will not work, e.g this will do nothing:
Yes, this is the first problem - for instance you have to be able to use the "#" operator at all levels anytime. If it was context-dependent like you propose, there would be needed some kind of anti-\ operator to get "#" operator of outer macros.

And the second problem is that pairing braces would break a feature of fasm's macros that exactly depends on braces not having to be paired. Check out the "tmacro" example at the end of section 2.3.3 in the manual.
Post 25 Jun 2009, 05:59
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2887
Location: [RSP+8*5]
bitRAKE
Tomasz, it is not as direct a solution as one would imagine - in fact, I see no syntactic symmetry at all - I like it! Very Happy
Post 25 Jun 2009, 06:17
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
nice idea, for your style: to add most functionality by adding least syntax features Smile
Post 25 Jun 2009, 12:24
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7709
Location: Kraków, Poland
Tomasz Grysztar
Version 1.69.01 is a direct response to the report given by MazeGen recently. At the same time I'm updating the Win32 includes and Win32 IDE, also in the 1.68 package (but this is probably the last update of IDE with 1.68 core, because I'm soon going to implement some new features into IDE using the changes I've made in 1.69 core).
FASMW is now auto-initializing the INCLUDE variable in case, when no .INI file has yet been created - as it was already suggested many times. I could think of something even more clever, but it's already late today. Wink
Post 01 Jul 2009, 22:49
View user's profile Send private message Visit poster's website Reply with quote
SFeLi



Joined: 03 Nov 2004
Posts: 140
Location: Severodvinsk, Russia
SFeLi
Thank you! Smile
Post 02 Jul 2009, 08:18
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7709
Location: Kraków, Poland
Tomasz Grysztar
Version 1.69.02 comes only with a few small bugfixes, however at the same time the IDEs got updated with new functionality, possible only with the 1.69 core - now both the FASMD and FASMW have the calculator under Ctrl+F6 (another key combination taken from DN Wink). It calculates expression using the same calculator as fasm's core, and presents 64-bit result in a dec, hex, bin and oct variants with option to copy to clipboard.
Post 04 Jul 2009, 20:04
View user's profile Send private message Visit poster's website Reply with quote
madmatt



Joined: 07 Oct 2003
Posts: 1045
Location: Michigan, USA
madmatt
Hi Tomasz,
Thanks a lot for all your hard work on the fasm packages! We really need the 64bit packages now because MS decided to remove the __asm keyword from the 64bit Visual Studio 2008 editions, all assembly must now be done with intrinsics code. All my google searching up to this point hasn't found a way to re-enable it. Has anyone tried to link a 64bit .obj file created with fasmw with some 64bit c code?

_________________
Gimme a sledge hammer! I'LL FIX IT!
Post 04 Jul 2009, 20:37
View user's profile Send private message Reply with quote
Helle



Joined: 24 Feb 2007
Posts: 23
Location: Germany
Helle
Hello,
a problem with the two SSE4.1-instructions BLENDVPD/BLENDVPS (only 64-bit-mode): With a memory-operand is the memory-address 0ffh-bytes too low in the opcode. Please take a look.
Thanks!
Helle
Post 05 Jul 2009, 10:52
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7709
Location: Kraków, Poland
Tomasz Grysztar
Can you clarify? I'm not sure I understand, what the problem is.
Post 06 Jul 2009, 06:13
View user's profile Send private message Visit poster's website Reply with quote
Helle



Joined: 24 Feb 2007
Posts: 23
Location: Germany
Helle
Hello,
First: Sorry for the post in this thread, Compiler Internals is better.
The Problem: I have this Code (e.g.)
Code:
;.....
;only any instructions, no sense!
!blendps xmm1,dqword[T],1
!shufpd xmm13,dqword[T],2 
!blendvpd xmm5,dqword[T],xmm0
!blendvps xmm2,dqword[T],xmm0
!cvtpi2ps xmm7,[T]
!movbe qword[T],rdx
!movlps xmm3,[T]
;.......

!section '.data' Data readable writeable
!T:  dq  ?
!    dq  ?
    

and get this (with my disassember):
Code:
66 0F 3A 0C 0D B1 1F 00 00 01    BLENDPS XMM1 , dqword ptr [ 00 00 00 01 40 00 30 00 ] , 01
66 44 0F C6 2D A7 1F 00 00 02    SHUFPD XMM13 , dqword ptr [ 00 00 00 01 40 00 30 00 ] , 02
66 0F 38 15 2D 9F 1E 00 00       BLENDVPD XMM5 , dqword ptr [ 00 00 00 01 40 00 2F 01 ] , XMM0
66 0F 38 14 15 96 1E 00 00       BLENDVPS XMM2 , dqword ptr [ 00 00 00 01 40 00 2F 01 ] , XMM0
0F 2A 3D 8E 1F 00 00             CVTPI2PS XMM7 , qword ptr [ 00 00 00 01 40 00 30 00 ]
48 0F 38 F1 15 85 1F 00 00       MOVBE qword ptr [ 00 00 00 01 40 00 30 00 ] , RDX
0F 12 1D 7E 1F 00 00             MOVLPS XMM3 , qword ptr [ 00 00 00 01 40 00 30 00 ]
    

Look at the addresses of BLENDVPD and BLENDVPS (also in the opcode)! All other instructions shows the correct address of T (RIP+Offset).
Thanks
Helle
Post 06 Jul 2009, 13:10
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7709
Location: Kraków, Poland
Tomasz Grysztar
Oh, I see now - you forgot to add, that it's in 64-bit mode. Nice catch - fixing now.
Post 06 Jul 2009, 13:49
View user's profile Send private message Visit poster's website Reply with quote
Helle



Joined: 24 Feb 2007
Posts: 23
Location: Germany
Helle
Hey, I wrote "...(only 64-bit-mode)..." Very Happy - works fine now!
Thanks
Helle
Post 07 Jul 2009, 05:15
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< 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.

Powered by rwasa.