Actually I wonder wether that was the behaviour originally intended by Matt.
The DASM documentation states that DASM's expression evaluator internally
treats everything as 32 bit unsigned value, thus it's kind of logical that
the literal -1 is treated as 0xffffffff (which was the effect of changing
SYMBOL.value from signed to unsigned). The whole DASM source is a mess of
differently typed/sized/signed and constantly mixed variables and should
be rewritten from the ground up.
>-- Original-Nachricht --
>From: "B. Watson" <atari@xxxxxxxxxxxxxx>
>To: stella@xxxxxxxxxxxxxxxxxx
>Subject: RE: [stella] DASM update -- 2.20.10b
>Date: Mon, 15 Aug 2005 16:06:58 -0400
>Reply-To: stella@xxxxxxxxxxxxxxxxxx
>
>
>
>
>On Mon, 15 Aug 2005 mathys66@xxxxxxxxxx wrote:
>
>> Version 2.20.07 had a typedef called ulong (in asm.h):
>>
>> typedef long ulong;
>>
>> Note that this is actually a signed value, although the typedef's name
>suggests
>> it's unsigned. In version 2.20.10 this typedef has been removed, and all
>> (?) occurences of ulong have been replaced by "unsigned long".
>
>Whoops, sorry about that. That was partly my fault: I suggested getting
>rid of that typedef because it was conflicting with some system header's
>definition of "ulong" when trying to compile DASM on Linux.
>
>Of course, "typedef long ulong" is pretty misleading, so I got
>misled. About like my ex-girlfriend who had two cats named Dog and Fish
:)
>
>--
>B.
>Archives (includes files) at http://www.biglist.com/lists/stella/archives/
>Unsub & more at http://stella.biglist.com
>
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://stella.biglist.com
