Why *HEX 64 and not &&, ~~ ?

[Richard Russell]

A very good question was asked recently: why did I choose to add the *HEX 64 command rather than signify 64-bit hex conversion by means of doubling-up the operator, i.e. && for converting from 64-bit hex and ~~ for converting to 64-bit hex. The (entirely reasonable) argument being that this would have been more consistent with using %% to signify a 64-bit integer variable.

And indeed it would, bar one complication: there is a third situation in which you need to specify 32-bits or 64-bits operation: the >>> and << shift operators. Take for example this code:

Code: Select all

      A% = -1
      PRINT A% >>> 1

Because >>> is an unsigned shift, the answer you would expect, in normal (32-bit) BBC BASIC, is 2.14748365E9. But when working internally in 64-bit integers the correct answer is 9.22337204E18, hence an incompatibility arises. It's necessary to be able to tell BBC BASIC whether to interpret >>> as a 32-bit unsigned right shift or a 64-bit unsigned right shift.

A similar situation arises with the left-shift operator.

Code: Select all

      A% = -2^31
      PRINT A% << 1

In regular BBC BASIC this would produce zero, because the MSB of A% is shifted out and lost. But when working internally in 64-bits the answer is -4.2949673E9!

In principle these shift cases could also have been tackled by introducing new operators (maybe >>>> for a 64-bit unsigned right-shift and <<<< for a 64-bit left-shift) but this struck me as a somewhat contrived and non-intuitive solution.

So, rightly or wrongly, I decided to lump all three cases together (conversion from hex, conversion to hex, and the shift operators) under the control of a single 32/64-bits setting rather than introducing new operators. If you disagree, sorry.