Re: Immediate arguments optimizer fails

>  > That is, PUSH imm without an explicit size
specified currently
>  > does not know how to optimize down to an sbyte
encoding.
>
>  Wrong.
>
>  : tazenda 56 ; cat push.lst
>       1                                          bits
32
>       2 00000000 6A01                            push
1
>       3 00000002 68FFFFFFFF                      push
0ffffffffh
>       4 00000007 6AFF                            push
-1
>       5
>       6                                          bits
64
>       7 00000009 6A01                            push
1
>       8 0000000B 68FFFFFFFF                      push
0ffffffffh
>       9 00000010 6AFF                            push
-1

Are you using any command line options?

I ask because I get a dword encoding for 1 and -1. (This is
with no command line options other than -l for a .lst
file.)

    18 00000024 68FFFFFFFF              push -1        ;
could pick
sbyte encoding, but doesn't
    19 00000029 6AFF                    push byte -1       
; picks
sbyte encoding as requested
    20 0000002B 6AFF                    push strict byte -1 
      ;
picks sbyte encoding as requested
    21
    22 0000002D 6801000000              push 1        ;
could pick
sbyte encoding, but doesn't
    23 00000032 6A01                    push byte 1        ;
picks
sbyte encoding as requested
    24 00000034 6A01                    push strict byte 1  
     ;
picks sbyte encoding as requested

>  As you can see, it gets the sbyte encoding just fine,
*except* in the
>  case where it is necessary to take truncation into
account.  This is the
>  fundamental design flaw in the optimizer: it runs too
early, on the
>  parser representation, but at that point it is not
known what width the
>  operand has and therefore if it can be optimized down
to an sbyte after
>  truncation is accounted for.

Well, your example demonstrates exactly what I said.  

While 1 and -1 do fit into an sbyte, 0xFFFF_FFFF doesn't:
that's 0x0000_0000_FFFF_FFFF, thanks to the evaluator
being 64-bit. As a result, the parser won't pick sbyte for
it,
the assembler will see PUSH imm (i.e. no explicit size) --
and you get the word/dword encoding (34).

In general I believe that NASM does not need to be fixed
here. Instead the user should write better code.

Case in point -- C is affected by this too:

> cat _32bit.c
#if 0xFFFFFFFF == -1
#error equal
#else
#error different
#endif

> cat _64bit.c
#if 0xFFFFFFFFFFFFFFFF == -1
#error equal
#else
#error different
#endif

> tcc _32bit.c
Turbo C++  Version 1.01 Copyright (c) 1990 Borland
International
_32bit.c:
Error _32bit.c 2: Error directive: equal

> tcc _64bit.c
Turbo C++  Version 1.01 Copyright (c) 1990 Borland
International
_64bit.c:
Error _64bit.c 2: Error directive: equal

> gcc _32bit.c
_32bit.c:4: #error different

> gcc _64bit.c
_64bit.c:2: #error equal

Note the difference between a 32- and a 64-bit compiler.

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel

anonymous coward wrote:
> 
> Are you using any command line options?
> 

-Ox, since we're talking about the optimizer.

> 
> Well, your example demonstrates exactly what I said. 

> 
> While 1 and -1 do fit into an sbyte, 0xFFFF_FFFF
doesn't:
> that's 0x0000_0000_FFFF_FFFF, thanks to the evaluator
> being 64-bit. As a result, the parser won't pick sbyte
for it,
> the assembler will see PUSH imm (i.e. no explicit size)
--
> and you get the word/dword encoding (34).
> 
> In general I believe that NASM does not need to be
fixed
> here. Instead the user should write better code.
> 

No, that's bunk.  The whole point of the optimizer is so the
programmer 
doesn't have to deal with that kind of junk.

	-hpa

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel