Re: Bignums and .sleb128

[Richard Sandiford <rsandifo@redhat.com>]

Daniel Jacobowitz <drow@false.org> writes:
>> You said later that:
>> 
>> > If we're going to use these semantics, at least the '-' case in
>> > operand() needs to be fixed.
>> 
>> but I wasn't sure what you meant by "these semantics".  Do you mean
>> treating bignums as signed, or treating them as unsigned?  By my reading,
>> operand()'s current handling of '-' already assumes they are signed,
>> just like the sleb128 code does (and did ;).
>
> It doesn't work, because sometimes bignums are signed and sometimes
> they aren't.  Consider -0xffffffffffff; the current code will return 1. 
> If you want to treat the input as unsigned, then you need to add a new
> word with the sign bit.  Note that with one less leading 'f', it
> suddenly works.

Right, that's exactly the point I made later.  Like you say, if you
treat the bignum as signed (as the current '-' code does), then
{0xffff, 0xffff, 0xffff} is an invalid representation of a positive
number, it should be {0xffff, 0xffff, 0xffff, 0x0000} instead.
So the '-' code _does_ seem OK if you treat bignums as signed,
the problem is that the integer parsing code is still assuming
that bignums are unsigned, and that the extra 0x0000 littlenum
isn't needed.

I couldn't tell whether that's what you were saying too, or whether
you think that opcode() is wrong even if bignums are treated as signed.
It's quite possible we're in violent agreement here ;)

> One approach to fix the problem would be to define X_unsigned as a
> secondary "sign bit" for the bignum.  The core changes for that would
> be easy.  It's the backends that bother me.

I guess that's one way, but both existing bits of "bignums are signed"
code just use the top bit of the bignum as the sign bit.  Maybe that is
the most natural representation?

Richard