flat assembler 1.69.36-38

Index > Main > flat assembler 1.69.36-38

Goto page 1, 2 Next

Author

Thread

Tomasz Grysztar

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

Tomasz Grysztar 11 Feb 2012, 18:35

The first new release this year, it adds two new features. First is the new assert directive, which causes "recoverable" error when the given logical expression is false (the "recoverable" means that error is not signalized if it occurs in the intermediate passes). The "assert 0" idiom now officially replaces the old tricky "rb -1", and constructions like:

Code:

if top>=10000h
  rb -1
end if

can now be simplified to:

Code:

assert top<10000h

The second new feature is ability to provide default value for macro argument, which will get used when empty value is provided when macro is used. You do it like:

Code:

macro show value=-15
 { display '0'+value }

show
show 1

EDIT: the 1.69.37 follows quickly, because I added one more new feature, discussed in the other thread. It is the "relativeto" operator, which allows to test labels for being any kinds of special values. In general, expression with "relativeto" is true when expressions on both sides of it differ only by some fixed value, for example if both are relocatable values with the same base address, or both have the same register as base, or both are absolute value.

Some examples of usage:

Code:

if mylabel relativeto 0
  dd mylabel xor 0xABCD ; this is just a number, I can do any computations on it
end if

if mylabel relativeto ebp
  offset_in_stack = mylabel - ebp
end if

if mylabel relativeto $
  jmp mylabel ; this jump will never generate relocation
end if

if mylabel relativeto some_external_array
  offset_in_array = mylabel - some_external_array
end if

While implementing it, I also found and fixed a couple of small bugs, in some cases assembler did not signal incorrect usage of value while it should. Now it is more restrictive, but this should not break any normal sources - if you've got something that stopped to assemble and you think it's a bad thing, please let me know.

If you are interested what other plans for the fasm development I have - currently I only plan adding AVX2 support later this year, any other additions left for indefinite future. I decided that 1.70 milestone will some after AVX2 support is finished and tested, I apologize to those who expected 1.70 to have Mach-O, but that probably is not going to happen (in 1.71.x line, maybe).

Last edited by Tomasz Grysztar on 24 Feb 2012, 16:52; edited 1 time in total

11 Feb 2012, 18:35

cod3b453

Joined: 25 Aug 2004
Posts: 618

cod3b453 11 Feb 2012, 21:00

This should clean my assert macros up nicely Cool

I'm also glad this is possible:

Code:

x = 0

macro @dummy [a,b=x,c]
{
        db a,b,c
        x = x + 1
}

@dummy  1,,2,\
        3,,4; 01 00 02 03 01 04

since it looks like it will simplify some of my more complicated macros.

11 Feb 2012, 21:00

l_inc

Joined: 23 Oct 2009
Posts: 881

l_inc 11 Feb 2012, 21:18

cod3b453 wrote:

I'm also glad this is possible

Yes. But this seems to work only if the last argument in a group has no default value (a bug?). The following code results in the error "invalid macro arguments".

Code:

macro show [value=1] { db value}
show

11 Feb 2012, 21:18

Tomasz Grysztar

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

Tomasz Grysztar 11 Feb 2012, 21:58

I uploaded the quick fix, please re-download the package - the closing bracket is no longer taken to be a part of default value. And if you need default value containing "]" there, enclose the value in "<" and ">".

11 Feb 2012, 21:58

mindcooler

Joined: 01 Dec 2009
Posts: 423
Location: Västerås, Sweden

mindcooler 12 Feb 2012, 00:15

Nice, I have recently run into a problem where I would need assertions.

And I recently had a macro where I wanted default arguments Smile

12 Feb 2012, 00:15

SFeLi

Joined: 03 Nov 2004
Posts: 138

SFeLi 13 Feb 2012, 15:11

Tomasz Grysztar wrote:

I uploaded the quick fix

It still does not work when written this way:

Code:

macro show value=-15 { display '0'+value }

Is it ok?

13 Feb 2012, 15:11

Tomasz Grysztar

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

Tomasz Grysztar 13 Feb 2012, 15:28

That's another bug. Will be fixed by the next release I'm preparing.

13 Feb 2012, 15:28

madmatt

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

madmatt 13 Feb 2012, 19:27

Whatever you changed, effected the 'cinvoke' macro too. this line crashes my program.

Code:

cinvoke printf, <10,13,"IID_IXAudio2 - XAudio2 Creation Succeeded.",10,13>

13 Feb 2012, 19:27

Tomasz Grysztar

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

Tomasz Grysztar 13 Feb 2012, 19:36

It works correctly for me. Are you sure it is this line that is assembled differently for you?

13 Feb 2012, 19:36

Tomasz Grysztar

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

Tomasz Grysztar 13 Feb 2012, 20:31

I edited the original post to include the 1.69.37 release information, since it comes so quickly after the previous one.

13 Feb 2012, 20:31

madmatt

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

madmatt 13 Feb 2012, 21:04

Tomasz Grysztar wrote:

It works correctly for me. Are you sure it is this line that is assembled differently for you?

It worked fine with 1.69.35, Began using 1.69.36 when the problem started, also:

1. Forgot to mention this is for 64bit cinvoke.
2. It seems to be crashing with the numbers before the quoted string.

Code:

cinvoke printf, <"IID_IXAudio2 - XAudio2 Creation Succeeded.",10,13> ;compiles fine

_________________
Gimme a sledge hammer! I'LL FIX IT!

13 Feb 2012, 21:04

Tomasz Grysztar

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

Tomasz Grysztar 13 Feb 2012, 21:36

Oh, right, that's one very important instruction which I dropped somehow.
I uploaded the correction.

13 Feb 2012, 21:36

l_inc

Joined: 23 Oct 2009
Posts: 881

l_inc 13 Feb 2012, 21:36

Tomasz Grysztar
I'm not sure, how the introduced operation should work, but should the following code display "different base"? Because I expected to see the opposite option.

Code:

label abc at ebp+esp

if (abc-esp) relativeto ebp
 display 'same base',13,10
else
 display 'different base',13,10
end if

Also the operation precedence and the commutativity are unclear. Is a relativeto b always the same as b relativeto a?

13 Feb 2012, 21:36

Tomasz Grysztar

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

Tomasz Grysztar 13 Feb 2012, 21:51

l_inc wrote:

I'm not sure, how the introduced operation should work, but should the following code display "different base"?

It should not, that's another correction. Hmm, the fault is because of some legacy code that needs cleanup... Maybe later. For now I'm uploading the simple fix.

l_inc wrote:

Also the operation precedence and the commutativity are unclear. Is a relativeto b always the same as b relativeto a?

It is commutative, because when two values differ by constant amount, it works both ways. But there is one catch - "relativeto" works as a special construct for the parser, the same as "at" operator, which make it expect an expression after. This allows to write "label x at ebp" or "if x relativeto ebp" (otherwise you'd have to write "label x at +ebx" to force the expression phrase to get parsed), but if you write a lone register name as a first expression, the parser will make it a register lexical type, not expression, because it does not yet know that "relativeto" follows. That may be considered a bug, but I do not feel an urge to fix it right now.

13 Feb 2012, 21:51

l_inc

Joined: 23 Oct 2009
Posts: 881

l_inc 13 Feb 2012, 22:04

Tomasz Grysztar
OK. Thank you.

13 Feb 2012, 22:04

madmatt

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

madmatt 13 Feb 2012, 22:20

Tomasz Grysztar wrote:

Oh, right, that's one very important instruction which I dropped somehow.
I uploaded the correction.

Seems to be fixed now, thanks!

_________________
Gimme a sledge hammer! I'LL FIX IT!

13 Feb 2012, 22:20

yoshimitsu

Joined: 07 Jul 2011
Posts: 96

yoshimitsu 15 Feb 2012, 04:22

Being able to give macro arguments default values sounds great!
Though, I guess I got to read that topic you linked to see usages for the new relativeto-operator, I can't think of any atm :s

Great work, Tomasz :)

Btw. There's a little typo in the changelog:
version 1.69.27 (Feb 13, 2012)

15 Feb 2012, 04:22

Tomasz Grysztar

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

Tomasz Grysztar 15 Feb 2012, 13:32

yoshimitsu wrote:

Btw. There's a little typo in the changelog:
version 1.69.27 (Feb 13, 2012)

Hmm, I guess it's too late to correct it in Linux/Unix packages.
I promised to not modify them after 24 hours from release, since some distro packagings rely on checksums of files staying constant.

15 Feb 2012, 13:32

edfed

Joined: 20 Feb 2006
Posts: 4353
Location: Now

edfed 15 Feb 2012, 20:47

what can make fasm version become 1.70.00?

15 Feb 2012, 20:47

Tomasz Grysztar

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

Tomasz Grysztar 15 Feb 2012, 20:51

edfed wrote:

what can make fasm version become 1.70.00?

See the end of first post.

15 Feb 2012, 20:51

Goto page 1, 2 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