Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #5940

Re: BASIC oddity?

Show all headers | View raw

In message <893aa72e58.DaveMeUK@BeagleBoard-xM>
 on 7 Jan 2020 David Higton  wrote:

> In message <582e9297f8News03@avisoft.f9.co.uk>
>           Martin <News03@avisoft.f9.co.uk> wrote:
> 
> > On 07 Jan in article <4ad6842e58.Matthew@sinenomine.freeserve.co.uk>,
> >   Matthew Phillips <spam2011m@yahoo.co.uk> wrote:
> > > It would be an utter pain for anyone writing stuff in BASIC to have to
> > > check each calculation to decide whether an overflow had occurred or
> > > not.  If BASIC generated a "Number too big" error for addition and
> > > subtraction of integers, if you want to ignore them, all you need to do
> > > is to write a suitable error handler.
> > 
> > Sorry, but I have to disagree!
> > 
> > Because a BASIC integer can be either signed or unsigned (and BASIC does
> > not know which) I do not think it is possible for BASIC to generate any
> > under/overflow errors for addition or subtraction.
> > 
> > Consider the following four examples - two for addition and two for
> > subtraction. Each example has the same numbers on the left shown as signed,
> > and on the right as unsigned hex.
> > 
> > You will see that each example has an obvious error case - BUT only when
> > used as either Signed or Unsigned, never both.
> >
> >Signed Addition                    Unsigned addition
> >---------------                    -----------------
> >2147483632 + 200 = -2147483464     &7FFFFFF0 + &C8 = &800000B8
> >Overflow set   = Overflow          Carry clear = OK
> >
> >-16 + 200 = 184                    &FFFFFFF0 + &C8 = &B8
> >Overflow clear = OK                Carry set   = Overflow
> >
> >
> >Signed Subtraction                 Unsigned Subtraction
> >------------------                 --------------------
> >100 - 200 = -100                   &64 - &C8 = &FFFFFF9C
> >Overflow clear = OK                Carry clear = Underflow
> >
> >-2147483516 - 2147483392 = 388     &80000084 - &7FFFFF00 = &184
> >Overflow set   = Underflow         Carry set   = OK
> >
> > The last example above is the same case as the third 'weird' example from
> > Alan's original post. It may look like an error if signed, but perfectly
> > logical if unsigned.
> > 
> > So, I think that it has to be the application which does any necessary
> > checks, as long as BASIC cannot tell whether an integer is signed or
> > unsigned.

My position is that BASIC sitting on the fence like this is ultimately not
much help to programmers who have a definite idea whether the values they are
dealing with are signed or unsigned, because in each case there are
circumstances in which you will not be told about overflows or carries.  If
you're happy to be vague about whether the value is signed or unsigned, BASIC
might suit you.

Remember that although you have written "Carry set" and "Overflow set", BASIC
doesn't provide the programmer with access to this information (unless I'm
missing something).

> I'm in agreement with you, Martin.  BASIC cannot know whether integer
> variables are being used as signed or unsigned.  It would be a real pain if
> it decided that an error had occurred when really it hadn't; the results of
> the calculation could never be seen.  It would mean descending into
> assembly language - which we /really/ don't want to do.
> 
> I would point out that it is also legitimate to add a signed int to
> an unsigned one, e.g. to add an offset in either direction to a pointer.
> You can see that adding a negative offset to a top-bit-set address
> would appear to overflow, when in reality no error occurs.

I agree that BASIC's behaviour is really useful when dealing with passing
flags to SWIs and handling memory addresses.  But there are also many
situations in which not having an error generated is a nuisance.  If you have
the address &ffff fffc and want to add -12 to get &ffff fff0 that's fine, but
what if you add 12?  You'd want to know that you've wrapped round to zero
page.

I hope you can both agree that BASIC is inconsistent between add/sub and
multiplication.  With addition and subtraction BASIC gives no errors if the
individual operands can all be expressed within 32 bits, whether the values
are signed or unsigned.  But with multiplication, the values are firmly
treated as signed:

>a%=&7fffffff
>b%=a%*2

Number too big
>a%=&3fffffff
>b%=a%*2
>P. b%
2.14748365E9

Negative numbers:

>a%=&C0000000
>P. a%
-1.07374182E9
>b%=a%*2
>P. b%
-2.14748365E9
>P. ~b%
  80000000
>c%=b%*2

Number too big

I know Dave argued that multiplication is different for signed and unsigned
integers in assembly language, but that's only the case if you're storing a
64 bit result from two 32 bit numbers.

There is further weirdness. Consider this, where the values are assigned to
floating point variables:

>a=&7fffffff
a=a+a
P.a
4.29496729E9
>a=&7fffffff+&7fffffff
>P.a
        -2

Or in decimal notation:

>a=2100000000+2100000000
>P. a
 -94967296
>
>a=2100000000
>a=a+a
>P.a
     4.2E9

>a=2200000000+2200000000
>P.a
     4.4E9

In short, while I can understand what BASIC is doing, and can see that it is
useful in some special circumstances (dealing with flags and addresses) its
behaviour is unexpected if you are not au fait with assembly language and it
is full of traps for the unwary.

If BASIC gave you access to the overflow and carry indicators or allowed you
to declare variables as signed or unsigned it would be better.  However, we
have to live with it as it is: I'm certainly not advocating changing it.

It's possible to avoid the 2100000000+2100000000 trap in a similar way to C
by writing 2100000000.0+2100000000.0

I only really got into Acorn machines with the Archimedes.  Were integers on
the BBC B also 32 bit?

-- 
Matthew Phillips
Durham

Back to comp.sys.acorn.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

BASIC oddity? Alan Adams <alan@adamshome.org.uk> - 2020-01-03 17:16 +0000
  Re: BASIC oddity? Martin <News03@avisoft.f9.co.uk> - 2020-01-03 19:31 +0000
    Re: BASIC oddity? druck <news@druck.org.uk> - 2020-01-03 21:00 +0000
      Re: BASIC oddity? Alan Adams <alan@adamshome.org.uk> - 2020-01-03 22:26 +0000
        Re: BASIC oddity? Steve Drain <steve@kappa.me.uk> - 2020-01-04 10:40 +0000
          Re: BASIC oddity? Martin <News03@avisoft.f9.co.uk> - 2020-01-04 16:08 +0000
            Re: BASIC oddity? Alan Adams <alan@adamshome.org.uk> - 2020-01-04 16:22 +0000
              Re: BASIC oddity? David Higton <dave@davehigton.me.uk> - 2020-01-04 17:24 +0000
                Re: BASIC oddity? Alan Adams <alan@adamshome.org.uk> - 2020-01-04 18:47 +0000
                Re: BASIC oddity? Matthew Phillips <spam2011m@yahoo.co.uk> - 2020-01-06 08:58 +0000
                Re: BASIC oddity? David Higton <dave@davehigton.me.uk> - 2020-01-06 16:20 +0000
                Re: BASIC oddity? Matthew Phillips <spam2011m@yahoo.co.uk> - 2020-01-07 08:49 +0000
                Re: BASIC oddity? Martin <News03@avisoft.f9.co.uk> - 2020-01-07 11:20 +0000
                Re: BASIC oddity? David Higton <dave@davehigton.me.uk> - 2020-01-07 15:05 +0000
                Re: BASIC oddity? Matthew Phillips <spam2011m@yahoo.co.uk> - 2020-01-08 08:23 +0000
                Re: BASIC oddity? Alan Adams <alan@adamshome.org.uk> - 2020-01-08 10:26 +0000
                Re: BASIC oddity? druck <news@druck.org.uk> - 2020-01-08 21:02 +0000
                Re: BASIC oddity? Richard Ashbery <basura@invalid.addr.uk> - 2020-01-09 12:53 +0000
                Re: BASIC oddity? Steve Fryatt <news@stevefryatt.org.uk> - 2020-01-09 23:16 +0000
                Re: BASIC oddity? Steve Fryatt <news@stevefryatt.org.uk> - 2020-01-08 22:35 +0000
                Re: BASIC oddity? Martin <News03@avisoft.f9.co.uk> - 2020-01-08 23:51 +0000
          Re: BASIC oddity? Steve Drain <steve@kappa.me.uk> - 2020-01-10 11:30 +0000
            Re: BASIC oddity? Alan Adams <alan@adamshome.org.uk> - 2020-01-10 12:38 +0000
      Re: BASIC oddity? Jean-Michel <jmc.bruck@orange.fr> - 2020-01-06 20:39 +0100
        Re: BASIC oddity? Alan Adams <alan@adamshome.org.uk> - 2020-01-06 21:13 +0000
          Re: BASIC oddity? Steve Drain <steve@kappa.me.uk> - 2020-01-08 12:46 +0000

csiph-web