Finally I have found time to make some of the additions planned for the 1.52 version, and so you've got the first pre-release here. Changes include:

• feature of more than 65535 relocations per section in MS COFF format; it would be great if someone tested it with some linkers (because this feature is specific for Microsoft's format only, standard COFF formatter keeps the limitation, the problem was reported here);
  
• "clflush" fixed to accept byte-sized operands (was reported here);
  
• include file searching largely improved - now fasm searches for the file first in the directory of file which is currently processed, then in the include directories (defined with INCLUDE environment variable), finally (for backward compatibility) in the directory, from which it has started (this was discussed here and in other threads that are linked there);
  
• experimental "store" directive added (more in the post below);
  
• command line switch for memory limit setting (more below);
  
• floating point values starting with dot are no longer allowed, to avoid confusion with structural labels, etc.
  

Attachment removed - official release is now available.

Will you explain the difference between "dw" and "du"?

Is this question really related to this thread?
Anyway, the difference can be explained most simply on the example. This instruction:

generates one word of data, with value 4241h, while this:

generates two words, first of value 0041h, second of value 0042h.

I see, thanks for your quick reply!
And when dw and du apply to numbers, such as:
They get the same result.

For results: No problems here -- projects compile and executables work as expected. That result is not very diagnostic, however, because I have no code dealing with the new features (MS-COFF relocations; clflush; search order).

For opinions: I find the TEST optimisation more confusing than helpful. It changes the source "behind my back" -- a feature that may save a couple of bytes here and there, at the cost of making the disassembly much less readable. Take the following part of a WIN32 WndProc:



Previously, the disassembly gave:



which is easy to detect because there is a 1:1 correspondence between source code and disassembly. With the TEST optimisation, in contrast, I get:



which is no longer 1:1 the same. Where my source code tests "wParam", a DWORD, the disassembly tests a BYTE.

Right now, I do know that the result of the two tests is the same. But next time I browse my disassembly, I will wonder why the program tests a BYTE when I had actually asked for a test of "wParam", a DWORD. Is my source code buggy? Did FASM do something wrong? Oh nooooooo -- it's the TEST-optimisation, silly me!

As for coding "test [wParam], DWORD MK_CONTROL": I don't think that one should have to do a type-cast if one wants to keep a variable's type -- one should have to do that if one wants to override the type. At least that's how FASM works everywhere else.

In other words, I think that the gain of this optimisation (saving three bytes) is too small to warrant the potential confusion.

Regards

Frank

S.T.A.S. are you reading this? Didn't I predict it would happen?

100 * 3 = 300
200 * 3 = 600
etc.

Regards.

Maybe you should have a poll? Or maybe command line option to enable this(and maybe even mov -> lea)?
Btw. i have changed my mind(thanks to S.T.A.S.) and like this new feature, because if i like to optimize my codes it would be too big work to check every equation to see if it's below 80h.

I think it should be like this... Keep it up Privalov! BTW: please don't add several options to the command line... One of the thing I like about FASM is its simple command line interface!

Regards,
Tommy

Also I have finally decided to implement the "store" directive as an feature dual to "load", it seems that in current form it should not cause any problems, and possibly it would allow to achieve some things that were impossible before (at least it should allow to simplify some macros that had to be made with combination of "virtual" and "load" before). It can store values into the already generated code (I have not implemented storing the values into file, which would be logical as an eqivalent for "load" variant that loads from file, but it would need some changes in the interface, as there is currently no function that would open file for writing without truncating it). Usage is simple, for example to modify the first byte of code with the binary output format, you do:

or just:

because the byte size is used as default, the same as it is in case of "load".

And thats all - have fun! Hope you'll be able to do some nice tricks with this new feature. As the very first simple sample I provide macro that defines the byte string and converts it uppercase:

I'll put in my two cents worth, First thanks again for a great assembler!, and I hope you keep on making the fasm "engine" run ever smoother! On the other hand, I think optimization should be left up to the programmer. Certain optimizations that work on older processors pentium II's or less may actually be slower on Pentium III' and IV's. Just because the instruction size is smaller doesn't mean it runs faster, especially on the new processors. Or, you should optimze with the lastest pentium/AMD Athlon in mind. I'll see if I can come up with some examples to make my point, unfortunately I don't have the ones I used to have a while ago.

I have problems with MenuetOS kernel compiled by FASM 1.52a1.
But the same code compiled by FASM 1.51 works perfect!
Please check this out.

Cool, Privalov! I'll try it out when I get home from school!

WARNING!!!
I found a BUG in FASM 1.52a2!
Try to assemble this instruction:
test edi,1

Oh, of course, I forgot about it (fixed in alpha 3).
Anyway, don't panic, it's still an alpha, isn't it?

Here is an FASM version for dos that allows up to 4GB of memory to be used for assembly rather than just 64mb's of memory as I believe the unmodified version of FASM version allows. Included is the modified source for FASM, plus the executable, and a program genasm2.exe (and source) that generates a !22mb! assembly file (-> gen.asm) that you can use to test the DOS 4GB FASM [Note: genasm2.exe has to be run in Windows!].

The results I got for assembling the gen.asm file is:

Passes 1849
Seconds 545.8
Bytes 4281699

This was on an AMD Athlon XP 2300 (~2ghz) with 384MB of memory
Any questions, comments let me know!
madmatt

You should not allocate memory yourself when the XMS services are present in system (some TSR program might be using XMS block, for instance), in that case it's better to use XMS 3.0 functions 8xh to allocate more than 64 MB. I have updated the alpha 3 with such variant of this extension.

Hello Privalov, thanks for adding this feature to fasm dos version. This was mainly a quick modification, the first and second version are in the dos forum, it worked, and left it as is, except for a few bug fixes. I'm sure if I had taken the time to look at the code better, I could have written something similar to what you have done.
Madmatt

With regard to optimizations... as long as they can be overridden, I guess they're okay. Near jump optimizations, for instance, are good, and I think it would be silly not to do them. Somehow I'm not too fond of the imm8 test optimization, but as long as they can be overridden it's okay - the app will be functionally equal with the optimization (well, haven't looked at instruction timings). I don't like LEA vs. MOV optimizations, though - while the functional result might be the same, LEA and MOV have quite different execution timings.

Anyway, if optimization settings can be enabled/disabled some central place at the top of an include file when assembling fasm, it won't matter too much - but I think it's important that optimization can be turned off (and with fine granularity, not just "turn off all optimization).

I don't see the problem in adding some commandline parameters to fasm, as long as fasm works for the majority of people without any options. But I think it would be nice to, say, use a relatively small memory block by default, but provide a cmdline argument to increase it, for use on big projects like fresh.

Just my 2 cents.

I think it's better to use this syntax:

The reasons are:
1) it looks natural, first give the offset, then follow data defination.
2) you can not only store data, but also code, for example: