fasm g is not going to be a direct successor to fasm 1

Will it be able to solve what fasm does?
Will it be limited to some architecture/instructions set?

Will it be reusable / mergeable, thus a one will be able use its source-facilities in hiw own project?

Which life shpere is it intended to be?

it is more like a tiny "probe" sent to investigate new areas

There are also some very subtle differences related to empty values and comma placement

Code:

x = (x-1)*(x+2)/2-2*(x+1)    

use64
org 100000000h
lea edx,[0]    

I mean, for example,

Code:

use64
org 100000000h
lea edx,[0]    

that still doesn't compile (preferably into the eip-relative addressing, which is currently quite inconvenient to do in fasm).

This construction is defined to generate RIP-relative encoding, so it is doomed to fail here by specification

It perhaps should allow at least [eip-$] to work here

use64
org 100000000h
lea edx,[eip-@F and 0xFFFFFFFF+0]
@@:    

mov rax,$70000000    

mov eax,$70000000    

Using the occasion I'd like to ask a question regarding your example from the first post:

Quote:

Code:

x = (x-1)*(x+2)/2-2*(x+1)    

Why is the value of x still zero at the beginning of the second pass? I mean, the initial prediction is "zero, undefined", then it's "zero, defined" at the beginning of the second pass, and only at the beginning of the third pass it's "-3, defined". Why isn't the predicted value -3 already at the second pass?

you can experiment yourself by commenting out the piece of code that zeroes the value (it's just before the "expression_value_ok" label)

macro x args&
{
    common match a:b, args
    \{
        y a
        display 13,10
        b
    \}
}
macro y arg1*, arg2
{
    display arg1,13,10
    match any,arg2 \{ arg2 \}
}
macro nothing {}

x <'Hello',' ','World!'> : nothing    

macro x [args]
{
    common match a:b, args
    \{
        a
        display 13,10
        b
    \}
}
macro y arg1*, arg2*
{
    display arg1,13,10
    arg2
}
macro z arg1*, arg2*
{
    display arg1,13,10
    arg2
}
macro nothing {}

x y '1', <z '2', display 'Hello!'> : nothing    

The expected result is same as when using the new feature instead of the group argument, but fasm's argument validation here is too restrictive. As long as the documentation does not clearly specify this behaviour (...)

The manual uses the "such argument should be enclosed" phrase, which I thought should be unambiguous enough.

If it was replaced with a mechanism that you propose, "x" macro would get three separate parameters, one being "<z '2'" and the other "display 'Hello!'> : nothing"

"C:\Program Files\Internet Explorer\iexplore.exe"    

C:\Prog"ram Files\In"ternet" "Explorer\iexplore.exe    

Thank you for the report!

C:\Documents and Settings\We are the Borg\Our Documents>fj MyUberProggy.asm
flat assembler junior  version 2.00.00  (1048576 kilobytes memory)
12 passes, 1.5 seconds, 442880 bytes.    

C'mon revo, we need to get rid of those traditional '...ASM' thingy.

F-compiler sounds like a boss.
fasm-junior sounds like,well,,,, a baby's milk formula.

F-compiler sounds like a boss.

system error wrote:

C'mon revo, we need to get rid of those traditional '...ASM' thingy.

Why? It's an assembler so it should sound like one.

system error wrote:

F-compiler sounds like a boss.
fasm-junior sounds like,well,,,, a baby's milk formula.

I like milk.

too many "..asm" out there and it doesn't have to be that way anymore. e,g, A386 or what else I can't remember.

You like milk because you are a SOCCER MOM!! LOL LOL!

system error wrote:

F-compiler sounds like a boss.

Actually it sounds like a compiler for the F language (whatever that is).

Actually it sounds like a compiler for the F language (whatever that is).