flat assembler
Message board for the users of flat assembler.

Index > Main > flat assembler 1.67.3x

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



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 10 Feb 2009, 15:36
Then perhaps best thing to do would be to not put a REX here at all.
Post 10 Feb 2009, 15:36
View user's profile Send private message Visit poster's website Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen 10 Feb 2009, 15:48
So PEXTRW RAX will cause "invalid size of operand" or it will get silently assembled to PEXTRW EAX?
Post 10 Feb 2009, 15:48
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 10 Feb 2009, 16:01
Well, I think we can make it to "silently" assemble into (66) 0F C5 opcode. If this will work exactly the same, it shouldn't cause any harm.
Though it's sometimes problematic to determine where we should put the limits of allowed code optimization, like if to allow optimizing LEA into MOV (which fasm does not).
Post 10 Feb 2009, 16:01
View user's profile Send private message Visit poster's website Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen 10 Feb 2009, 16:25
Since REX would be completely unnecessary here, I think we can consider this as code size optimization.

The MOV -> LEA conversion is different thing because it changes whole instruction. (I remember someone complaining about this in GoAsm forum because GoAsm converts it.)
Post 10 Feb 2009, 16:25
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 10 Feb 2009, 18:31
revolution wrote:
How do we say it to our friends? "I'm using version 1.6cool"

So I think we have agreed upon a code name for the 1.68 release - it's "cool". Wink
Post 10 Feb 2009, 18:31
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20355
Location: In your JS exploiting you and your system
revolution 11 Feb 2009, 00:47
MazeGen wrote:
The MOV -> LEA conversion is different thing because it changes whole instruction. (I remember someone complaining about this in GoAsm forum because GoAsm converts it.)
I have always seen this as simply a mnemonic substitution problem. The CPU knows only binary and will execute the LEA/MOV thing in such a way that the net effect is the same. Just because we need to satisfy the human desire to convert binary values into more human friendly words does not affect the CPU. If the disassemblers were to display those LEAs as MOVs would the people still complain? How do people feel when the dual Jcc opcodes are "changed" by the disassembler? The disassembler has to choose one of the mnemonics, how can it know what the source code programmer was thinking? The same with XOR reg,reg. If the disassembler were to display "CLEAR reg" would people then complain? Okay, I know that CLEAR has not been defined in any official documentation, but if it was defined and assemblers modified etc. then suddenly XOR reg,reg (displayed as CLEAR reg) becomes acceptable?

The CPU does what it does without caring about human mnemonics. If we can use a shorter opcode to achieve the same effect then I don't see why not to use it. Perhaps instead of us forcing the assembler to make less efficient code we should instead be asking the disassembler writers to make their code more flexible/smarter?


Last edited by revolution on 11 Feb 2009, 04:55; edited 1 time in total
Post 11 Feb 2009, 00:47
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid 11 Feb 2009, 02:29
Isn't there difference in optimization between LEA and MOV? Such as LEA needing address calculation, or something like that. (just quessing)
Post 11 Feb 2009, 02:29
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20355
Location: In your JS exploiting you and your system
revolution 11 Feb 2009, 04:27
vid wrote:
Isn't there difference in optimization between LEA and MOV? Such as LEA needing address calculation, or something like that. (just quessing)
Is there? Has anyone done tests? Sure the LEA probably uses the AGU, whereas MOV uses the ALU. But will it create a resource bottleneck? Perhaps using the AGU will free up the ALU for another instruction to be processed in parallel, perhaps it can improve the performance? I'm also guessing.
Post 11 Feb 2009, 04:27
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 4046
Location: vpcmpistri
bitRAKE 11 Feb 2009, 06:05
Macros should be used for this kind of pigeon hole optimization of assembly, imho. The only thing important to me is consistency because code size does matter when it comes to utilizing availble decode bandwidth. Also, jumping into unrolled loops of a constant granularity require tuning the size for binary masks.
Post 11 Feb 2009, 06:05
View user's profile Send private message Visit poster's website Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen 11 Feb 2009, 08:43
revolution, since this MOV->LEA conversion is perhaps the only optimization which we should seriously consider, we don't need to generalize this issue.

I think if one needs to save few bytes of code (what means s/he is not a beginner in asm language), one can always write
Code:
LEA RAX, [lbl]    

instead of
Code:
MOV RAX, lbl    

or overload the MOV instruction using a macro, as bitRAKE said.
Post 11 Feb 2009, 08:43
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20355
Location: In your JS exploiting you and your system
revolution 11 Feb 2009, 14:43
The LEA macro already exists, written by me Very Happy

For the full history of these macros see this thread.
Post 11 Feb 2009, 14:43
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 12 Feb 2009, 07:23
Small little thing here, You need to update your copyright notice. people seeing it will think you haven't updated fasm since 2007. Smile
Post 12 Feb 2009, 07:23
View user's profile Send private message Reply with quote
shoorick



Joined: 25 Feb 2005
Posts: 1614
Location: Ukraine
shoorick 12 Feb 2009, 07:57
Quote:

You need to update your copyright notice.

put there something like 2099 (to not care a while)
Post 12 Feb 2009, 07:57
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 12 Feb 2009, 09:00
madmatt wrote:
Small little thing here, You need to update your copyright notice. people seeing it will think you haven't updated fasm since 2007. Smile

It took me a few moments of searching to realize, which one you're talking about. Wink
Post 12 Feb 2009, 09:00
View user's profile Send private message Visit poster's website Reply with quote
mattst88



Joined: 12 May 2006
Posts: 260
Location: South Carolina
mattst88 12 Feb 2009, 16:47
shoorick wrote:
Quote:

You need to update your copyright notice.

put there something like 2099 (to not care a while)


It doesn't work like that.

_________________
My x86 Instruction Reference -- includes SSE, SSE2, SSE3, SSSE3, SSE4 instructions.
Assembly Programmer's Journal
Post 12 Feb 2009, 16:47
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1903
DOS386 13 Feb 2009, 08:14
MazeGen wrote:
revolution wrote:
Tomasz Grysztar wrote:
Silent update is coming. Wink
Can I suggest a fourth digit to distinguish these versions. 1.67.30.1


Why not 1.67.31?


But there is 1.67.31 Smile

Quote:
Fourth digit looks a bit too much for me. And we still have 1.67.32 - 1.67.99 namespace until 1.68 is done.


Right. Please continue minor fixes with 1.67.32 , 1.67.33 ...

Quote:
I don't want the amount of packages on the server to grow too quickly with all the small mistake fixes.


Just keep succesful old versions only, so keep 1.67.26 and 1.67.29, and kick 1.67.25, 1.67.27/28 as well as 1.67.30.xx Idea and if you upload 1.67.32 soon, kick 1.67.31 at this time Smile

Quote:
flat assembler 1.67.30 The new release comes today


None of my enhancements and fixes is included Crying or Very sad

_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug
Post 13 Feb 2009, 08:14
View user's profile Send private message Reply with quote
madmatt



Joined: 07 Oct 2003
Posts: 1045
Location: Michigan, USA
madmatt 13 Feb 2009, 08:17
Tomasz Grysztar wrote:
madmatt wrote:
Small little thing here, You need to update your copyright notice. people seeing it will think you haven't updated fasm since 2007. Smile

It took me a few moments of searching to realize, which one you're talking about. Wink


Yeah, I should've been more specific. Rolling Eyes

_________________
Gimme a sledge hammer! I'LL FIX IT!
Post 13 Feb 2009, 08:17
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 13 Feb 2009, 09:43
DOS386 wrote:
Right. Please continue minor fixes with 1.67.32 , 1.67.33

Those version numbers mean actual development progress, the one listed in whatsnew.txt
The fourth digits reflects what used to be the "silent updates" - the quick fixes of obvious mistakes made in those development versions.

DOS386 wrote:
Just keep succesful old versions only, so keep 1.67.26 and 1.67.29, and kick 1.67.25, 1.67.27/28 as well as 1.67.30.xx Idea and if you upload 1.67.32 soon, kick 1.67.31 at this time Smile

But that's the same what I'm doing by replacing the files with their new versions. Wink
Oh, but I know what troubles you - it's that the version listed on "Download" page doesn't chage. I'm correcting this.

DOS386 wrote:
None of my enhancements and fixes is included Crying or Very sad

Currently I'm working on the core, not IDEs. When I get back to the work on IDE (and I have to do it one day, because they both are still "prototypes"; the things like directory browsing or .ini support are missing in FASMD not because I don't think they're necessary, but just because this is still far from the "final" version - possibly I should state it more clearly in the documentation draft?), I may look into your suggestions.
Post 13 Feb 2009, 09:43
View user's profile Send private message Visit poster's website Reply with quote
Helle



Joined: 24 Feb 2007
Posts: 23
Location: Germany
Helle 13 Feb 2009, 10:59
Hello,
PEXTRW works fine now (test with 32-Bit-OS and FAsm 1.67.31_2), but for PEXTRB R32,XMMx,Ib I think, in the ModR/M-Byte must change the reg-and the r/m-field (M8 is oK).
PEXTRD R32,XMMx,Ib give the message "invalid size of operand", M32 is oK.
Thanks
Helle
Post 13 Feb 2009, 10:59
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 13 Feb 2009, 11:16
Fixed. And thanks for the report.
Post 13 Feb 2009, 11:16
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

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