Byte variables start over

Discussions about the BBC BASIC language, with particular reference to BB4W and BBCSDL
PhilD
Posts: 6
Joined: Mon 18 May 2020, 09:44

Byte variables start over

Post by PhilD »

I'm not sure if this is the right place to ask about this. If not please move it to the appropriate spot.

I've noticed that byte variables "start over" if they're assigned values above 255, so for example if a& = 258, a& will return a value of 2. I couldn't find any reference to this in any of the documentation, and I wondered if it's a bug, a special feature or just a standard feature of byte variables. I noticed also that the same thing applies to rgb values set using COLOUR x, r, g, b. It seems unlikely to me that this is coincidence, and it makes sense for BB4W's internal workings to assign byte variables to rgb values, which also never exceed 255. This isn't a complaint at all - I like it that colours start over like that - but I'm not sure that it's supposed to do that.

RichardRussell
Posts: 399
Joined: Tue 15 Oct 2019, 09:10

Re: Byte variables start over

Post by RichardRussell »

PhilD wrote:
Sun 19 Jul 2020, 00:32
I've noticed that byte variables "start over" if they're assigned values above 255, so for example if a& = 258, a& will return a value of 2. I couldn't find any reference to this in any of the documentation, and I wondered if it's a bug, a special feature or just a standard feature of byte variables.
The technical term is "evaluated modulo-256" (or, put another way, ANDed with &FF); it's a standard feature of byte variables. It's not always appreciated that BBC BASIC has had 'byte variables', of a sort, from the very beginning (6502 BBC BASIC from 1981) in the form of the ? indirection operator, for example:

Code: Select all

      DIM P% 0
      ?P% = 123
      PRINT ?P%
      ?P% = 246
      PRINT ?P%
      ?P% = 369
      PRINT ?P% : REM Prints 113
The 'true' byte variables (with a & suffix) in BBC BASIC for Windows and BBC BASIC for SDL 2.0 (and also recently added to Matrix Brandy) are handled identically, and share the same code internally. So just as byte indirection is evaluated modulo-256, so are byte variables; generally this is useful, since it makes it unnecessary to specify AND &FF every time. It also makes the code slightly faster.

Byte variables also differ from the other integer variable types in being unsigned, whilst the others (32-bit and 64-bit) are signed.
If you have a comment about the style or tone of this message please report it to the moderators by clicking the exclamation mark icon, rather than complaining on the public forum.

PhilD
Posts: 6
Joined: Mon 18 May 2020, 09:44

Re: Byte variables start over

Post by PhilD »

Thank you - that's as clear an explanation as I need. Having byte variables return to zero is certainly preferable to the alternatives of having them plateau at 255 or return a "number too big" error!

RichardRussell
Posts: 399
Joined: Tue 15 Oct 2019, 09:10

Re: Byte variables start over

Post by RichardRussell »

PhilD wrote:
Sun 19 Jul 2020, 20:49
or return a "number too big" error!
Acorn's BBC BASICs sometimes behave the same way with 32-bit integer variables, i.e. they 'wrap around' rather than reporting a Number too big error. But they're not consistent, for example this behaviour cannot be justified (in my opinion):

Code: Select all

      A% = &80000001
      B% = A% + A% : REM No error, sets B% to 2
      B% = A% * 2 : REM Reports "Number too big"
There's no way that adding a number to itself should give a different result from doubling it, so in my BASICs a Number too big error results in both cases.
If you have a comment about the style or tone of this message please report it to the moderators by clicking the exclamation mark icon, rather than complaining on the public forum.