I don't understand why not.

If you need to compare values as signed, you may need something like "load signed" - exactly what LocoDelAssembly proposed.

macro def [name, size]
{
forward
local n

   rept 1 s:(size)-1\{n equ s\} ; To avoid having the assembler to calculate (size - 1) each time twice

   macro signExtend.#name v.out, v.in
   \{
      v.out = v.in or (0 - v.in shr n) shl n
   \}
}

def byte,  8,\
    word, 16,\
   dword, 32,\
   qword, 64

purge def    

Would this if-less version work and be compatible with any future extra precision?

But still, I think something like "load signed" should be native, and also store and data definition directives should support both signed and unsigned for easy range checking (if nothing is specified then the default is used which is the union of both if I understand the current behavior correctly)

The purpose is to sort the original values passed to the macro.

alpha = alpha or -1
if alpha < 1
  display "bit 65th set" ; This is what I'm expecting
else
  display "bit 65th not set"
end if    

Tomasz, it seems I'm a bit confused on how you'll implement the extra precision. What would be the following code display?

Code:

alpha = alpha or -1
if alpha < 1
  display "bit 65th set" ; This is what I'm expecting
else
  display "bit 65th not set"
end if    

If the code above does what I expect, why shl would cause overflow? Shouldn't it behave like multiplying by a power of 2?

As for store, it is not like it needs a special handling, but it is just for the programmers' convenience, for instance "db signed -1" should assemble while "db unsigned -1" should fail and "db signed 255" should also fail.

PS: My macro is supposed to sign extend the value and make sure fasm detects the number as negative if the sign bit was set in the original (smaller than fasm's internal representation) size. Am I right in assuming that fasm will continue to have two's complement arithmetic and bit-wise logic?

This is not possible with old fasm, either. You sort only the qword representations of the computed values.

For example, if you have "-1" and "$FFFF'FFFF'FFFF'FFFF" values, they have the same qword representation

This is possible, because the qword representation is the complete representation of a (zero-based) value in the current fasm implementation, which is going to be changed.

Yes. And they are also equal. In current fasm implementation it's just the same value.

I will leave the possible overflow errors under clause "when assembler is not able to maintain the precision required to give the right result"

macro dispDec num*
{
  local digCount,tenPow,number

    number = num
        if number < 0
            display '-'
               number = -number
    end if
      digCount = 0
        tenPow = 1
  while tenPow <= number
           tenPow = tenPow*10
          digCount = digCount + 1
     end while
   if digCount = 0
             digCount = 1
                tenPow = 10
 end if
      repeat digCount
             tenPow = tenPow/10
          display number/tenPow + '0'
               number = number mod tenPow
  end repeat
}    

macro dispDec num*
{
     local digCount,tenPow,number

    number = num
        if number < 0
            display '-'
               number = -number
    end if
      digCount = 0
        tenPow = 1
  while tenPow <= number & tenPow < 1000000000000000000 ;an additional check for higher values!
             tenPow = tenPow*10
          digCount = digCount + 1
     end while
   if digCount = 0
             digCount = 1
                tenPow = 10
 end if
      ;some more additional checks
        if tenPow > number
               tenPow = tenPow/10
  else
                digCount = digCount + 1
     end if
      
    repeat digCount
             display number/tenPow + '0'
               number = number mod tenPow
          tenPow = tenPow/10
  end repeat
}    

macro dispDec num*
{ 
        local digCount,tenPow,number 

        number = num 
        if number < 0 
                display '-' 
                number = -number 
        end if 
        digCount = 0 
        tenPow = 1 
        while tenPow <= number 
                tenPow = tenPow*10 
                digCount = digCount + 1 
        end while 
        if digCount = 0 
                digCount = 1 
                tenPow = 10 
        end if 
        repeat digCount 
                tenPow = tenPow/10 
                display number/tenPow + '0' 
                number = number mod tenPow 
        end repeat 
}

dispDec 0x7fffffffffffffff    

Now a fly in the ointment comes. As long as the author does not specify the internal assembler word size, he's forcing me to find the value of 1000000000000000000 empirically. Well, not a problem. But after all the author is changing the assembler internal word size and then states, that's my responsibility for using undocumented features and therefore for the fact, that nothing works anymore.

So don't you think it's better to make such a crucial thing like the highest possible precision a part of specification? Wouldn't you be astonished if Intel said: "Oh, eax is a register of some size which we won't document, but if you exceed that size, we will notify you with a triple fault"? Because that's exactly your current approach: "I leave many things implementation dependent and undocumented forcing the programmers to empirically investigate them, but at least I'm then able to change those things making the half of all written macros inoperative".

How would anything stop to work? Your display macro would still be able to display all the values it was able to - it may not be able to display some new super-large numbers that assembler is suddenly able to also calculate on, but neither it was able to display them earlier.

P.S. I appreciate, that you continue to answer my posts, even though I may appear very stubborn.

Why not go for something a bit less aspiring, like "a macro that displays decimal values in signed 64-bit range", etc.?

macro signExtend.qword v.out, v.in {
    if ~ v.in and 8000000000000000h
      v.out = v.in
    else
      v.out = v.in and 7FFFFFFFFFFFFFFFh - 8000000000000000h
    end if
}

x = qword -823543
signExtend.qword a,x

assert x>0
assert a<0

_x dq x
_a dq a

load xd qword from _x
load ad qword from _a

assert xd=ad    

MAX_QWORD_SIGNED equ 0x7fffffffffffffff
;Test 1. Compiles OK.
myvar1 = -MAX_QWORD_SIGNED
myvar1 = myvar1*2-2

;Test 2. Compiles OK.
myvar2 = -MAX_QWORD_SIGNED-1
myvar2 = myvar2 shl 1

;Test 3. Fails.
myvar3 = -MAX_QWORD_SIGNED-1
myvar3 = myvar3*2    

Is this the expected behaviour?

x = not 0xffffffffffffffff
x = x * 1 ;error: value out of range.
x = x / 1 ;error: value out of range.