flat assembler 1.69

Index > Main > flat assembler 1.69

Author

Thread

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland

Tomasz Grysztar 24 Jun 2009, 21:55

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"

24 Jun 2009, 21:55

Borsuc

Joined: 29 Dec 2005
Posts: 2465
Location: Bucharest, Romania

Borsuc 24 Jun 2009, 23:31

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

24 Jun 2009, 23:31

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland

Tomasz Grysztar 25 Jun 2009, 05:59

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.

25 Jun 2009, 05:59

bitRAKE

Joined: 21 Jul 2003
Posts: 4060
Location: vpcmpistri

bitRAKE 25 Jun 2009, 06:17

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

25 Jun 2009, 06:17

vid
Verbosity in development

Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia

vid 25 Jun 2009, 12:24

nice idea, for your style: to add most functionality by adding least syntax features Smile

25 Jun 2009, 12:24

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland

Tomasz Grysztar 01 Jul 2009, 22:49

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

01 Jul 2009, 22:49

SFeLi

Joined: 03 Nov 2004
Posts: 138

SFeLi 02 Jul 2009, 08:18

Thank you! Smile

02 Jul 2009, 08:18

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland

Tomasz Grysztar 04 Jul 2009, 20:04

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.

04 Jul 2009, 20:04

madmatt

Joined: 07 Oct 2003
Posts: 1045
Location: Michigan, USA

madmatt 04 Jul 2009, 20:37

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!

04 Jul 2009, 20:37

Helle

Joined: 24 Feb 2007
Posts: 23
Location: Germany

Helle 05 Jul 2009, 10:52

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

05 Jul 2009, 10:52

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland

Tomasz Grysztar 06 Jul 2009, 06:13

Can you clarify? I'm not sure I understand, what the problem is.

06 Jul 2009, 06:13

Helle

Joined: 24 Feb 2007
Posts: 23
Location: Germany

Helle 06 Jul 2009, 13:10

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

06 Jul 2009, 13:10

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland

Tomasz Grysztar 06 Jul 2009, 13:49

Oh, I see now - you forgot to add, that it's in 64-bit mode. Nice catch - fixing now.

06 Jul 2009, 13:49

Helle

Joined: 24 Feb 2007
Posts: 23
Location: Germany

Helle 07 Jul 2009, 05:15

Hey, I wrote "...(only 64-bit-mode)..." Very Happy

- works fine now!
Thanks
Helle

07 Jul 2009, 05:15

< 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