flat assembler 1.67.3x

Index > Main > flat assembler 1.67.3x

Goto page Previous 1, 2, 3, 4, 5 Next

Author

Thread

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8353
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.

10 Feb 2009, 15:36

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?

10 Feb 2009, 15:48

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8353
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).

10 Feb 2009, 16:01

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.)

10 Feb 2009, 16:25

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8353
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

10 Feb 2009, 18:31

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20338
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

11 Feb 2009, 00:47

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)

11 Feb 2009, 02:29

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20338
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.

11 Feb 2009, 04:27

bitRAKE

Joined: 21 Jul 2003
Posts: 4039
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.

11 Feb 2009, 06:05

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.

11 Feb 2009, 08:43

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20338
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.

11 Feb 2009, 14:43

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

12 Feb 2009, 07:23

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)

12 Feb 2009, 07:57

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8353
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.

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

12 Feb 2009, 09:00

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

12 Feb 2009, 16:47

DOS386

Joined: 08 Dec 2006
Posts: 1900

DOS386 13 Feb 2009, 08:14

MazeGen wrote:

revolution wrote:

Tomasz Grysztar wrote:
Silent update is coming.
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

13 Feb 2009, 08:14

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.

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

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

_________________
Gimme a sledge hammer! I'LL FIX IT!

13 Feb 2009, 08:17

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8353
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 and if you upload 1.67.32 soon, kick 1.67.31 at this time

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

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.

13 Feb 2009, 09:43

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

13 Feb 2009, 10:59

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8353
Location: Kraków, Poland

Tomasz Grysztar 13 Feb 2009, 11:16

Fixed. And thanks for the report.

13 Feb 2009, 11:16

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