IMHO, definitely no. It's completely another story. It should be possible to define local labels to data labels.

Yes, you're right. And I have just realized that with changing it only for numerical constants I don't have to update the documentation. In fact it is more consistent with documentation now, so I can even consider it a bugfix. (I am updating the release on website now)

Won't this break struct macro? sizeof, virtual at 0, etc?

No. And everything compiles fine in my tests.

I have also added the promised Prescott New Instructions support - it's beta 3 now.

One more update - with little bug fix for large octal constants and documentation updated to cover the new Prescott instructions.
Also FASMW has been updated a bit - now it stores the maximized state in .ini file and the right click in editor finally gives you some menu.

Great thanks to all users who helped me to make this updates.

Is the new prescott processor from intel called Pentium Extreme Edition?

http://www.xbitlabs.com/news/cpu/display/20031203151532.html
It seems they are calling it SSE3 now.

AFAIK "Prescott" is only code-name.

hi, as i know, main 1.51 speedup was storing labels in binary tree. Couldn't be instruction mnemoznics stored in such tree too? they are used much more than labels.

Hi, Privalov
First of all thanks, great FASM!

I noticed some strange situation with include files of 2nd nesting level.
(well, main.asm includes some.inc, and some.inc includes second.inc)

When I write in main.asm or some.inc code like that:
I of course get "unexpected end of file" error.

But when I write above code in second.inc,
this compiles without any errors.

May be this bug appears just in some cases, but could be really weird, IMHO
(exe: flat assembler version 1.51 / January, 31)


Regards,
S.T.A.S.

Hm, actually I can't reproduce this bug.
Here is the files that I create using above description, but I get proper "Unexpected end of file" error.

[edit]attachement removed[/quote]

Oh, sorry, I haven't posted an example. Here's my version now.
May be there is something wrong with my understanding of macro preprocessing?

The problem is, I suppose, with brackets '}'.
FASM allows some tricks when we write in one file something like
But when it's is separated in different files, sometimes it could be difficult to locate the unclosed brackets.
Still, I'm not sure is it really bug or not.

Ah, you are talking about this case. It is not because the nesting of files.
There is no "nested" brackets in FASM macro syntax.
Simply the above mentioned macro is normally defined macro that contains the sign "{". When you use it somewhere in the text of the program, it will insert in the source the "{" char. That's all. If you want to play with macroses that create another macroses, that creat... You should use "fix" directive to play with brackets. See for example "globals.inc" file from Fresh source files.

Regards

Thanks, JohnFound
I have studied a lot from "globals.inc". It is good example about FASM's power.

Well, it's really good trick to define a macro by another macro. And I'm trying to use this as frequently as it is possible.
Of course I'm using fix directive to define "internal" brakets. My macro isn't from real code, it's just to simplify situation.

Problem is (well, could be) when I forgot to write '}' (or '_m fix }' ) in some include file just by mistake.
Then FASM could interpret some unwanted code in other file as a part of my macro.
And to locate this one forgotten bracket in some big project may be not so easy.
Especially in the case, when some (defined by macro) code may (or may not) be compiled depending on some condition(s) and several "purge" are used.
Of course, it isn't a big deal with a small project (where I have noticed it) .

I'm not sure is it good idea to check unclosed macro's brackets at the end of include file by FASM or not.
IMHO it's not a real compiler bug, but feature we should sometimes care about.


Regards
(and sorry for my English)

Hi, S.T.A.S

Thank you for compliments. They are for many people because globals.inc is collective work.



Don't do it "as frequently as possible". It is powerfull, but quite hard to follow trick. If you can do the job without it, better IMHO avoid.



I am agree with you. It is a problem for FASM that the message "unexpected end of file" is non-informative and don't help for solving the problem. Privalov should think out something about this. But I am not agree that that "something" should be check at the end of the file. Because this will artificaly reduce the features of FASM without so big benefit, because some source files are quite big, so if you get the message at the end of the file, it won't help you so much to find the problem.

Regards

S.T.A.S.:
Look at this thread: http://board.flatassembler.net/topic.php?t=619
It's quite helpfull to have 'fixes.inc' when your working with nested macros, so you don't need to invent new names for {, } and like in every include file you have(you know that the fix has to be defined after macro definition?).

All:
Please give me better symbol for fixed #, i don't think that every keyboard has ¤ symbol easily accessible(in my keyboard it's next to #).

Thanks, aaro
It's easier, than think about unique names in every file