Re: [cc65] Expression usage question

On Fri, Apr 09, 2004 at 05:03:40AM -0700, David Holz wrote:
> If you're going to choose one sign, I'd say make it unsigned.  Unsigned
> numbers are a bit more "literal", as bits in your number directly translate
> into bits, and we assembly programmers like that. :)  But if A = -1 and A =
> $ffffffff both end up being the same thing (ie, the $ffffffff doesn't give
> an out-of-range error in signed mode), I doubt it will even matter what the
> internal representation is, though unsigned would be my preference.

The problem in making values always unsigned is that there is no longer any
way to work with signed numbers. Dividing -3 by -1 gives a different result
than dividing $FFFFFFFC by $FFFFFFFF. If the assembler handles all values
internally as unsigned, the former will no longer work. And it will not work
for *any* negative value. On the other side, when always handling values as
signed, problems for unsigned values only arise of bit 31 is 1, something that
should be quite rare because the platform we're using doesn't support such
values directly.

I'm myself a strong supporter of using unsigned types where a value cannot
become negative. But in case of ca65, there is currently just one numeric data
type, and in this case I cannot rule out negative values, so interpreting
anything as unsigned is not really an option.

> I'd prefer to leave shifts as unsigned shifts, and add signed shift
> operators.  This would mirror 6502 functionality, where you'd need to to
> something special to make a shift signed, and since this is a 6502 family
> assembler it would be reasonable to have signedness assumptions be
> consistent between the assembly code and the pseudo-ops.

Sounds reasonable on the first glance, but there's also a counter argument.
The current .shr and .shl operators assume unsigned arguments (both, for the
left hand side and the shift count). This will continue to work, and there
will be new .asr/.asl operators that treat the operands as signed. But since
the default interpretation of values would be signed, I would like to change
the meaning of the undocumented << and >> operators to also work on signed
values. What you wrote about unsigned shifts being more natural for the
platform is absolutely correct, but having an operator that breaks the
signedness rules that all other operators adhere to, is not a good idea
either. If the / operator works correctly for signed values, but >> does not,
this might be confusing. It is exactly this non deterministic handling of the
current assembler version, that I would like to change.

Are you using the >> operator in your code? If so, do you depend on the fact
that is is treating its arguments as unsigned values? If the arguments are
always smaller than 32 bit, nothing will change.

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz@musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.