BBC BASIC - 64 bit integer support, long string support

I’ll let you all know when there is.

BTW I’ve just added this, which is handy:

Should Colin set his Alarm, or his calendar?

<language geek grabs you by the lapels> I need you to understand how cool this is

Well, I’ve really no idea what is going on here.

Hmmm, that gravestone looks like it’s been standing in Binley Woods for about 6 months.

It’s BASIC, Paul, but not as we know it.

That photo? Looks like a pleasant place for a picnic.

@Paul

The explanation was in the HELP in the above screenshot. Namely, bitwise access to integers:

=<num>[n] (literal square brackets): the boolean value of bit n.
=<num>[l:h]: the unsigned integer value of a bitfield.
=<num>[l TO h]: the signed integer value of a bitfield. If n,l,h<0, 32 is added.

So a%[0] is the boolean value of bit 0 of a% (ie 0 if clear, -1 if set); a%[4:6] is the integer value (0-7) of bits 4-6 of a%; a%[16TO23] is the signed value of bits 16-23, the third byte of the word; and a%[24:31,16:23,8:15,0:7] is an endianness-swapped version of a% – converting between little-endian and big-endian in one small expression.

The boolean single bit ops allow code like IF a%[4] AND NOT a%[7] whereas the bitfield list form allows arbitrary bit rearrangement.

As an interpreted language geek I find that very pleasing. Coupled with the array arrow operator, that means you can endian-convert an entire array with:

a%()=>a%()[24:31,16:23,8:15,0:7]

As an interpreted language geek I find that very pleasing.

Snap. Especially that endian conversion example. Although I’m not sure I’d ever find a use for it in anything I’m ever likely to do! 8~)

The bitfield extraction looks very handy actually!

Am wondering – how do you post the screenshots? Do you have to host them externally, or can you ‘post them’ directly to the forum?

The bitfield extraction looks very handy actually!

Saves a lot of faffing around with AND and shifts.

Am wondering – how do you post the screenshots?

Look at the source info in the browser of your choice.

The one above is https://pbs.twimg.com/media/GTbnoG0WkAIGVFV?format=png&name=large so it’s just linking to an image posted on the antisocial dead blue bird network.

The forum can include images, but they must be hosted externally. And with modern browsers being what they are, you should use a host that supports https.

Can these bit operations also set the values too? That would be very useful like the BFI instruction in assembler. Example: A%[16:23] = B%

Saves a lot of faffing around with AND and shifts.

Indeed, except that

I’m not sure I’d ever find a use for it in anything I’m ever likely to do!

@tymaja

For images that aren’t already somewhere else, I can recommend Imgur. It’s free, you can upload images without publishing and instantly get a URL for the picture. The image Rick referred to happens to have been published on Twitter already, but whether it continues to be accessible externally from that infernal site is entirely at the whim of an extremely unstable and unpleasant man. So Imgur’s probably your best bet.

@Graeme

Absolutely, bitlists can be applied to the value or to assignment. Which means there’s actually two ways to do endianness conversions: (and if you did both they’d cancel eachother out)

When there’s a list of bitfields, each consecutive range is higher significance – so A=B[0,2,4] builds a new word from b0, b2 and b4 of B, forming b0, b1 and b2 of A. However, as single bits are boolean, the last one in that list is sign-extended across the rest of the bits in the word. In contrast to single bits, bitfields are only sign-extended if TO is used – when : is used they’re unsigned.

When a bitlist is used in an assignment, ie A[10,4:7,20]=B then each bit or bitfield is taken from B in fields of increasingly significance – so in that example Ab10 is taken from Bb0, Ab4:7 from Bb1:4, and Ab20 from Bb5.

Treating single bits (ie [4] versus [4:4]) as boolean (returning either 0 or -1) is necessary for logic to work, such as IF a[0] AND NOT a[1] – as it’s easy to forget that NOT is not a logical operator (“truthy”) it’s a binary operator (each bit separately), whereas IF is always “truthy”. Hence when a=1, both IFa and IFNOTa are “true”! Counter-intuitively.

BTW This kind of thing is usually referred to as a “gather/scatter” operator, which takes me back to primary school harvest festival time.

However, as single bits are boolean, the last one in that list is sign-extended across the rest of the bits in the word.

I can see that one biting people.

In lieu of not having image posting:

ARM BBC BASIC © Acorn 1989

Starting with 4438526573 bytes free

>PRINT 9999999999999999999
9.99999999E17
>_

Very experimental! :O (I typed this out looking at the screen on my RPi, so the number of 9’s in the PRINT statement is almost certainly incorrect, however it does actually work, and is a promising start (still chasing some Carry bits around the code!)

Starting with 4438526573 bytes free

That’s insane…
(I remember when 18,432 was a lot)

9.99999999E17

What’s the magic incantation to give to @% to get rid of this exponent nonsense? I’d prefer to see my numbers as fully written numbers.

I can see that one biting people.

Hmmm. Perhaps a list disables sign-extension unless TO is explicitly used, ie a[0,2,4TO4] to get a number between -4 and 3. You may be right.

exponent nonsense

If the column width is narrower than the number of digits, you’ll get an exponent. So @%=“G20.19” would be a start. But the NumToString routine will need massaging in line with the increased number of sigfigs.

9999999999999999999

You can fit 19 significant digits into an Extended, yes (20 if it starts with “4” or less!). So that’s 12 bytes per real in order to round-trip 8-byte integers.

Basic fits 9 "9"s into its 40b reals; Basic64 can do 15 with its 64b doubles; so this’ll be Basic96 yes? :-)

Returning to round-tripping: Note that Basic64 would be able to round trip 53b integers – that’s a max value of &1FFFFFFFFFFFFF, which is 8PB, 8000TB, 8 million GB.

Might that be enough for now?

i.e. maybe you don’t need 64b integers, but just an easier way to get large integers into and out of reals.

nemoBasic extends BPUT and BGET to be syntactic sugar for GBPB – so in addition to PTR and EXT which could already return big integers to reals (in Basic64), you’d only need to add the polymorphic BGET/BPUT so that a PTR can be specified (as a real). ie:

large=EXT#F%
PTR#F%=large

See what I mean? If you limit yourself to GBPB 2 and 4 you wouldn’t even need to update BGET/BPUT. But for reference:

BGET#<channel> TO <mem> LEN <size> [PTR <ptr>] [TO <lenvar>]: or
BGET#<channel> TO <mem> TO <end> [PTR <ptr>] [TO <lenvar>]: or
=BGET#chan TO mem LEN|TO num [PTR ptr]: read bytes from file [from a given PTR] [returning how many].

BPUT#<channel> OF <mem> LEN <size> [PTR <ptr>] or
BPUT#<channel> OF <mem> TO <end> [PTR <ptr>]: write a block of memory to file, by size or end [at a specified PTR].

BTW the reason for the OF|TO etc in those is because BGET(...) does something else, and BPUT#F%,a,b,c outputs multiple bytes already.

re : round trip integers….…… BASIC72? :D

I’ve been looking at floating point formats; it is a huge amount of work, but the ‘easiest’ way to go about 64-bit integer support is to add floating point with a 64-bit mantissa :S; in a way, 72-bit floating point is required to enable 64-bit integer support; BASIC uses a word for mantissa, and a byte for exponent, so that lends itself to a 64-bit mantissa and 8-bit exponent (although I am leaving 2 bytes for the exponent, for ‘future expansion’!

Some of the work is easy; upgrading the ‘reading-in code’ was easy – so it can now read 64-bit integers in, and store them, and can also read in 72-bit floating point perfectly.

This is why I am chasing Carry bits around! From the (experimental, unreleased ‘RiscPC-with-ARMv8 CPU’ emulator I worked on for a while (it did boot to desktop!)), BASIC REALLY uses most of the CPU, including preserving ‘carry’ for ages at times, and lots of RRX, and shifter carryout from logical data instructions – which gets messy when extending to a 64-bit mantissa! I need to go over the ‘FACCtoBCD’ code next (it is now 64-bit, but introduces an error at about 24 bits in it’s current 64-bit form, so

abc = 123456
PRINT abc
123455.9967334

Which is exactly what happens when writing an ARM emulator and neglecting the finer points of shifter-carryout! Fortunately the encoding side works fine – it is just the ‘convert float72 to a string in STRACC’ code that needs more work!

(then comes the ‘FPA BCD → STRACC code, currently 32-bit still (I convert FP72 – FP40 by just removing the lower 32 bits of mantissa there … for now!) – that isn’t the cause of the FP → text output accuracy issue (yet), so will be the next thing to do

I have an idea for how to do BASIC108, which would have almost the same performance as BASIC64VFP, but I need to understand several esoteric research papers better. It is possible to extend FP accuracy in a similar way to ADD / ADC does for integers, using the FP hardware, but it is not easy! (and so will be kept for a rainy day at this point)

(edit : autocorrect typos aplenty, have fixed some)

The biggest problem isn’t the maths, it’s that there are various bottlenecks in the interpreter where it runs out of registers, including at least one where it reuses R8! (this is meaningless to anyone unfamiliar with the code)

And there are many places where it keeps a numeric and a string in the ACC at the same time, and several places where it keeps multiple integer parameters in registers – and if all of those become 64b you have so much work, so much opportunity for error, and there will be a performance impact.

And there are a few places where you can’t use the stack because it’s in the process of being transformed. See PROC/FN calls for an example.

BTW I’ve used &8C as the field tag for PRINT# and INPUT# Extended precision – we already have &80=40b and &88=64b. Plus field tag 1 is used for long strings (stored in memory order, not reverse order like tag 0).

There is an argument for having a larger exponent (than 8b) when the mantissa is 63.1b. And there’s a pleasing symmetry in using 10 bytes instead of 5 bytes – that’ll help the array code for example.

nemoBasic supports IEEE Half, Single, Double, Extended, Packed and Expanded, and bfloat16 too, via BGET and BPUT (file or memory).

That might be easier, but horribly inefficient as there is no 72 bit float support in any of the native FP instruction sets.

If you are going to 64 bit integers, you need to bite the bullet and separate the integer and floating point code. Relying on the FP 5 byte format being able to represent integers with full fidelity was one of the great tricks that BBC Basic was able to exploit for speed on early ARMs and going back as far as the 8 bit Beeb, but not something which can go any further. A BBC BASIC with 64 bit integers really needs standard 64 bit float too using VFP, and that means no int/fp interchangeability.

@druck I think you should know

nemo, right side clipped…

…or does your BASIC’s assembler treat # and #- as testing with TRUE or something?

Sorry, clipped yeah. Just showing the results on the left and the immortalised build switch on the right! Implementation details not important (beyond 4 instructions versus 2).

no int/fp interchangeability.

You’re entitled to do that in DruckBasic. You cannot do that in BBC Basic.

In any case, A%%/=2.0 should not behave differently from A%%/=2. Round-trip is desirable as well as required.