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 |
|
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 |
|||
11 Jun 2012, 09:13 |
|
revolution 11 Jun 2012, 09:53
In 16-bit mode we get this:
Code: lea ecx,[(not 30 + 32)] ;lea ecx,[0x0001'0001] |
|||
11 Jun 2012, 09:53 |
|
idle 11 Jun 2012, 11:27
i really used 32
|
|||
11 Jun 2012, 11:27 |
|
Tomasz Grysztar 11 Jun 2012, 11:34
revolution wrote: In 16-bit mode we get this: 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. |
|||
11 Jun 2012, 11:34 |
|
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] |
|||
11 Jun 2012, 12:39 |
|
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. |
|||
11 Jun 2012, 12:58 |
|
revolution 11 Jun 2012, 13:00
Tomasz Grysztar wrote: 32-bit operand size and 32-bit addressing mode are two separate things. |
|||
11 Jun 2012, 13:00 |
|
Tomasz Grysztar 11 Jun 2012, 13:01
Oh, I thought we were still discussing that previous issue. Yes, this one is problematic.
|
|||
11 Jun 2012, 13:01 |
|
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 |
|||
11 Jun 2012, 14:43 |
|
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. Tomasz Grysztar at http://board.flatassembler.net/topic.php?p=141363#141363 wrote: 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. |
|||
12 Jun 2012, 14:27 |
|
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. 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. 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. Cheers, _________________ ⠓⠕⠏⠉⠕⠙⠑ |
|||
16 Jun 2012, 13:32 |
|
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 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. |
|||
16 Jun 2012, 15:27 |
|
hopcode 16 Jun 2012, 17:24
Code: ...but there is no real mathematical argument to support automatic masking... 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. Code: alfa equ 80000000'00000000h alfa equ alfa shl 1 mov rax,alfa ;--- ok stopping compilation on the first one, because out of range, should be an hint to reload the design of the preprocessor. Cheers, _________________ ⠓⠕⠏⠉⠕⠙⠑ |
|||
16 Jun 2012, 17:24 |
|
revolution 16 Jun 2012, 17:50
hopcode wrote: on "db -1 xor 0x80" there's no need of a final AND 0FFh, |
|||
16 Jun 2012, 17:50 |
|
hopcode 17 Jun 2012, 13:33
Quote: What if I put "db 0x100"? 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, _________________ ⠓⠕⠏⠉⠕⠙⠑ |
|||
17 Jun 2012, 13:33 |
|
revolution 17 Jun 2012, 16:27
What about "db -1 xor 0x100 "?
|
|||
17 Jun 2012, 16:27 |
|
hopcode 18 Jun 2012, 14:09
Quote: What about "db -1 xor 0x100 "? well, while this Code: display_hex 32,80000000h xor (-1 xor 100h) ;--- 7FFFFEFF Code: display_hex 64,80000000h xor (-1 xor 100h) ;--- FFFFFFFF7FFFFEFF 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 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 !! Code: mov rax,gamma ;--- as 48 C7C0 FFFFFF7F i.e: with positive sign extension Cheers, _________________ ⠓⠕⠏⠉⠕⠙⠑ |
|||
18 Jun 2012, 14:09 |
|
revolution 04 Jul 2012, 02:33
Tomasz Grysztar wrote: Yes, this one {lea ecx,[eax+not 0]} is problematic. |
|||
04 Jul 2012, 02:33 |
|
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.
|
|||
06 Jul 2012, 11:01 |
|
Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.