flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > 1.70.01 fails on lea ecx,[$3fff+64-$3fff-(not 30 + 32)]

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
idle



Joined: 06 Jan 2011
Posts: 440
Location: Ukraine
idle 11 Jun 2012, 09:13
Code:
                       ;=neg 30 + 31
lea ecx,[$3fff+64-$3fff-(not 30 + 32)] ;fasm 1.70.01, value out of range
         /        /
              +64      -(not 30 + 32)
              +64      -(neg 30 + 31)
              +64      -           1
               63
    
Post 11 Jun 2012, 09:13
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20363
Location: In your JS exploiting you and your system
revolution 11 Jun 2012, 09:43
not 30 = 0xFFFF'FFE1

32 = 0x0000'0020

not 30 + 32 = 0x1'0000'0001 (does not fit into 32 bits)

BTW: your code assembles when I use "use16". It appears that you are using "use32". Is that correct?
Post 11 Jun 2012, 09: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: 20363
Location: In your JS exploiting you and your system
revolution 11 Jun 2012, 09:53
In 16-bit mode we get this:
Code:
lea ecx,[(not 30 + 32)] ;lea ecx,[0x0001'0001]    
I think this is a bug.
Post 11 Jun 2012, 09:53
View user's profile Send private message Visit poster's website Reply with quote
idle



Joined: 06 Jan 2011
Posts: 440
Location: Ukraine
idle 11 Jun 2012, 11:27
i really used 32
Post 11 Jun 2012, 11:27
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 11 Jun 2012, 11:34
revolution wrote:
In 16-bit mode we get this:
Code:
lea ecx,[(not 30 + 32)] ;lea ecx,[0x0001'0001]    
I think this is a bug.
In 16-bit mode the default addressing size is WORD, so "not 30" equals 0FFE1h in this case. If you write "lea ecx,[dword (not 30 + 32)]" in 16-bit mode, you will get the same overflowing calculation as in 32-bit mode.

However I'm not sure, why in 16-bit mode the address size gets upgraded instead of overflowing. This may have been for backward compatibility, I'm not really sure of my memory here.

So if you write "lea ecx,[word (not 30 + 32)]" you'll also get an overflow, but when you write "lea ecx,[(not 30 + 32)]" the overflow becomes the upgrade to 32-bit addressing.
Post 11 Jun 2012, 11:34
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: 20363
Location: In your JS exploiting you and your system
revolution 11 Jun 2012, 12:39
Okay, I understand your explanation.

But this feels wrong and unintuitive:
Code:
use16
lea ecx,[eax+not 0] ;lea ecx,[eax+0xFFFF]
use32
lea ecx,[eax+not 0] ;lea ecx,[eax+0xFFFFFFFF]    
Inside the brackets I was expecting a 32-bit address since it is a 32-bit instruction. eax is always 32-bit but the offset doesn't always match the size of the register. Confused
Post 11 Jun 2012, 12:39
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 11 Jun 2012, 12:58
revolution wrote:
Inside the brackets I was expecting a 32-bit address since it is a 32-bit instruction.
32-bit operand size and 32-bit addressing mode are two separate things. With USE16 "lea ecx,[-1]" is like "lea ecx,[si]", it has only 66h prefix and puts 0FFFFh into ECX, while "lea ecx,[dword -1]" has also 67h prefix (like "lea ecx,[esi]") and puts 0FFFFFFFFh into ECX.
Post 11 Jun 2012, 12:58
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: 20363
Location: In your JS exploiting you and your system
revolution 11 Jun 2012, 13:00
Tomasz Grysztar wrote:
32-bit operand size and 32-bit addressing mode are two separate things.
But the use of eax in my example forces 32-bit addressing.
Post 11 Jun 2012, 13:00
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 11 Jun 2012, 13:01
Oh, I thought we were still discussing that previous issue. Yes, this one is problematic.
Post 11 Jun 2012, 13:01
View user's profile Send private message Visit poster's website Reply with quote
ouadji



Joined: 24 Dec 2008
Posts: 1081
Location: Belgium
ouadji 11 Jun 2012, 14:43
just my opinion ...

In 16-bit mode, the default addressing size is WORD ... ok.

But ... if the use of eax forces 32-bit addressing,
then this is no longer the default addressing mode.

in this case, the offset size is no longer the default offset size either. (word)
therefore, in this case, the offset size should be again 32-bit

_________________
I am not young enough to know everything (Oscar Wilde)- Image
Post 11 Jun 2012, 14:43
View user's profile Send private message Send e-mail Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20363
Location: In your JS exploiting you and your system
revolution 12 Jun 2012, 14:27
Tomasz Grysztar wrote:
However I'm not sure, why in 16-bit mode the address size gets upgraded instead of overflowing. This may have been for backward compatibility, I'm not really sure of my memory here.

So if you write "lea ecx,[word (not 30 + 32)]" you'll also get an overflow, but when you write "lea ecx,[(not 30 + 32)]" the overflow becomes the upgrade to 32-bit addressing.
I think the automatic upgrade of address size is not the right thing to do in the "lea ecx,[(not 30 + 32)] ;lea ecx,[0x0001'0001]" example above.
But I will probably keep the special handling of "not", "xor" and "shr" operators when operating in "sized" environment. So they will operate like 2-adic only when no size context is specified.
I find myself thinking that the sized environment for "not", "xor" and "shr" is now perhaps not needed, and also maybe creates more confusion that it solves. With the new infinite size (currently 65-bit) computations can we forgo the sized computations?
Post 12 Jun 2012, 14:27
View user's profile Send private message Visit poster's website Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode 16 Jun 2012, 13:32
Quote:
I think the automatic upgrade of address size is not the right thing to do in the "lea ecx,[(not 30 + 32)] ;lea ecx,[0x0001'0001]" example above.
bingo!! you got it now
and on the contrary, whenever the datasize has been specified,
there's no capable environment to get this compiled with fasm
Code:
 mov eax,word (not 30 + 32)     

where the meaning is simple and straightforward: use32 MOV instro
with word immediate after the comma corresponding to a
wrapped-around value of 1 from 1'0001h ANDed to WORD 0FFFFh,
just because it is said "WORD" there, right from left.

several forumers here (me included) opened threads
related to that unresolved matter of pre-procedural coherence.
but it seems you understated it... a bit, or you answered
telling general stories about fasm being focused on instructions.
well,as you can see above,it is.
Quote:
...the sized environment for "not", "xor" and "shr" is now perhaps not needed, and also maybe creates more confusion that it solves.
With the new infinite size (currently 65-bit) computations can we forgo the sized computations?
it may be possible with fasm, at certain effort. but that's nonsensical for now, with the actual design.

Because even on what you call "the new infinite size (currently 65-bit)",
there is no way to make QWORD preprocedural computations in order to get back
for example the MODed result before a computational overflow occurs;
nor it concretely as it should be: the wrapped result of them after overflows.
i.e.: the same design incoherence applies/propagates at the moment
to whatever new neverending story too, or 1.69 at least.

and i would like to recall you now that the just thinking at that TASM-like-way-65th-bit-of-the-signing-bit thingy thing makes actually the whole thing on design
- rather obsolete (i.e. there's nothing new in a technological sense)
- not infinite, for a matter of konkreteness, they are only and ever 64 bit.

where nowadays needs are rather about managing, as example and
simply, floating point values at a preprocedural stage., instead of
loosing time on implementing the dizziness-ing new features of "rept".

and that's obviously, imho.
Smile
Cheers,

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 16 Jun 2012, 13:32
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: 20363
Location: In your JS exploiting you and your system
revolution 16 Jun 2012, 15:27
hopcode wrote:
Because even on what you call "the new infinite size (currently 65-bit)", there is no way to make QWORD preprocedural computations in order to get back
for example the MODed result before a computational overflow occurs;
nor it concretely as it should be: the wrapped result of them after overfl
Yes there is a way. If "not 0" is taken as the infinite precision result then we get -1 as the answer. And something like "not 30 + 32" becomes "-31 + 32" == +1.

Similarly things like "db -1 xor 0x80" can be manually forced to byte with a final "and 0xff". It is only a quirk of the current fasm that the programmer does not need to force manual final masking, but there is no real mathematical argument to support automatic masking.
Post 16 Jun 2012, 15:27
View user's profile Send private message Visit poster's website Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode 16 Jun 2012, 17:24
Code:
 ...but there is no real mathematical argument to support automatic masking...    
exactly. in fact that's not a matter of what is mathematically agreed under such an expression: "not 0".
btw, i have seen preprocessors out there making such assumptions:
bad desing, because 0 in there should be considerd rather/firstly
as an expression than a numerical-symbol. also, this is another matter.

on "db -1 xor 0x80" there's no need of a final AND 0FFh,
because just said explicitedly there in "DB", reading it Lx <- Rx.
anyway, back on the "instructional" point of view
Code:
 alfa equ 80000000'00000000h
 alfa equ alfa * 2
 mov rax,alfa  ;--- error: value out of range.     
but
Code:
 alfa equ 80000000'00000000h
 alfa equ alfa shl 1
 mov rax,alfa  ;--- ok     
now, while signaling OF-warning in the 2nd case would be ok,
stopping compilation on the first one, because out of range, should be an hint to reload the design of the preprocessor.

Cheers,

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 16 Jun 2012, 17:24
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: 20363
Location: In your JS exploiting you and your system
revolution 16 Jun 2012, 17:50
hopcode wrote:
on "db -1 xor 0x80" there's no need of a final AND 0FFh,
because just said explicitedly there in "DB", reading it Lx <- Rx.
i can't agree here. What if I put "db 0x100"? Automatic masking there is not desirable.
Post 16 Jun 2012, 17:50
View user's profile Send private message Visit poster's website Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode 17 Jun 2012, 13:33
Quote:
What if I put "db 0x100"?
why supposing ?
it has been already discussed several times; Tomasz's developemnt line seems
plain and already clarified afterall, whenever someone may have in those threads
different opinions.

afaik, writing db 100h should be considered an error, when after fasm's
basic rules, i.e when DB comes not from a redefinition at a preprocedural tage.
and this case "db -1 xor 0x80" is more complex than the one above. there is
a XOR operation from 2 quantities but, finally, front-end and humans
should conform their output upon those basic rules (i.e. unless redefined).

Cheers,

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 17 Jun 2012, 13:33
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: 20363
Location: In your JS exploiting you and your system
revolution 17 Jun 2012, 16:27
What about "db -1 xor 0x100 "?
Post 17 Jun 2012, 16:27
View user's profile Send private message Visit poster's website Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode 18 Jun 2012, 14:09
Quote:
What about "db -1 xor 0x100 "?
you need perhaps some spare time for you or summer holidays.
well, while this
Code:
 display_hex 32,80000000h xor (-1 xor 100h) ;--- 7FFFFEFF     
is partially correct because -1 has an unspecified size/type; and this one
Code:
 display_hex 64,80000000h xor (-1 xor 100h) ;--- FFFFFFFF7FFFFEFF     
results to be an arbitrary assumption because i didnt tell it i need FFFFFFFF
in the hi part, whenever computation are on 64bit now,
the following equ allow us to write such extensible but flawed code (imho)
Code:
beta equ -1 and (80000000h  xor (-1 xor 100h))
 mov al,beta       ;--- B0 FF
 mov ax,beta      ;--- 66 B8 FFFF
 mov eax,beta        ;--- B8 FFFFFFFF
 mov rax,beta       ;--- 48 C7C0 FFFFFFFF with sign extension to -1
    
then we can turn the ice-cream upside down on use64 using the largest mask we know in the form of expression : not 0
Code:
 gamma equ (not 0) and (80000000h  xor (-1 xor 100h))
 mov al,gamma  ;--- B0 FF
 mov ax,gamma     ;--- 66 B8 FFFE
 mov eax,gamma       ;--- B8 FFFEFF7F
 mov rax,gamma      ;--- 48 B8 FFFEFF7FFFFFFFFF so encoded !!
    
to get exactly what we want except for the 64 bit line because, again, it should have been in this following form, for one more and severe reason now
Code:
 mov rax,gamma ;--- as 48 C7C0 FFFFFF7F i.e: with positive sign extension     

Cheers,

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 18 Jun 2012, 14:09
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: 20363
Location: In your JS exploiting you and your system
revolution 04 Jul 2012, 02:33
Tomasz Grysztar wrote:
Yes, this one {lea ecx,[eax+not 0]} is problematic.
Does this mean you intend to fix it? Or is it something that we should take note of and be aware of to avoid problems?
Post 04 Jul 2012, 02:33
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 06 Jul 2012, 11:01
I did give it some thought and I concluded that fixing it would require creating some more complex rules (because you are allowed to create multi-level expressions with various kinds of registers) - and I think I prefer to stay with current one, which has flaws, but at least these behaviors are relatively simple to predict. I may add some statement to manual, which would clarify that in the address expression the default size context is always assumed to be the same as the current bitness of code.
Post 06 Jul 2012, 11:01
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 1, 2  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.