Topics

locked 64-bit indirection ?

Richard Russell
 

In the context of a 64-bit version of BBC BASIC it would be useful to have a 64-bit integer indirection operator, in addition to the regular 32-bit ('!') and 8-bit ('?') operators. However there are no obvious single-character or multi-character candidates which aren't either already in use or at least ambiguous.  The choice is in any case greatly restricted because indirection operators are l-values (i.e. can be used on the left of an assignment).

Can anybody think of a suitable operator to use for 64-bit indirection which won't clash with existing usage and which isn't too contrived?

Richard.

Norman Vingoe
 

I expect you've already considered !!
Since you've used repeat character for 64-bit integers %% there would at least be some consistency.


On Fri, 29 Dec 2017 at 1:19, Richard Russell
<news@...> wrote:
In the context of a 64-bit version of BBC BASIC it would be useful to have a 64-bit integer indirection operator, in addition to the regular 32-bit ('!') and 8-bit ('?') operators. However there are no obvious single-character or multi-character candidates which aren't either already in use or at least ambiguous.  The choice is in any case greatly restricted because indirection operators are l-values (i.e. can be used on the left of an assignment).

Can anybody think of a suitable operator to use for 64-bit indirection which won't clash with existing usage and which isn't too contrived?

Richard.

Richard Russell
 

On Thu, Dec 28, 2017 at 10:54 pm, Norman Vingoe wrote:
I expect you've already considered !!
Indeed, but it's already legal (and useful) syntax and I've used it many times in existing programs.  Here's is a contrived example:

      P% = ^abc%
      !P% = ^def%
      !!P% = 123456
      PRINT !!P%

You can extend this pattern indefinitely:

      P% = ^abc%
      !P% = ^def%
      !!P% = ^ghi%
      !!!P% = 654321
      PRINT !!!P%

So we need something that ideally is invalid syntax currently or, at the very least, is extremely unlikely to have been used in any existing programs.

Richard.
 

Howard
 

What about ¬ 

It certainly does seem to be in use!   Typing ¬¬p% currently generates "RIGHT$(NOTRIGHT$(NOTp%"  ... which came as a bit of a surprise!

Howard

Richard Russell
 

On Fri, Dec 29, 2017 at 02:19 am, <john_fowler_son@...> wrote:
What about ¬ 
That's not a (7-bit ASCII) character at all!  On my keyboard it generates ANSI code 172 (the BBC BASIC token for NOT) but that will probably depend on language and encoding settings.  If it's necessary to say so explicitly, by "character" I naturally mean something that can be used in a BBC BASIC program, i.e. in the ASCII code range 33 to 126.

Richard.

Robin Hodson
 

How about the Pound symbol?

DIM a% 50
!a%=123

PRINT £A
Produces 0 123
This behaviour could be preserved when used for other purposes.

B=£A
Gives "Mistake", and it isn't a valid part of a variable name.


Or a backslash?

And yet P.\A
Rather mysteriously gives "Missing \" in BB4W ("Unknown or missing
variable" in RISC OS BASIC)

As 64-bit integer numeric variables use %%
and 64-bit floating-point variables use #
and doubled symbols are used elsewhere:
##
@#
@%
@@

PRINT #A
is a channel, but

PRINT ##A
is a syntax error, so presumably that's available.

Ric
 

Does it have to be a single character or double character? A bit outside the box, but something like D! Maybe. No it's not a emoji.

Ric

Sent from my HTC

----- Reply message -----
From: "Richard Russell" <news@...>
To: <bb4w@groups.io>
Subject: [bb4w] 64-bit indirection ?
Date: Fri, Dec 29, 2017 10:42

On Fri, Dec 29, 2017 at 02:19 am, <john_fowler_son@...> wrote:
What about ¬ 
That's not a (7-bit ASCII) character at all!  On my keyboard it generates ANSI code 172 (the BBC BASIC token for NOT) but that will probably depend on language and encoding settings.  If it's necessary to say so explicitly, by "character" I naturally mean something that can be used in a BBC BASIC program, i.e. in the ASCII code range 33 to 126.

Richard.

Norman Vingoe
 

I recall the 'control' character (used in eg. *key commands - end with <ctrl>m to insert a <return> into the keyboard buffer) which would fail syntax outside of that particular useage, displayed in mode 7 as a double vertical bar. Is that used elsewhere?


On Fri, 29 Dec 2017 at 10:42, Richard Russell
<news@...> wrote:
On Fri, Dec 29, 2017 at 02:19 am, <john_fowler_son@...> wrote:
What about ¬ 
That's not a (7-bit ASCII) character at all!  On my keyboard it generates ANSI code 172 (the BBC BASIC token for NOT) but that will probably depend on language and encoding settings.  If it's necessary to say so explicitly, by "character" I naturally mean something that can be used in a BBC BASIC program, i.e. in the ASCII code range 33 to 126.

Richard.

Richard Russell
 

On Fri, Dec 29, 2017 at 02:59 am, Robin Hodson wrote:
How about the Pound symbol?
Same problem as ¬, it's not an ASCII character: £ is ANSI code 163, which is the BBC BASIC token for FALSE!   If that weren't enough, non-ASCII characters will generate different codes depending on whether the IDE is set to ANSI or Unicode!  I obviously framed the question badly for people to be suggesting codes that aren't even usable as a character in a BBC BASIC program (except in a quoted string).

Or a backslash?
Already in use: backslash is valid anywhere that a space is (with a few exceptions documented in the BB4W manual).

## @# @% @@
The latter three are all legal 'system' variable names now - and @% is actually in use of course - so they are ruled out.  I concede that ## is currently a syntax error (indeed even a single # is invalid in an l-value context); my main concern would be that # is associated with floating-point values so could easily be misleading.

Richard.

Richard Russell
 

On Fri, Dec 29, 2017 at 03:29 am, Richard Russell wrote:
my main concern would be that # is associated with floating-point values so could easily be misleading.
A time machine would be of value here!  Thinking about it, # would actually have been a good choice for the floating-point indirection operator, which would have freed up | for 64-bit integer indirection.  Pity Sophie didn't think of that in 1986!

Richard.

Richard Russell
 

On Fri, Dec 29, 2017 at 03:02 am, Ric wrote:
Does it have to be a single character or double character? A bit outside the box, but something like D! Maybe.
I have no problems with a double-character (as has been pointed out the 64-bit integer variable suffix is already %%) but of course D! is perfectly valid syntax now and may well occur in existing programs:

      DIM D 3
      D!0 = 555555
      PRINT D!0

Richard.

Richard Russell
 

On Fri, Dec 29, 2017 at 03:04 am, Norman Vingoe wrote:
Is that used elsewhere?
Messages crossed - answered in an earlier reply.

Richard.

Robin Hodson
 

How about a system variable that turns ! into a specified bit-width, eg
32 for the current, and 64 for 64-bit?

This would eliminate the same trouble reoccurring with 128 bits etc, and
a 32-bit operator is less useful on 64-bit systems.

Richard Russell
 

On Fri, Dec 29, 2017 at 05:02 am, Robin Hodson wrote:
How about a system variable that turns ! into a specified bit-width, eg
32 for the current, and 64 for 64-bit? This would eliminate the same
trouble reoccurring with 128 bits etc, and
a 32-bit operator is less useful on 64-bit systems.
I think the fallacy with that argument is that 32-bit indirection is not "less useful [than 64-bit indirection] on 64-bit systems".  If you think back to the original thread in which the possibility of a '64-bit' BBC BASIC was discussed, one of the options considered there was to redefine a regular integer variable e.g. 'a%' to be 64-bits rather than 32-bits.  I pointed out that this is not what the great majority of other programming languages had done, for example in 'C' (and C++) an 'int' type remains 32-bits even when compiled for a 64-bit platform.

This surprises some people, not least because the original specification of the C language calls for 'int' to be 'the integer type that the target processor is most efficient at working with'.  That would lead you to expect that 'int' would be 64-bits on a 64-bit CPU, but it virtually never is.  This is largely for pragmatic reasons: it would make it far more difficult to port software from a 32-bit platform to a 64-bit platform if 'int' - the most common integer data type - changed its size.

The argument is at least as strong in the case of BBC BASIC; compatibility with existing programs would be severely compromised if an integer variable like 'a%' was anything other than 32 bits.  In any case you cannot divorce BBC BASIC from C: the SYS statement interfaces with the API functions provided by the host operating system, and those API functions are almost certainly defined in terms of a C-like interface.


So I am confident that 64-bit indirection would be needed only very infrequently, and therefore redefining the ! operator (under control of some command analogous with the *float command) wouldn't be a desirable approach.

Richard.

Howard
 

What about ]]   Since ] is only valid at the end of assembler, if the interpreter encountered ] without having previously encountered [ , it could generate an error, if ] was not followed by ].
.

Howard

Richard Russell
 

On Fri, Dec 29, 2017 at 06:08 am, <john_fowler_son@...> wrote:
What about ]]   Since ] is only valid at the end of assembler,
I can't fault the argument, although I don't see the necessity to repeat it as ']]' - is there some reason why you thought a single ']' would be unsuitable?  It's not strictly true to say that it is only valid "at the end of" assembler because [ and ] are also used to indicate an indirect operand in x86 assembly language, but that's still within assembler code, just not at the end.  Even if one were to want to use 64-bit indirection in assembler source code there's probably no ambiguity in syntax. 

Richard.

Richard Russell
 

On Fri, Dec 29, 2017 at 06:08 am, <john_fowler_son@...> wrote:
What about ]
I can see one objection, although it's not necessarily a killer.  At the moment [ and ] are always used in matching pairs (either to delimit assembler code, or to mark an indirect operand) so a tool, such as the Cross Reference Utility, that wants to ignore assembler code can simply add one to a count whenever it sees a '[' and subtract one when it sees a ']', and assume that a non-zero value indicates 'inside assembler code'.  That approach wouldn't be reliable if ']' were to be encountered on its own.  Nevertheless it's the best suggestion received so far.

Richard.

Howard
 

I only suggested ]] as I thought it might be useful as a means of enabling the interpreter to trap errors since if it encountered an "]" unmatched by either a "[" or "]" it would indicate an error.   But, of course, for the same reason that we currently use !! we would, in 64b require "]]" and that would certainly be preferable to "]]]]" (etc).
Howard

Richard Russell
 

On Fri, Dec 29, 2017 at 08:20 am, <john_fowler_son@...> wrote:
I only suggested ]] as I thought it might be useful as a means of enabling the interpreter to trap errors since if it encountered an "]" unmatched by either a "[" or "]" it would indicate an error.
You seem to be proposing that the syntax be made more complex - with an inevitable hit on execution speed - for the sole purpose of making the error message more specific.  In other words, with your suggestion the presence of an isolated "]" would result in an error such as 'Unexpected ]' whereas with the simpler (and faster) approach of using a single "]" to indicate 64-bit indirection the resulting error message would be 'Syntax error' or something similarly generic.

Whilst it's true that a more specific error message might lead the programmer to the cause of the problem more quickly, the performance hit is a high price to pay and generally BBC BASIC doesn't work that way.  As a rule, an error is detected and reported at run-time only when the alternative is a crash, or the interpreter is simply unable to proceed with the information available to it.  Neither of those is true in this case.

We mustn't lose sight of the fact that BBC BASIC is interpreted, so any code executed at run time that does not directly contribute to the correct working of the user's program must be carefully justified: on balance the benefit would have to outweigh the performance hit.  I would argue that in this case it doesn't.

But, of course, for the same reason that we currently use !! we would, in 64b require "]]"
You say "of course" but does it actually follow?  !!P% makes sense because !P% returns a 32-bit integer which is itself an appropriate address parameter for the 32-bit indirection operator.  For the same reason ]!P% would make sense, because again the expected parameter of 64-bit indirection is a 32-bit address.  But what would ]]P% mean?  You are passing a 64-bit integer as the address, but since BBC BASIC is still a 32-bit language it is not expecting to be dealing with 64-bit addresses and wouldn't know what to do with it!

Richard.

Richard Russell
 

Right, I have 'experimentally' implemented 64-bit indirection, using the "]" character, in the 'experimental' 64-bit version of BBC BASIC.  It can be downloaded from the same place as before.

Please try it out.  Test the 64-bit indirection specifically, but also anything else that takes your fancy.  I have mentioned some of the 'expected' incompatibilities previously, but if you need reminding the list is at the forum. It's out of date in one respect: I've put a compatible ogllib.bbc in the zip file so you can run some of the 3D programs successfully.

Richard.