Matrix Brandy BASIC VI for console and SDL1.2: V1.22.7 released

for discussion of bbc basic for windows/sdl, brandy and more
User avatar
Richard Russell
Posts: 1595
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Richard Russell » Mon Jul 06, 2020 6:00 pm

Soruk wrote:
Mon Jul 06, 2020 5:41 pm
I'm not so sure it would be less accurate. Indeed, I've seen odd stuff with system clocks on the production environment where I work if there's been a network hiccup and the NTP server has disappeared
CLOCK_MONOTONIC_RAW certainly can't be more accurate, since it is typically just a free-running crystal oscillator. Something is seriously wrong if CLOCK_MONOTONIC has noticeable hiccups, the only influence of NTP corrections on that clock is supposed to be small frequency adjustments which correct its average timekeeping over the long term. Are you sure you weren't looking at CLOCK_REALTIME when you saw the hiccups?

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Soruk » Mon Jul 06, 2020 6:40 pm

Richard Russell wrote:
Mon Jul 06, 2020 6:00 pm
Soruk wrote:
Mon Jul 06, 2020 5:41 pm
I'm not so sure it would be less accurate. Indeed, I've seen odd stuff with system clocks on the production environment where I work if there's been a network hiccup and the NTP server has disappeared
CLOCK_MONOTONIC_RAW certainly can't be more accurate, since it is typically just a free-running crystal oscillator. Something is seriously wrong if CLOCK_MONOTONIC has noticeable hiccups, the only influence of NTP corrections on that clock is supposed to be small frequency adjustments which correct its average timekeeping over the long term. Are you sure you weren't looking at CLOCK_REALTIME when you saw the hiccups?
It is possible, which is why I want to do some tests to examine any performance impact. I do have some little test VMs, so I could knock up a program that uses both clocks, dump the outputs to a file and see what happens when I make it lose NTP or vmotion it between VM hosts.

Then again, doing some googling results in some discussions over which is better, and they do tend towards CLOCK_MONOTONIC, however there was a kernel bug that could cause it to go backwards. (I don't think I have such an affected system?)
Matrix Brandy BASIC VI (work in progress)

User avatar
Richard Russell
Posts: 1595
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Richard Russell » Mon Jul 06, 2020 6:45 pm

Soruk wrote:
Mon Jul 06, 2020 6:40 pm
however there was a kernel bug that could cause it to go backwards.
My view is that you shouldn't be making allowances for bugs of this sort. Clearly a 'monotonic' clock cannot, by definition, go backwards.

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Soruk » Mon Jul 06, 2020 9:41 pm

Stepping aside from these clock shenanigans... over to RISC OS.

I'm using GCC 3.4.6, the last of the builds that creates Acorn native AIF binaries. (GCC 4.x ports create Elf binaries, and is itself an elf binary, and I cannot get them to run on my (emulated) Risc PC at all.) Unfortunately, while the binaries start up on a Raspberry Pi running RISC OS I'm having severe difficulty with the way it's handling keyboard input (a non-empty line just hangs). On my RPCEmu setup it works fine, and to my surprise it even works in ArcEm (an emulated A440 or 540 with 16MB RAM, RISC OS 3.1).

Edit 1: Turns out the RasPi RISC OS image includes a newer GCC 4.7.4 toolchain, and after much tweaking and poking, I got Brandy to build on it, and it worked. Next trick is to see if the resulting binary runs on RPCEmu (Edit 1.5: It does!) ... and I think I've worked out why I wasn't having any luck earlier with this toolchain on RPCEmu running RISC OS 3.71.

Edit 2: No luck. !SharedLibs is installed, SOManager module is loaded. *SOMStatus shows it even tried to run an elf app (gcc at the command line). But it just exits with no error, no messages, no nothing.

Edit 3: I have a second instance of RPCEmu running RISC OS 5.27, while an order of magnitude slower than the RasPi there is the massive advantage that the HostFS layer follows symbolic links so pointing the source files at my git tree on the Linux layer allows me to track my development even without a RISC OS git implementation.

Edit 4: This approach seems to be working. RPCEmu with RISC OS 5.27 running the new toolchain builds a binary that works on RISC OS 3.71 and newer (building as a static binary and running elf2aif on it). And, the older toolchain on RISC OS 3.71 builds a binary that works on Archimedes (with RISC OS 3.1, not tested RISC OS 2) up to and including Risc PC with RISC OS 3.71.

The newer toolchain builds much faster code, running this:

Code: Select all

a%=0:TIME=0:REPEAT a%+=1: UNTIL TIME>100:PRINT a%
shows me that the 32-bit binary is about 3x as fast as the 26-bit one (at least for loops, comparisons and integer increments), running on the same OS on the same box (and, is an astonishing 75% the speed of ARM BBC BASIC on the same box).

I think I will stick with this approach for RISC OS builds - a Zip is here.

Edit 5: Better speed comparison over here comparing 26-bit build, 32-bit and the native ARM BBC BASIC V interpreter. The native values may look a bit low, my RPCEmu box is an old (2013-era) HP thin-client with a 1.65GHz AMD G-T56N CPU, which I've upgraded to include a SATA HDD and 4GB RAM. Being a thin client (especially 7 years ago) it was never intended to do real hevy lifting, but its performance is surprisingly good, rather better than my Intel Atom-based machines.
Last edited by Soruk on Wed Jul 08, 2020 1:16 am, edited 3 times in total.
Matrix Brandy BASIC VI (work in progress)

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Soruk » Tue Jul 07, 2020 4:09 pm

Based on a bit of checking online, and a quick test late last night, I've removed the MONOTONIC_RAW from the code, so it just checks for MONTONIC and uses REALTIME if that's not available.
Matrix Brandy BASIC VI (work in progress)

User avatar
Richard Russell
Posts: 1595
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Richard Russell » Tue Jul 07, 2020 5:00 pm

Soruk wrote:
Tue Jul 07, 2020 4:09 pm
Based on a bit of checking online, and a quick test late last night, I've removed the MONOTONIC_RAW from the code, so it just checks for MONTONIC and uses REALTIME if that's not available.
=D> =D>

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Soruk » Thu Jul 09, 2020 10:59 am

Having been playing with *EXEC on another thread, I've identified a bug in Matrix Brandy's implementation where it was halting on any error condition (it should only halt on Escape) - and that *EXEC was itself not interruptible with Escape.... oops. This became evident as it's quite legal to have a

Code: Select all

#!/path/to/brandy
line at the start of a program, which LOAD and CHAIN ignore, but allows it to be run like a UNIX script (e.g. shell, Perl, Python, TCL etc.), but a line starting with #! will report "Syntax error" in BASIC and is safe to ignore when *EXEC'ing in such a program.

Anyway, this is now fixed and checked in, and the nightlies have been rebuilt.
Matrix Brandy BASIC VI (work in progress)

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Soruk » Tue Jul 21, 2020 1:38 pm

I've reworked the BrandyApp mechanism so instead of using 'ld' to put the BASIC program into a blob in a .o file, it creates a .c file instead. This is in response to RISC OS not using the regular 'ld' in its gcc implementation, and its linker isn't able to do stuff like this. The git tree is also now configured to ignore "app.c" so, like all object files, it will be skipped over when it comes to tracking the files in the repository. The converter program to make the .c program is itself a BASIC program so you'll need a regular build - SDL or text, either is OK. While it uses the ARGC and ARGV$ pseudo-variables to pick up command-line arguments when called from Brandy, it will run on ARM BBC BASIC on RISC OS and prompt for the parameters (and will also prompt on Brandy if they aren't supplied on the command line).
Matrix Brandy BASIC VI (work in progress)

User avatar
Richard Russell
Posts: 1595
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Richard Russell » Tue Jul 21, 2020 3:27 pm

Soruk wrote:
Tue Jul 21, 2020 1:38 pm
I've reworked the BrandyApp mechanism so instead of using 'ld' to put the BASIC program into a blob in a .o file, it creates a .c file instead.
This complication isn't necessary in Windows, because it's perfectly legitimate simply to append a binary blob (so-called 'extra data') to the end of a PE-format executable. It can therefore be done after the linker has been run, just by concatenating the two (or more) files. There is a minor issue when it comes to signing such a composite file, but that is easily worked around. This is how BBC BASIC for Windows creates its standalone executables.

I must admit I thought the same was true of Elf object files, although I've not needed to put it to the test (the concept of 'standalone executable' doesn't really apply when there's a dependence on non-native libraries like SDL).

Having mentioned signing, is there any chance that you could sign your Windows Matrix Brandy executables? It's quite annoying to receive the worst kind of security warning from Windows (and having to wait for an online scan) every time I run it.

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Soruk » Tue Jul 21, 2020 3:38 pm

Richard Russell wrote:
Tue Jul 21, 2020 3:27 pm
Soruk wrote:
Tue Jul 21, 2020 1:38 pm
I've reworked the BrandyApp mechanism so instead of using 'ld' to put the BASIC program into a blob in a .o file, it creates a .c file instead.
This complication isn't necessary in Windows, because it's perfectly legitimate simply to append a binary blob (so-called 'extra data') to the end of a PE-format executable. It can therefore be done after the linker has been run, just by concatenating the two (or more) files. There is a minor issue when it comes to signing such a composite file, but that is easily worked around. This is how BBC BASIC for Windows creates its standalone executables.

I must admit I thought the same was true of Elf object files, although I've not needed to put it to the test (the concept of 'standalone executable' doesn't really apply when there's a dependence on non-native libraries like SDL).
I'm not sure how I would address it from within the binary, this way the address of the blob is known and is completely cross-platform (tested on Linux 32-bit & 64-bit, Windows 32-bit & 64-bit, and RISC OS 32-bit.
Richard Russell wrote:
Tue Jul 21, 2020 3:27 pm
Having mentioned signing, is there any chance that you could sign your Windows Matrix Brandy executables? It's quite annoying to receive the worst kind of security warning from Windows (and having to wait for an online scan) every time I run it.
Sorry if this is a silly question, but as you are aware I'm not really a Windows programmer (my dev environment uses Cygwin so is UNIX-like). How would I go about signing it?
Matrix Brandy BASIC VI (work in progress)

User avatar
Richard Russell
Posts: 1595
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Richard Russell » Tue Jul 21, 2020 3:56 pm

Soruk wrote:
Tue Jul 21, 2020 3:38 pm
I'm not sure how I would address it from within the binary
In BB4W (and simplifying things somewhat) at the very end of the file I store a pointer to the start of the binary blob. So at runtime I seek to where that pointer is stored, read it, and then seek to the binary data.

I couldn't do it exactly the way you are because it requires a linker; in Linux a linker is probably guaranteed to be available, but not in Windows (that's something you're only likely to have if you've installed development tools).
How would I go about signing it?
Signing isn't unique to Windows, it's pretty much compulsory in all OSes except Linux if you're not to receive warnings (or worse) at install time, and as malware becomes more common and more sophisticated this requirement is only going to increase. In Windows it's just a case of running the signtool utility, but of course you need a Code Signing Certificate. Do you have one (or does your employer have one you're allowed to use)?

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Soruk » Tue Jul 21, 2020 5:16 pm

Richard Russell wrote:
Tue Jul 21, 2020 3:56 pm
Do you have one (or does your employer have one you're allowed to use)?
I don't have one, and my eomployer isn't in the software development business. I've had a look at a few, prices are not sensible for an open source project (and being in the middle of a divorce, so every penny has to count) - not to mention they don't want individuals getting them, they have to be for businesses. I'm not going to formally register a business and pay all that is required, as it would be massively expensive for me with zero return.
Matrix Brandy BASIC VI (work in progress)

User avatar
Richard Russell
Posts: 1595
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Richard Russell » Tue Jul 21, 2020 6:50 pm

Soruk wrote:
Tue Jul 21, 2020 5:16 pm
prices are not sensible for an open source project
My Code Signing Certificate, which I can use any number of times, cost me $195 for 3 years, or around £4.50 a month. I consider that a bargain compared with a typical broadband subscription or a mobile phone contract, say.

Increasingly, and understandably, people simply won't install software that their OS (whether it be Windows, MacOS, Android or iOS) warns them is unsafe - and overriding the warnings isn't always possible. As I said before, this is only going to get worse.
not to mention they don't want individuals getting them
That's not been my experience. You do of course have to prove your identity, which typically means sending a scan of a utility bill or something like that, but as a sole trader I've not been treated any differently from an individual when purchasing mine.
I'm not going to formally register a business and pay all that is required
There's not the slightest need to do that.

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Soruk » Tue Jul 21, 2020 6:57 pm

Richard Russell wrote:
Tue Jul 21, 2020 6:50 pm
Soruk wrote:
Tue Jul 21, 2020 5:16 pm
prices are not sensible for an open source project
I'm not going to formally register a business and pay all that is required
There's not the slightest need to do that.
Who is your signing provider? Admittedly, the first one I looked at (Tucows) said their provider required proof of business registration...
Matrix Brandy BASIC VI (work in progress)

User avatar
Richard Russell
Posts: 1595
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Richard Russell » Tue Jul 21, 2020 7:43 pm

Soruk wrote:
Tue Jul 21, 2020 6:57 pm
Who is your signing provider? Admittedly, the first one I looked at (Tucows) said their provider required proof of business registration...
Tucows, yes. I've no idea what they are talking about in respect of "business registration" since I'm not a registered business and never have been. My understanding is that Tucows certificates are issued by Sectigo, who say "Sectigo is among the only Certificate Authorities that offers both an organization and an individual code signing certificate option" (my emphasis).

User avatar
Richard Russell
Posts: 1595
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Richard Russell » Fri Jul 24, 2020 10:33 am

In this thread the 'wrapping' behaviour of RENUMBER in various different versions of BBC BASIC is discussed. Matrix Brandy seems to be the odd-one-out because although it issues a warning it can irreversibly corrupt the program by not correctly resolving cross-references:

brandy_renumber.png

User avatar
Richard Russell
Posts: 1595
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Richard Russell » Fri Jul 24, 2020 10:44 am

Actually Matrix Brandy's cross-reference correction seems to be broken anyway if the RENUMBER creates line number 65279 (which should be valid):

brandy_renumber3.png

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Soruk » Fri Jul 24, 2020 1:21 pm

Richard Russell wrote:
Fri Jul 24, 2020 10:44 am
Actually Matrix Brandy's cross-reference correction seems to be broken anyway if the RENUMBER creates line number 65279 (which should be valid):
Ooh, good spot. And... ouch.

Anyhow, I've fixed this (it's also broken upstream) - as there is a pass that identifies lines with line numbers I've done a line number check as it steps through, and if it would go out of range it blocks before it starts the actual renumber.

As an added bonus, your format BASIC programs without line numbers were previously imported with all lines numbered zero, they are now renumbered with a step of 1. As 0 is a valid line number for Acorn format and Matrix Brandy, a renumber is triggered if it finds more than one line with a zero line number.

I've rebuilt the nightly.
Matrix Brandy BASIC VI (work in progress)

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Matrix Brandy BASIC VI for console and SDL1.2: V1.22.7 released

Post by Soruk » Sat Aug 01, 2020 1:29 pm

Hi,

I've just put together version 1.22.7 of Matrix Brandy BASIC VI. Notable changes since 1.22.6 include:

- Platforms: Native display builds for RISC OS available, including networking. 26-bit and 32-bit builds both possible.
- Platforms: SYS calls on RISC OS can call the Brandy_* calls from within the interpreter in addition to the RISC OS native calls. OS_SWINumerFromString is intercepted to also recognise the Brandy_* calls.
- Platforms: BrandyApp build mechanism changed, no longer relies on ld to build a .o file, instead uses a BASIC program to build a .c file with the program data embedded.
- System: pthreads used for timer thread on non-SDL (and non-RISC OS) builds.
- System: Timer uses monotomic clock instead of gettimeofday().
- System: *EXEC now interruptable with ESCAPE, and not aborted on other errors.
- BASIC: Unsigned 8-bit data type (var&) implemented.
- BASIC: Overflowing a 32-bit integer variable will now raise an error instead of silently wrapping. (uint8 variables will wrap.)
- BASIC: OLD keyword now reports Unsupported. It never worked properly and in Brandy it is rather pointless.
- BASIC: DELETE keyword now requires at least one parameter.
- BASIC: Lowercase immediate mode commands no longer allowed, unless compiled with -DBRANDY_ALLOW_LOWERCASE_COMMANDS
- BASIC: RENUMBER edge cases fixed.
- BASIC: GET(x,y) and GET$(x,y) are now relative to the current text viewport as set with VDU28.
- Examples: Teletext screen editor updated with mouse support, inspired by code written as examples for Pixelblip@Stardot's editor.

Source tarballs, Windows 32-bit and 64-bit builds, and RISC OS 26-bit and 32-bit builds are on the website. And there's GitHub as usual.
Matrix Brandy BASIC VI (work in progress)

User avatar
Richard Russell
Posts: 1595
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.7 released

Post by Richard Russell » Sun Aug 02, 2020 10:34 am

In another thread you advised against using a 'suffixless' variable to hold an address/pointer in Matrix Brandy, for example:

Code: Select all

      DIM s &2FFF
Am I right in thinking that, in practice, this is entirely safe because no current CPU has a virtual address space larger than 52-bits (most are 48-bits I think)? I know that there are proposed extensions to 57 bits of virtual address but I'm not sure that there are yet any such devices in circulation.

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.7 released

Post by Soruk » Sun Aug 02, 2020 10:49 am

Richard Russell wrote:
Sun Aug 02, 2020 10:34 am
In another thread you advised against using a 'suffixless' variable to hold an address/pointer in Matrix Brandy, for example:

Code: Select all

      DIM s &2FFF
Am I right in thinking that, in practice, this is entirely safe because no current CPU has a virtual address space larger than 52-bits (most are 48-bits I think)? I know that there are proposed extensions to 57 bits of virtual address but I'm not sure that there are yet any such devices in circulation.
I will have to test that...

Matrix Brandy uses 64-bit 'double' for the float type, BBCSDL and BB4C use 80-bit (so yours should be safe into the future). That may be something I need to look at coming up.
Matrix Brandy BASIC VI (work in progress)

User avatar
Richard Russell
Posts: 1595
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.7 released

Post by Richard Russell » Sun Aug 02, 2020 12:32 pm

Soruk wrote:
Sun Aug 02, 2020 10:49 am
BBCSDL and BB4C use 80-bit (so yours should be safe into the future).
That's not the reason mine are "safe". Even when running on ARM (which doesn't have 80-bit floats) mine are still entirely safe because suffixless variables are numeric variants, not floats (on ARM they can contain either a 64-bit double or a 64-bit integer).

If you can confirm it's safe in Matrix Brandy too (for a different reason) it will be helpful from a compatibility perspective. I actively encourage people to use suffixless variables to hold addresses.

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.7 released

Post by Soruk » Sun Aug 02, 2020 1:50 pm

Richard Russell wrote:
Sun Aug 02, 2020 12:32 pm
Soruk wrote:
Sun Aug 02, 2020 10:49 am
BBCSDL and BB4C use 80-bit (so yours should be safe into the future).
That's not the reason mine are "safe". Even when running on ARM (which doesn't have 80-bit floats) mine are still entirely safe because suffixless variables are numeric variants, not floats (on ARM they can contain either a 64-bit double or a 64-bit integer).
I had a look at creating a variant type, but Brandy's architecture is such that when a variable is created its type is set before the value goes near it. But, I might have another look at this it will be one of two 64-bit types so memory allocation shouldn't be too much of a hiccup. It might have to be a placeholder type that is fixed once a value is assigned to it.
Matrix Brandy BASIC VI (work in progress)

User avatar
Richard Russell
Posts: 1595
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.7 released

Post by Richard Russell » Sun Aug 02, 2020 3:43 pm

Soruk wrote:
Sun Aug 02, 2020 1:50 pm
I had a look at creating a variant type.
I've described how mine work on a previous occasion: a unique value for the 'exponent' (in practice zero) is used to flag the presence of an integer. Often this exponent value is reserved to mean a NaN or an un-normalised number, which I don't support in my BASICs anyway; but even if it isn't, doubling the smallest representable floating-point number is no great loss.

Internally my variants can be a string rather than a number, which is flagged (not surprisingly) by the 'exponent' being 0xFFFF! It's the data type used for the value returned by an FN (which I think is the only occasion in BBC BASIC that such a numeric-or-string variant gets used). In C it's declared as a union of the three types (integer, float, string).

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.7 released

Post by Soruk » Tue Aug 04, 2020 1:50 am

Richard Russell wrote:
Sun Aug 02, 2020 3:43 pm
I've described how mine work on a previous occasion: a unique value for the 'exponent' (in practice zero) is used to flag the presence of an integer. Often this exponent value is reserved to mean a NaN or an un-normalised number, which I don't support in my BASICs anyway; but even if it isn't, doubling the smallest representable floating-point number is no great loss.

Internally my variants can be a string rather than a number, which is flagged (not surprisingly) by the 'exponent' being 0xFFFF! It's the data type used for the value returned by an FN (which I think is the only occasion in BBC BASIC that such a numeric-or-string variant gets used). In C it's declared as a union of the three types (integer, float, string).
I've got my variant partially working - it can handle an int64 or a float64 (but not a string, yet). It's only used when a non-suffixed variable is created, and the type is replaced when the data is written. Once set, its type is fixed. I've had to be a bit more devious (as you can make use of the extra 16 bits from using an 80-bit float), reorganising the items in my variable type struct (as in places where I'd need to be able to write the type, only the address of the variable's value is passed). It assumes that the union of stuff that is no more than 64 bits in size BAD ASSUMPTION - turns out the included basicstring struct is int32 and pointer, so can be 96 bits long - fixed with offsetting using sizeof(basicstring) (and has at least two items that are 64 bits even on 32-bit hardware) and the compiler will lay out in memory in exactly the order defined in the struct.
Last edited by Soruk on Tue Aug 04, 2020 7:21 am, edited 1 time in total.
Matrix Brandy BASIC VI (work in progress)

User avatar
Richard Russell
Posts: 1595
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.7 released

Post by Richard Russell » Tue Aug 04, 2020 3:48 am

Soruk wrote:
Tue Aug 04, 2020 1:50 am
I've got my variant partially working - it can handle an int64 or a float64 (but not a string, yet).
I'm puzzled that you would want your variants to handle a string; I wouldn't have expected this implementation detail of BB4W/BBCSDL, which can't be observed externally, to be relevant to you. I'm assuming that whatever mechanism in Matrix Brandy currently allows an FN to return either a number or a string works satisfactorily, so there is no pressure on you to change it to work more like my BASICs internally.
turns out the included basicstring struct is int32 and pointer, so can be 96 bits long - fixed with offsetting using sizeof(basicstring)
The way I handle this is that my string pointers are 32-bit heap addresses, not 64-bit machine addresses. This means that a string descriptor requires only 64-bits, not 96 bits, but does mean that strings can only be stored in the heap. That's not a significant limitation for me because the string allocation mechanism makes this assumption anyway (a string's memory, once freed, is assumed always to be available for another string so you can't point a string at arbitrary memory).

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.7 released

Post by Soruk » Tue Aug 04, 2020 10:17 am

Richard Russell wrote:
Tue Aug 04, 2020 3:48 am
Soruk wrote:
Tue Aug 04, 2020 1:50 am
I've got my variant partially working - it can handle an int64 or a float64 (but not a string, yet).
I'm puzzled that you would want your variants to handle a string; I wouldn't have expected this implementation detail of BB4W/BBCSDL, which can't be observed externally, to be relevant to you. I'm assuming that whatever mechanism in Matrix Brandy currently allows an FN to return either a number or a string works satisfactorily, so there is no pressure on you to change it to work more like my BASICs internally.
I wasn't trying to match the internals, but previously found that doing:

Code: Select all

t="Hello World"
didn't throw an error (testing in BB4C) I assumed you could set a variant to a string.

Subsequently, this morning, I found I was getting a very unexpected result, which I have posted to the BB4C thread as I think it might be a bug.

In that case, I'll leave my variant implementation where it is, where it can be an int64 or a float. However, unlike your implementation its type is fixed once set.
Matrix Brandy BASIC VI (work in progress)

User avatar
Richard Russell
Posts: 1595
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.7 released

Post by Richard Russell » Tue Aug 04, 2020 11:05 am

Soruk wrote:
Tue Aug 04, 2020 10:17 am
I think it might be a bug.
Yes, you should get a 'Type mismatch' error, but it's not reported in the 64-bit editions; now fixed in my local copy. I could quite easily implement variants which could be strings as well as numerics, but the only value I can see in BBC BASIC would be for holding the returned value from a FN without knowing whether it is a number or a string. In nearly 40 years I've probably only wished I could do that once or twice:

Code: Select all

      variant = FNsomething : REM might return a number or a string
      PRINT variant
However, unlike your implementation its type is fixed once set.
What's the practical implication of that? Presumably the type can change in this kind of situation:

Code: Select all

      n = &1234
      n *= 1.1
where n is initially an integer but is promoted to a float as a result of the multiplication. Or similarly:

Code: Select all

      n = 2^63 - 1
      n += 1
where the addition takes it out of range for an integer but still representable as a float.

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.7 released

Post by Soruk » Tue Aug 04, 2020 9:27 pm

Richard Russell wrote:
Tue Aug 04, 2020 11:05 am
Soruk wrote:
Tue Aug 04, 2020 10:17 am
However, unlike your implementation its type is fixed once set.
What's the practical implication of that? Presumably the type can change in this kind of situation:

Code: Select all

      n = &1234
      n *= 1.1
where n is initially an integer but is promoted to a float as a result of the multiplication. Or similarly:

Code: Select all

      n = 2^63 - 1
      n += 1
where the addition takes it out of range for an integer but still representable as a float.
You raise a very good point. However, I've backed this out from the main branch as my variant stuff is breaking too many things. I've moved it to a branch, but it may well never get merged if I can't get it to work right.

For now, my recommendation for Matrix Brandy and DIMming memory blocks is to explicitly use the 64-bit int type.
Matrix Brandy BASIC VI (work in progress)

User avatar
Richard Russell
Posts: 1595
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.7 released

Post by Richard Russell » Wed Aug 12, 2020 10:48 pm

I'm not sure if this is a bug or a feature, or even if Matrix Brandy's 'virtualising' of MODE 7 to address &7C00 is officially supported (ARM BASIC doesn't do it AFAIK), but there's a difference in how it behaves compared with BeebEm as you can see below. I discovered this when experimenting with MODE 7 sprites for pixelblip:

beebem7c00.png
brandy7c00.png

Post Reply

Return to “modern implementations of classic programming languages”