registers algebra engine

Index > Compiler Internals > registers algebra engine

Goto page Previous 1, 2

Author

Thread

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20299
Location: In your JS exploiting you and your system

revolution 25 Jun 2010, 16:54

What do you propose to replace it?

25 Jun 2010, 16:54

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 25 Jun 2010, 18:06

Why a new thread for this was needed when you reported the same thing in the sticky post? ( http://board.flatassembler.net/topic.php?t=11611 )

If you want, I can merge this thread into your older one.

25 Jun 2010, 18:06

ouadji

Joined: 24 Dec 2008
Posts: 1081
Location: Belgium

ouadji 25 Jun 2010, 18:17

Most of the time, Tomasz has very difficult to admit there is a problem ...
it's a pity, and detrimental to the improvement of Fasm.
Why spend time to propose solutions, because most of the time, Tomasz disregards solutions !
"FASM" is a wonderful compiler ... but Fasm is imperfect..
To make Tomasz admit that there is a problem, and to have a positive response from him ...
is like having to lift a mountain.
well, I will redesign and rebuilt this engine ... just for the fun ... Razz

Quote:

If you want, I can merge this thread into your older one.

_________________
I am not young enough to know everything (Oscar Wilde)-

25 Jun 2010, 18:17

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 25 Jun 2010, 18:37

Merge done.

25 Jun 2010, 18:37

Tomasz Grysztar

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

Tomasz Grysztar 25 Jun 2010, 20:34

ouadji wrote:

Most of the time, Tomasz has very difficult to admit there is a problem ...
it's a pity, and detrimental to the improvement of Fasm.

When you call some choices that were substantial in the design of fasm the "problems", you're certainly looking for some other assembler. Feel free to make a fork, but I'm going to stay with my principles.

25 Jun 2010, 20:34

Tomasz Grysztar

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

Tomasz Grysztar 25 Jun 2010, 21:03

Tomasz Grysztar wrote:

LocoDelAssembly wrote:
IMHO, if this is fixed, I think the best will be to change [ds:ebp+ebp+disp32] to check if some ModR/M+SIB exists that avoids using the override prefix ([EBP*2+disp32] here).
I agree. This is fix for just an optimization issue (that is: to optimize [ds:ebp+ebp] into form without prefix, shorter than the one generated now).

Actually, I was wrong here. The form with prefix is still shorter than the form without prefix, but with enforced disp32 instead. Thus such fix wouldn't really do a good job.

25 Jun 2010, 21:03

ouadji

Joined: 24 Dec 2008
Posts: 1081
Location: Belgium

ouadji 25 Jun 2010, 23:20

Nothing to do with "shorter" or "longer".
It's only a question of compliance with the code requested.
With a asm compiler, no opcode should be unattainable or banned.
You talk about principles ...
i think respect the code requested by the programmer is the first principle !
A compiler must be an evolving program, the designer must be listening to users ...
especially when the comments are correct.
This is a pity ... Fasm is a very good compiler and few things could make it perfect !...
but you seem to refuse any ideas of change and improvement.
Many people use Fasm, It is unfortunate to note that its designer does not take into consideration the comments and requests from users.
Don't forget that without the users, fasm would not exist !

Thank you very much

_________________
I am not young enough to know everything (Oscar Wilde)-

25 Jun 2010, 23:20

ouadji

Joined: 24 Dec 2008
Posts: 1081
Location: Belgium

ouadji 26 Jun 2010, 13:38

my first patch.
This patch handles the difference between "reg+reg" and "reg* 2"
It seems to give very good results,
I still have not noticed errors with 32bits code.

Code:

EXPRESSI.INC     ;patch = (A)+(B)
-------------
        .....
sib_allowed:
   or      bh,bh
       jnz     check_index_scale

       cmp     cl,2
        je      reg2_   ;<---------- (A) "reg2_"  instead of "special_index_scale"
   cmp     cl,3
        je      special_index_scale
 cmp     cl,5
        je      special_index_scale
 cmp     cl,9
        je      special_index_scale

check_index_scale:
   or      cl,cl
       jz      check_immediate_address
     cmp     cl,1
        je      check_immediate_address
     cmp     cl,2
        je      check_immediate_address
     cmp     cl,4
        je      check_immediate_address
     cmp     cl,8
        je      check_immediate_address
     jmp     invalid_address

reg2_:       cmp     byte[edi+1Eh],1            ;+(B)
    jne     check_immediate_address    ;+
       
special_index_scale:
        mov     bh,bl
       dec     cl
check_immediate_address:
  mov     al,[address_size]
   and     al,0Fh
      .....

_________________
I am not young enough to know everything (Oscar Wilde)-

Last edited by ouadji on 29 Jun 2010, 13:27; edited 5 times in total

26 Jun 2010, 13:38

Tomasz Grysztar

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

Tomasz Grysztar 26 Jun 2010, 13:42

ouadji wrote:

With a asm compiler, no opcode should be unattainable or banned.

I cannot agree. In fact, most of the assemblers don't follow such principle, because there are often many opcodes that correspond to exactly the same instruction. fasm focuses on function of instruction only, and thus the principle that is important here is "no instruction should be unattainable", where instruction is defined by its function (and assembly language mnemonic correspond to function of instruction, not the opcode - see MOV, for example). Assembler then chooses the opcode that correctly reflects this function - in case of fasm it tries to generate the shortest opcode possible (though it's not always possible, see some discussions about code resolving).

As for the EBP*2 problem, the only real problem I see there is the ambiguity of the default segment register used for addressing. In flat mode it doesn't really matter and you can leave to assembler to choose whatever form (again: the shortest one possible). But when you are working in segmented mode, the ambiguity caused by this approach might be a problem - thus you'd need to use segment prefix just to be on the safe side (and force assembler to choose an encoding that uses this default segment). However the problem might be considered marginal (solution is: use segment override when feel unsure about what segment will be used, fasm still is going to choose the shortest form, possibly without a segment prefix) and does not justify for me getting rid of the register algebra, which a substantial feature of fasm's internal.
If you got rid of it, the pieces of code like this one would no longer work:

Code:

virtual at EBP-100h
  some_structure MY_STRUC some_parames
  sizeof.some_structure = $ - some_structure

And in general, working with labels using some register base would get impossible, if you simply got rid of the register algebra feature.

ouadji wrote:

It is unfortunate to note that its designer does not take into consideration the comments and requests from users.

I do take them into consideration, when they seem reasonable to me and they do not conflict with my own plans. And considering that sometimes there are even groups of users requesting exactly opposite things each other, I have to make some choices. And the choice is usually to stick with my own rules.

ouadji wrote:

Don't forget that without the users, fasm would not exist !

Well, in fact fasm did exist without users for a long time - that is, I was the only user and it was just a personal tool that suited my preferences well. But later, when I made it available on the web, it started gathering people that found it useful, too - and thus things such as this forum came to life. So you might rather say: it is this forum, that would not exist without users. And because it exists, you are now able to publicly express your opinion about this subject.

26 Jun 2010, 13:42

ouadji

Joined: 24 Dec 2008
Posts: 1081
Location: Belgium

ouadji 26 Jun 2010, 13:56

sorry if I was a bit "direct" in my comments.
Again, "Fasm" is a wonderfull and very good compiler.
congratulations !

I agree with you on all of your message.

just above a small fix for this "problem".
and if you prefer don't change this, ok ! Wink

(Sorry for my bad english)

_________________
I am not young enough to know everything (Oscar Wilde)-

26 Jun 2010, 13:56

ouadji

Joined: 24 Dec 2008
Posts: 1081
Location: Belgium

ouadji 29 Jun 2010, 23:48

Please Tomasz, could you look at this, thank you.
I think I found an interesting idea to solve this problem with "ebp".

the problem occurs only with the Registry ebp/rbp, and only with an result multiplier of 2.

1) with any registers exept ebp/rbp, priotity to "reg+reg", like "FASM" works currently!

2) with ebp/rbp, by default ... give priority to the form with "reg*reg"
inc dword [ebp+ebp+ebp-ebp] ... it will be compiled like this : inc dword [ebp*2]
In this case, if no segment register is specified, then this is the segment register "DS" which is used by default by the processor.

3) with ebp/rbp, If we want to use the segment register "SS" instead of "DS" !
In this case, we will ask that by specifying the register " SS"
like this :

Code:

inc dword [ss:ebp+ebp+ebp-ebp]

BUT,

A) in this case, the priority will be given to the form with "+"
B) and we will cancel the request to add the prefix "ss".
Indeed, with the form with "+", the segment register used by default is already the register "ss"!

Code:

summary of these two cases (with ebp/rbp)
----------------------------------------
by default :
inc dword [ebp+ebp+ebp-ebp] ==> inc dword [ebp*2] ; "ds" by default

if we want "SS" :
inc dword [ss:ebp+ebp+ebp-ebp] ==> inc dword [ebp+ebp] 
; without "ss:" because here,"ss" is by defaut !!

this works fine.
It's a easy and effective way to solve this problem.

The code:

Code:

EXPRESSI.INC
------------
      .....
sib_allowed:
   or      bh,bh
       jnz     check_index_scale

       cmp     cl,2
        jne     no_two
      cmp     bl,45h
      je      ss__
        cmp     bl,85h
      jne     special_index_scale; ---> any registre except ebp/rbp --> (reg + reg)

ss__:    cmp     [segment_register],3
        jne     check_immediate_address ; --->  ebp/rbp but not "ss:" --> (reg * 2)
     mov     [segment_register],0
        jmp     special_index_scale ; ---> ebp/rbp and "ss:" --> (reg + reg)
                                            ;and remove "ss" (useless)

no_two: cmp     cl,3
        je      special_index_scale
 .....

Code:

results
-------
inc dword[(eax+eax+eax-eax)]          ; ==> [eax+eax] - ds by default
inc dword[(ebp+ebp+ebp-ebp)]              ; ==> [(ebp*2) + 00000000h] - ds by default
inc dword[ss: (ebp+ebp+ebp-ebp)]  ; ==> [ebp+ebp+00h] without "ss:" - ss by default

_________________
I am not young enough to know everything (Oscar Wilde)-

29 Jun 2010, 23:48

ouadji

Joined: 24 Dec 2008
Posts: 1081
Location: Belgium

ouadji 01 Jul 2010, 15:19

NASM vs FASM (quick test)

NASM
------

Code:

inc dword [ebp+ebp]
inc dword [ebp*2]
inc dword [ebp+ebp+(ebp*3)-ebp-(ebp*2)]

results
-------
a) 0FFh, 44h, 2Dh, 00h
b) 0FFh, 44h, 2Dh, 00h
c) 0FFh, 44h, 2Dh, 00h

FASM
------

Code:

inc dword [ebp+ebp]
inc dword [ebp*2]
inc dword [ebp+ebp+(ebp*3)-ebp-(ebp*2)]

results
-------
a) 0FFh, 44h, 2Dh, 00h
b) 0FFh, 44h, 2Dh, 00h
c) 0FFh, 44h, 2Dh, 00h

0FFh, 44h, 2Dh, 00h == inc dword [ebp+ebp]

NASM builds the same code as FASM,
apparently, NASM has a algebra engine like FASM and makes exactly the same mistake ! Shocked

(about "ss:")
thus I keep Fasm, because fasm is nevertheless much better ! Wink

_________________
I am not young enough to know everything (Oscar Wilde)-

01 Jul 2010, 15:19

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20299
Location: In your JS exploiting you and your system

revolution 01 Jul 2010, 15:57

Code:

inc dword [ds:ebp+ebp]
inc dword [ds:ebp*2]
inc dword [ds:ebp+ebp+(ebp*3)-ebp-(ebp*2)]

results
-------
a) 0x3e,0xff,0x44,0x2d,0x00
b) 0x3e,0xff,0x44,0x2d,0x00
c) 0x3e,0xff,0x44,0x2d,0x00


inc dword [ss:ebp+ebp]
inc dword [ss:ebp*2]
inc dword [ss:ebp+ebp+(ebp*3)-ebp-(ebp*2)]

results
-------
a) 0xff,0x44,0x2d,0x00
b) 0xff,0x44,0x2d,0x00
c) 0xff,0x44,0x2d,0x00

01 Jul 2010, 15:57

chaoscode

Joined: 21 Nov 2006
Posts: 64

chaoscode 07 Jul 2010, 10:47

what about that:
do what the user enters, if it is possibile.
(even it's not the best way.)
if it's not possibile try to modify it.
Example
[ebp*2] -> [ebp*2]
[ebp+ebp]-> [ebp+ebp]
[ebp*3] not possibile, try to modifie it ( will result in [ebp*2+ebp])

07 Jul 2010, 10:47

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20299
Location: In your JS exploiting you and your system

revolution 07 Jul 2010, 11:21

chaoscode wrote:

what about that:
do what the user enters, if it is possibile.
(even it's not the best way.)
if it's not possibile try to modify it.
Example
[ebp*2] -> [ebp*2]
[ebp+ebp]-> [ebp+ebp]
[ebp*3] not possibile, try to modifie it ( will result in [ebp*2+ebp])

So what would be [ebp+ebp*2-ebp]?

07 Jul 2010, 11:21

ouadji

Joined: 24 Dec 2008
Posts: 1081
Location: Belgium

ouadji 07 Jul 2010, 11:56

add separately terms with +/- and terms with '*'.

"ebp+ebp*2-ebp"

+/- : +1 -1 = 0

* : +2

result : ebp*2

give priority to the positive term.

(ebp*4)-ebp-ebp ---> (ebp*2)

ebp+ebp+ebp+ebp-(ebp*2) ---> ebp+ebp

_________________
I am not young enough to know everything (Oscar Wilde)-

07 Jul 2010, 11:56

Goto page Previous 1, 2

< 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