Topic: problem with evluation of expressions (1 of 8), Read 19 times
Conf: VEDIT Macro Language Support
From: Bernd Richert
Date: Saturday, January 08, 2005 12:38 PM

I have experienced problems with the evaluation of expressions that include the logical AND operator.

As an example, I'll give you what I got from a command mode session.

COMMAND: $#14
0x0300:0001
COMMAND: $#14&0xFFFFFFFF
0x00
COMMAND: (#14&0xFFFFFFFF)==0
0

The 2nd output should have been '0x0300:0001'.
If #14&0xFFFFFFFF is null, then the 3rd output should have been '1'.

Bernd

 


Topic: Re: problem with evluation of expressions (2 of 8), Read 21 times
Conf: VEDIT Macro Language Support
From: Christian Ziemski
Date: Saturday, January 08, 2005 05:18 PM

On Sat, 08 Jan 2005 00:38:00 -0500, Bernd Richert wrote:

>I have experienced problems with the evaluation of expressions
>that include the logical AND operator.
>
>As an example, I'll give you what I got from a command mode session.
>
>COMMAND: $#14
>0x0300:0001
>COMMAND: $#14&0xFFFFFFFF
>0x00
>COMMAND: (#14&0xFFFFFFFF)==0
>0
>
>The 2nd output should have been '0x0300:0001'.
>If #14&0xFFFFFFFF is null, then the 3rd output should have been '1'.


That is simply a numeric overflow within the calculation.

Try it with 0x7FFF:FFFF instead.

0xFFFF:FFFF is too big for the 32-Bit Vedit. It's MAXNUM is
0x7FFF:FFFF.

Or you can try it with the 64-Bit Vedit. That MAXNUM of
0x7FFF:FFFF:FFFF:FFFF should be big enough...


Christian

 


Topic: Re: problem with evluation of expressions (3 of 8), Read 18 times
Conf: VEDIT Macro Language Support
From: Bernd Richert
Date: Sunday, January 09, 2005 06:38 AM

I can accept that 0xFFFFFFFF is beyond MAXNUM. Meanwhile I have seen that
COMMAND: 0xFFFFFFFF
..produces the output '0'.

Consequently
COMMAND: #14&0xFFFFFFFF
..does also produce '0' - ok.

But why does then
COMMAND: (#14&0xFFFFFFFF)==0
..also produce '0' - ???

Regards
Bernd

 


Topic: Re: problem with evluation of expressions (4 of 8), Read 17 times
Conf: VEDIT Macro Language Support
From: Christian Ziemski
Date: Sunday, January 09, 2005 12:34 PM

On Sun, 09 Jan 2005 06:38:00 -0500, Bernd Richert wrote:

>I can accept that 0xFFFFFFFF is beyond MAXNUM.
>Meanwhile I have seen that COMMAND: 0xFFFFFFFF
>..produces the output '0'.
>
>Consequently
>COMMAND: #14&0xFFFFFFFF
>..does also produce '0' - ok.
>
>But why does then
>COMMAND: (#14&0xFFFFFFFF)==0
>..also produce '0' - ???

It may be an error-0 and not the result 0.

I think all calculations with values beyond MAXNUM make the complete
result invalid.

So you shouldn't use those values!

Perhaps Ted can give more infos?


Christian

 


Topic: Re: problem with evluation of expressions (5 of 8), Read 21 times
Conf: VEDIT Macro Language Support
From: Ted Green
Date: Sunday, January 09, 2005 01:12 PM

At 06:39 AM 1/9/2005, you wrote:
>I can accept that 0xFFFFFFFF is beyond MAXNUM. Meanwhile I have seen that
>COMMAND: 0xFFFFFFFF
>..produces the output '0'.
>
>Consequently
>COMMAND: #14&0xFFFFFFFF
>..does also produce '0' - ok.
>
>But why does then
>COMMAND: (#14&0xFFFFFFFF)==0
>..also produce '0' - ???

Bernd:

Once there is an overflow, the ENTIRE numeric expression returns 0.

Ted.

 


Topic: Re: problem with evluation of expressions (6 of 8), Read 20 times
Conf: VEDIT Macro Language Support
From: Bernd Richert
Date: Monday, January 10, 2005 02:40 AM

On 1/9/2005 1:12:36 PM, Ted Green wrote:
>
>Bernd:
>
>Once there is an overflow, the
>ENTIRE numeric expression
>returns 0.
>
>Ted.
>

Ted,

this does make sense. Thanks for this information.

Bernd

 


Topic: Re: problem with evluation of expressions (7 of 8), Read 17 times
Conf: VEDIT Macro Language Support
From: Pauli Lindgren
Date: Friday, January 14, 2005 12:35 PM

On 1/8/2005 5:18:16 PM, Christian Ziemski wrote:
>
>
>That is simply a numeric overflow within the calculation.
>
>Try it with 0x7FFF:FFFF instead.
>
>0xFFFF:FFFF is too big for the 32-Bit
>Vedit. It's MAXNUM is 0x7FFF:FFFF.

I think that can be considered as a bug (probably in the hex input routine).
0xffff:ffff does fit in 32 bit variable.
When interpreted as signed value, it would be -1.

Currently in Vedit, you must type negative numbers in order to enter values larger than 0x7fff:ffff.
For example, the following does work:
123456 & -1

But I think it would be useful if we could use unsigned numbers in online calculator, in addition to signed numbers.
I often use online calculator to calculate addresses etc.

--
Pauli

 


Topic: Re: problem with evluation of expressions (8 of 8), Read 18 times
Conf: VEDIT Macro Language Support
From: Ted Green
Date: Friday, January 14, 2005 12:54 PM

At 12:36 PM 1/14/2005, you wrote:
>I think that can be considered as a bug (probably in the hex input routine).
>0xffff:ffff does fit in 32 bit variable.
>When interpreted as signed value, it would be -1.

We have tried hard, but cannot make 0xffff:ffff work; VEDIT currently
does not support unsigned numbers.

Ted.