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


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

Re: BASIC oddity?

From David Higton <dave@davehigton.me.uk>
Newsgroups comp.sys.acorn.programmer
Subject Re: BASIC oddity?
Date 2020-01-07 15:05 +0000
Organization Home
Message-ID <893aa72e58.DaveMeUK@BeagleBoard-xM> (permalink)
References (7 earlier) <d46b282d58.DaveMeUK@BeagleBoard-xM> <930f302d58.Alan.Adams@ArmX6.adamshome.org.uk> <60432a2e58.DaveMeUK@BeagleBoard-xM> <4ad6842e58.Matthew@sinenomine.freeserve.co.uk> <582e9297f8News03@avisoft.f9.co.uk>

Show all headers | View raw


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.
> 
> ... unless anyone can see the flaws in my argument!

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.

David

Back to comp.sys.acorn.programmer | Previous | NextPrevious 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