Byte variables start over

[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]

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.

[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]

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.