flat assembler
Message board for the users of flat assembler.

Index > Main > pre-release: fasm 1.52

Goto page 1, 2, 3  Next
Author
Thread Post new topic Reply to topic
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 20 Mar 2004, 11:55
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.


Last edited by Tomasz Grysztar on 03 Apr 2004, 18:06; edited 5 times in total
Post 20 Mar 2004, 11:55
View user's profile Send private message Visit poster's website Reply with quote
LiuJunfeng



Joined: 28 Nov 2003
Posts: 48
Location: China
LiuJunfeng 22 Mar 2004, 11:01
Will you explain the difference between "dw" and "du"?
Post 22 Mar 2004, 11:01
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 22 Mar 2004, 11:05
Is this question really related to this thread?
Anyway, the difference can be explained most simply on the example. This instruction:
Code:
dw "AB"    

generates one word of data, with value 4241h, while this:
Code:
du "AB"    

generates two words, first of value 0041h, second of value 0042h.
Post 22 Mar 2004, 11:05
View user's profile Send private message Visit poster's website Reply with quote
LiuJunfeng



Joined: 28 Nov 2003
Posts: 48
Location: China
LiuJunfeng 22 Mar 2004, 12:34
I see, thanks for your quick reply!
And when dw and du apply to numbers, such as:
Code:
dw 1,2
du 1,2
    
They get the same result.
Post 22 Mar 2004, 12:34
View user's profile Send private message Reply with quote
Frank



Joined: 17 Jun 2003
Posts: 100
Frank 22 Mar 2004, 18:33
Privalov wrote:
Please test this pre-release and post your results/opinions here.


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:

Code:
.wmlbuttondown:
        test    [wParam],MK_CONTROL             ; CTRL key pressed?
        jz      .defwndproc                     ; no  ==> default handling
    


Previously, the disassembly gave:

Code:
0040382D                    loc_0040382D:
0040382D F744240C08000000       test    dword ptr [esp+0Ch],8
00403835 74D9                   jz      loc_00403810
    


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:

Code:
0040382D                    loc_0040382D:
0040382D F644240C08             test    byte ptr [esp+0Ch],8
00403832 74DC                   jz      loc_00403810
    


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
Post 22 Mar 2004, 18:33
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 22 Mar 2004, 19:25
S.T.A.S. are you reading this? Didn't I predict it would happen? Wink
Post 22 Mar 2004, 19:25
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3499
Location: Bulgaria
JohnFound 22 Mar 2004, 19:33
Frank wrote:
In other words, I think that the gain of this optimisation (saving three bytes) is too small to warrant the potential confusion.


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

Regards.
Post 22 Mar 2004, 19:33
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
aaro



Joined: 21 Jun 2003
Posts: 107
Location: hel.fi
aaro 22 Mar 2004, 19:38
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.
Post 22 Mar 2004, 19:38
View user's profile Send private message Reply with quote
Tommy



Joined: 17 Jun 2003
Posts: 489
Location: Norway
Tommy 22 Mar 2004, 19:45
I think it should be like this... Wink 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! Wink

Regards,
Tommy
Post 22 Mar 2004, 19:45
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 22 Mar 2004, 20:32
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:
Code:
store byte 0xC3 at 0    

or just:
Code:
store 0xC3 at 0    

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:
Code:
macro upstr name,[value]
 { common name db value
   repeat $-name
     load char from name+%-1
     if char>='a' & char<='z'
      store char-20h at name+%-1
     end if
   end repeat }

upstr hello,"Hello!"    
Post 22 Mar 2004, 20:32
View user's profile Send private message Visit poster's website Reply with quote
madmatt



Joined: 07 Oct 2003
Posts: 1045
Location: Michigan, USA
madmatt 22 Mar 2004, 20:52
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.
Post 22 Mar 2004, 20:52
View user's profile Send private message Reply with quote
Ivan Poddubny



Joined: 21 Sep 2003
Posts: 32
Location: Yaroslavl, Russia
Ivan Poddubny 23 Mar 2004, 06:48
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.
Post 23 Mar 2004, 06:48
View user's profile Send private message Visit poster's website Reply with quote
Tommy



Joined: 17 Jun 2003
Posts: 489
Location: Norway
Tommy 23 Mar 2004, 07:03
Cool, Privalov! Smile I'll try it out when I get home from school! Very Happy
Post 23 Mar 2004, 07:03
View user's profile Send private message Visit poster's website Reply with quote
Ivan Poddubny



Joined: 21 Sep 2003
Posts: 32
Location: Yaroslavl, Russia
Ivan Poddubny 23 Mar 2004, 11:06
WARNING!!!
I found a BUG in FASM 1.52a2!
Try to assemble this instruction:
test edi,1
Post 23 Mar 2004, 11:06
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 23 Mar 2004, 11:21
Oh, of course, I forgot about it (fixed in alpha 3).
Anyway, don't panic, it's still an alpha, isn't it?
Post 23 Mar 2004, 11:21
View user's profile Send private message Visit poster's website Reply with quote
madmatt



Joined: 07 Oct 2003
Posts: 1045
Location: Michigan, USA
madmatt 23 Mar 2004, 12:21
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
Post 23 Mar 2004, 12:21
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 23 Mar 2004, 12:53
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.
Post 23 Mar 2004, 12:53
View user's profile Send private message Visit poster's website Reply with quote
madmatt



Joined: 07 Oct 2003
Posts: 1045
Location: Michigan, USA
madmatt 23 Mar 2004, 16:36
Privalov wrote:
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
Post 23 Mar 2004, 16:36
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 23 Mar 2004, 19:08
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.
Post 23 Mar 2004, 19:08
View user's profile Send private message Visit poster's website Reply with quote
LiuJunfeng



Joined: 28 Nov 2003
Posts: 48
Location: China
LiuJunfeng 25 Mar 2004, 07:20
Privalov wrote:

Usage is simple, for example to modify the first byte of code with the binary output format, you do:
Code:
store byte 0xC3 at 0    


I think it's better to use this syntax:
Code:
store at 0
db 0xC3    

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:
Code:
store at 0x400
mov eax,0
    
Post 25 Mar 2004, 07:20
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2, 3  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


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.