Re: Bignums and .sleb128

[Richard Sandiford <rsandifo at redhat dot com>]

Daniel Jacobowitz <drow@false.org> writes:
> I spent most of this morning chasing a bug in .sleb128 support.  After
> I finished running around in circles and discovered that Richard Sandiford
> had fixed it two weeks ago (thanks!) I compared the testcases I'd written
> with the ones that he committed.  There were a couple of differences,
> basically related to this comment from bignum.h:
>
>  *      Bignums are >= 0.                                               *

Ugh, didn't notice that, sorry.  But I think that comment fell by the
wayside the moment we tried to handle '-' for O_bigs.  After all, the
precision of bignums is completely arbitrary, so if the result of
-bignum is supposed to be unsigned, there's no obvious cut-off
point for the sign extension.

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 ;).

> So generating a sleb128 from one is pretty strange - the sign bit is
> ambiguously handled.

Perhaps, but the problem isn't limited to sleb128.  E.g.:

	.quad	-0xffffffffffff

acts in the same way as ".quad 1", not ".quad 0xffff000000000001".

The direction of recent changes suggests there really is a need
for negative bignums, so IMO we should try to support them.

Richard