New: Console Mode editions of BBC BASIC

[Deleted User 9295]

Performance numbers updated to include 10.3.1:

Do we know whether the stack usage of GCC 10 is significantly different from earlier versions? An issue was identified early on in the development of the Pico version of BBC BASIC, whereby stack use varied dramatically according to the optimisation level. Here are some of the figures measured then:

Code: Select all

----------------------------------
-O1   1320 bytes/recursion
-O2   1336 bytes/recursion
-O3   2704 bytes/recursion
----------------------------------

This meant that -O3 could not be used, irrespective of the impact on performance, because programs relying on recursion (sudoku.bbc is a case in point) could fail due to stack overflow.

[hoglet]

Do we know whether the stack usage of GCC 10 is significantly different from earlier versions? An issue was identified early on in the development of the Pico version of BBC BASIC, whereby stack use varied dramatically according to the optimisation level. Here are some of the figures measured then:

That took a bit longer that I expected....

The *SBRK command no longer exists - it seems it got dropped in one of the merged - so I added it back in locally.

Unfortunately it's pretty much the same with GCC 10.3:

Using -O1 - 1304 bytes:

Using -O2 - 1640 bytes:

Using -O3 - 2384 bytes:

For reasons I don't understand, the -O3 option actually runs about 5% slower than -O1, according to the speed benchmark. So maybe it's not that imprtant to resolve the stack usage issue.

Dave

[Deleted User 9295]

The *SBRK command no longer exists - it seems it got dropped in one of the merged

Yes, it was a temporary debug feature only.

Unfortunately it's pretty much the same with GCC 10.3:

OK, at least it's not worse!

One reason for higher levels of optimisation resulting in more stack usage is, I assume, the effect of inlining. If you inline a function, any local variables of that function become local variables of the calling function, so instead of the stack space they occupied being freed on return, it just adds to the stack frame of the calling function.

A similar thing can happen with an optimised-out tail-call. If the calling function has very little stack usage but the tail-called function has a lot, the calling function acquires all that stack usage. But it might have been coded that way precisely to minimise stack growth when recursion is involved:

Code: Select all

void function(void)
{
      recursive_call();
      tail_call();
}

You want as little stack as possible to have been used when recursive_call() is made, but optimising out the tail_call() may mean that the entirety of that function's stack frame adds to the cumulative total on recursion!

It would be useful to be able to tell the compiler not to reserve stack ahead-of-time, but only when actually needed (which is probably what an assembly language programmer would do), but I'm not aware of any such capability.

[cmorley]

For reasons I don't understand, the -O3 option actually runs about 5% slower than -O1, according to the speed benchmark. So maybe it's not that imprtant to resolve the stack usage issue.

O3 is often not a win because of code and memory usage bloat. If it bloats past cache sizes then you can easily take a performance hit... e.g. i-cache causing more FLASH reads with waitstates or D-cache simply being thrashed. I'm not surprised -O3 can be slower.

[Deleted User 9295]

O3 is often not a win because of code and memory usage bloat.

Indeed, and it's why I often use -Os (or -Oz in Clang), but for reasons that haven't been ascertained doing that breaks the Pico BBC BASIC build entirely! I worry that it is pointing to something strictly illegal in my code that I'm not aware of (it wouldn't be the first time).

[cmorley]

Indeed, and it's why I often use -Os (or -Oz in Clang), but for reasons that haven't been ascertained doing that breaks the Pico BBC BASIC build entirely! I worry that it is pointing to something strictly illegal in my code that I'm not aware of (it wouldn't be the first time).

This can happen with type punning & breaking the strict aliasing rules of C (and C++). Code works with one optimisation level then breaks at another.

Check for code where you cast a pointer to a different type... e.g. struct* to a char*. The compiler is within its rights to elide code which has no observable effects and if you break the pointer aliasing rules then it can elide code you intended be executed.

I'm sure there are other reasons why code can break with optimisations and mature compilers (i.e. not bug ridden compilers).

[Deleted User 9295]

Check for code where you cast a pointer to a different type... e.g. struct* to a char*.

The question is: what should I check it for?! I'm not a C programmer and don't have the foggiest idea about the 'rules'; as I've said before the C version of my BBC BASIC interpreter is mostly a semi-automated translation of the assembler original, where register names become variables. For example:

Code: Select all

      mov esi,ebx

becomes:

Code: Select all

      void *esi = ...;
      intptr_t ebx = ...;
      esi = (void*) ebx;

Casts like that are used in their thousands because the assembly language code has no concept of 'type' and is converting between integers and pointers etc. all the time. If somebody who understands these things wants to plough through the Megabyte or so of source code they are welcome, but I'd have no idea what to look for.

If you say (and I wouldn't blame you) that code created that way, by somebody with no knowledge of the C language, is unacceptable, I will happily and without hesitation discontinue all my products built from that code base. It had been my intention to do that anyway on 1st October last, but I didn't go ahead with it then. I have been considering doing it (and closing down all my websites and other online resources) at the end of the year.

[BigEd]

I don't think there's any need to try to inspect the codebase at this level - it might mean that -Os isn't available, with some compilers, but so be it.

The value is in what the code does do!

Please don't be put off by one voice, whatever it might say.

[Deleted User 9295]

I don't think there's any need to try to inspect the codebase at this level - it might mean that -Os isn't available, with some compilers, but so be it.

If it means, as it probably does, that there are places where my code 'breaks the rules of C', so that the compiler feels able to change the function of the code when optimising, then this is potentially quite serious. After all, a comprehensive test of every feature of BBC BASIC is all but impossible so if only an obscure, rarely-used, part of the interpreter was affected it could go undetected and cause BASIC programs to fail in confusing and unexpected ways.

Although my BBC BASIC shouldn't be used for 'life critical' applications it certainly has been for professional applications in which it would be unacceptable for it to misbehave, produce incorrect results from a calculation or similar. As an example I would point to the BBC BASIC installation at the Colosseum in Rome which monitors and logs earth tremors 24 hours a day. That's written in BBC BASIC for Windows, in which I have more confidence, but I would not want BBC BASIC for SDL 2.0 to be any less reliable.

So I do think, ideally, that my code should be "inspected at this level", but I can't do it. Not only does my negligible knowledge of C not allow me to tell when something is legitimate or not, my mental deterioration is now so severe that I can barely understand what the code is supposed to do anyway! That's why I suggested that the safest approach may be to abandon my versions of BBC BASIC altogether and leave the field to more competent products like Brandy BASIC.

Are there any automated tools which can draw attention to possibly problematic C code?

[Soruk]

So I do think, ideally, that my code should be "inspected at this level", but I can't do it. Not only does my negligible knowledge of C not allow me to tell when something is legitimate or not, my mental deterioration is now so severe that I can barely understand what the code is supposed to do anyway! That's why I suggested that the safest approach may be to abandon my versions of BBC BASIC altogether and leave the field to more competent products like Brandy BASIC.

I strongly disagree with this notion.

I have run into issues with -Os when compiling Brandy - and it breaks in ways that I just can't figure out, and it varies from compiler to compiler. To the point that the GCC 4 cross-compiler for RISC OS won't even compile it with -Os, the compiler itself crashes, but with -O2 it's fine...

Also, while I can now no longer replicate this, back in 2018 I had a very weird crash where some graphics operations in Brandy would just draw incorrectly when compiled with -Os on the RasPi, but not on other platforms. I didn't do anything specific to fix it as the incorrect drawing and crashes just did not happen in any specifically repeatable fashion, and suddenly one day it stopped being a problem.

If y our approach makes code that is useful to people, then stick with it, it obviously works for you, and if specific compiler options break it, don't use those options!

[BigEd]

(There are automated tools - what I'd suggest, if this is important, is that you collaborate with someone who can start to feed in small fixes which you can merge. You'd need to be ready to accept them, and they might touch crucial files which affect all builds, and I know that will have a cost as a consequence. This is something to tackle carefully and progressively, at a time when the project is otherwise quiescent.)

[Deleted User 9295]

what I'd suggest, if this is important, is that you collaborate with someone who can start to feed in small fixes

We've been through this before: there is nobody who wants to collaborate with me. I put the code of BBC BASIC for SDL 2.0 (and later the Console Mode editions) at GitHub specifically with the hope that it would encourage exactly that, but it hasn't happened and is most unlikely to now. I can quite understand why no competent programmer wants to get involved with code mechanically translated from assembler!

My BBC BASICs have come to the end of their useful lives, just as I am rapidly approaching the end of mine. There's no point being sentimental about it.

[cmorley]

Are there any automated tools which can draw attention to possibly problematic C code?

Some linters might? Maybe hoglet might know. The Roslyn intellisense built into Visual Studio is getting better and better at suggestion higlighting. GCC has some aliasing warnings you can enable but I don't know how helpful they might be.

You could try compiling with GCC -fno-strict-aliasing (or CLANG equivalent) since -fstrict-aliasing is turned on for -O2, -O3 & -Os in GCC.

Type-punning is legal in C via unions (rather than dereferencing pointers) is an extension in gcc but rewriting your code generator to replace pointers with unions sounds like a lot of work. I am not saying pointer aliasing is definitely a problem here just that it can cause the exact symptoms you describe. I certainely wouldn't scrap a code base over it.

edit: Union type-punning is GCC not C standard. memcpy is the correct way to do type-punning I think and modern compilers will detect that and should elide the memcpy

[BigEd]

I suppose what I'm saying is that you needn't think you need to try to do this yourself: as Soruk notes, there is in a sense no need. With the code open source, anyone can at any time have a go, but ideally they'd do it with your help and you'd merge their work.

One might say that no software is ever finished, but ideally it gets to the point where it's useful. I don't think it's sentimentality to want to keep BBC BASIC going.

[RobMcK]

Are there any automated tools which can draw attention to possibly problematic C code?

I use clang-tidy to check for some coding habits which result in undefined behaviour.

Clang keeps having more warnings added to help detect undefined behaviour etc and there’s warnings for doing nasty things to pointers when casting to or from ints.

I’ll look at the options I usually use and let you know. Can’t look now as I’m browsing on my phone.

Richard, I have the skills to review the code but unfortunately it’s not a lack of interest which prevents me from doing it but a lack of time and other pressures. I may be able to try to determine if a combination of clang and clang-tidy will identify the scale of the problem but not for the next few weeks.

Thank you for your work keeping BBC Basic alive.

Rob

[Deleted User 9295]

Clang keeps having more warnings added to help detect undefined behaviour etc and there’s warnings for doing nasty things to pointers when casting to or from ints.

I use Clang to compile BBC BASIC on MacOS, but it may not be a particularly recent version (I suppose it's whatever comes with Xcode). I use -Wall, with expected warnings explicitly suppressed (e.g. -Wno-array-bounds), so if I see anything at all it attracts my attention. I don't think I saw any warnings the last time I compiled it.

Should I be using different switches to maximise the value of the Clang warnings?

[shifters74]

I would like to echo Rob's sentiment - thanks for the work you do on BBC Basic for the many platforms - it helps keep BBC basic alive!

Kinds Regards

shifters

[RobMcK]

Clang keeps having more warnings added to help detect undefined behaviour etc and there’s warnings for doing nasty things to pointers when casting to or from ints.

I use Clang to compile BBC BASIC on MacOS, but it may not be a particularly recent version (I suppose it's whatever comes with Xcode). I use -Wall, with expected warnings explicitly suppressed (e.g. -Wno-array-bounds), so if I see anything at all it attracts my attention. I don't think I saw any warnings the last time I compiled it.

Should I be using different switches to maximise the value of the Clang warnings?

For clang, I use

Code: Select all

 -Wall -Wextra -Wpedantic -Wformat=2 -Wcast-align -Wsign-conversion -Wpadded -std=c11 -Wstrict-prototypes -Wold-style-definition

For GCC I use the same with the addition of

Code: Select all

-Wlogical-op

I'm not sure which of them is the magic one. I also use -Werror which makes warnings errors so the compile fails since we're not allowed any warnings

I've just checked my MAC and it has apple clang version 12.0.5 and I think that the warnings came in version 13 or version 14, I don't recall which.


Regards,

Rob

[markdryan]

You could also try the sanitizer, i.e., build with -fsanitize=undefined. This will add runtime checks to your compiled code for undefined behaviour so you need to run your code, e.g., run your test suite, to see the errors. It catches alignment issues (which can be introduced by type punning), integer and shift overflows. It’s found a whole bunch of these type punning issues in Subtilis (not all of which are fixed yet).

https://developers.redhat.com/blog/2014 ... izer-ubsan

[Deleted User 9295]

I've just checked my MAC and it has apple clang version 12.0.5 and I think that the warnings came in version 13 or version 14, I don't recall which.

OK, I'll try to bear it in mind (although I'll probably forget) if and when Xcode updates to a later version of Clang.

I don't want to enable any warnings about code which is 'bad practice' or 'non-standards compliant' but still guaranteed to work, since BBC BASIC will be riddled with that sort of thing.

Incidentally I cannot switch to Clang for most of my builds because they use features that Clang doesn't support, in particular register variables (not essential, but very useful for an interpreter) and nested functions (needed to implement SYS with Windows' unusual ABI).

You could also try the sanitizer, i.e., build with -fsanitize=undefined. This will add runtime checks to your compiled code for undefined behaviour so you need to run your code, e.g., run your test suite, to see the errors.

It would be nice to have a "test suite" with a reasonable coverage of BBC BASIC features, but nothing I have approaches that. I wonder if anybody has ever tried to create such a thing.

[hoglet]

You could also try the sanitizer, i.e., build with -fsanitize=undefined. This will add runtime checks to your compiled code for undefined behaviour so you need to run your code, e.g., run your test suite, to see the errors. It catches alignment issues (which can be introduced by type punning), integer and shift overflows. It’s found a whole bunch of these type punning issues in Subtilis (not all of which are fixed yet).

This is a reallt good suggestion.

I'm able to replicate the failures by using -Os

But unfortunately the sanitizer doesn't seem to be supported with the GCC ARM Embedded tool chain:
https://github.com/google/sanitizers/wi ... sSanitizer

(And indeed it fails to find libasan)

Dave

[Deleted User 9295]

I'm able to replicate the failures by using -Os

-Os works fine in Windows, with GCC 8.1.0 at least. I can't try it with GCC 10.3.0 because I get an immediate crash if I compile BBC BASIC with that:

Code: Select all

(13d0.175c): Unknown exception - code c0000028 (!!! second chance !!!)
ntdll!RtlRaiseStatus+0x36:
00007ffb`3ac72346 65488b0c2560000000 mov   rcx,qword ptr gs:[60h] gs:00000000`00000060=????????????????

When I first had problems with GCC 10 I blamed this regression; perhaps it's still not fixed in the binary currently available for download

[Deleted User 9295]

(And indeed it fails to find libasan)

No libasan anywhere in Windows GCC 10.3.0 either. If I build with -fsanitize=undefined (in both compiler and linker flags) I just get many linker errors like undefined reference to `__ubsan_handle_shift_out_of_bounds'. Is sanitize a Linux-only thing?

[RobMcK]

I've updated my fork of the BBCSDL GitHub repo to use the latest version and updated the actions to compile the console edition to use clang-13 and added some of the extra warnings.

There are a number of warnings generated. I've not spotted the warning about pointer eliding.

The results can be seen here: https://github.com/Rob-McKay/BBCSDL/run ... focus=true

I've run out of time for today. I'll try to look again tomorrow.

Regards,

Rob

[Deleted User 9295]

There are a number of warnings generated. I've not spotted the warning about pointer eliding.

What would be helpful is to filter out the irrelevant warnings, such as GNU extensions (of which I use many, indeed they are frequently commented as such in the source) and structure padding (not even sure why that deserves a warning).

Here's what I've determined myself on Windows (both GCC 8 and 32-bits GCC 10), as far as my simple tests can ascertain:

• Compiling with -O2 doesn't result in any problems.
• Compiling with -Os doesn't result in any problems.
• Compiling with -fstrict-aliasing doesn't result in any problems.

I conclude that there are probably no issues resulting from aliasing, and that the reason for the -Os failure on the Pico is something different.

[markdryan]

Is sanitize a Linux-only thing?

The address sanitizers don’t seem to be supported on windows but the undefined sanitizer is apparently, in clang at least. Having said that though I haven’t tried this configuration and a quick search doesn’t show up any evidence of it working on Windows, although there are lots of questions about linker errors. I’ve only used the undefined sanitizer with clang on MacOS and gcc on Linux. Both of these were x86_64 builds and both reported real problems that needed fixing.

[RobMcK]

I've updated my compile script to suppress most of the compiler warnings and the results are here: https://github.com/Rob-McKay/BBCSDL/runs/4124905244

The warnings about void* to function pointer are a problem if the function signature of the passed function does not match the parameter signature but since the passed signature is erased the compiler cannot check.


What is the exact problem we are trying to fix with the Pico version and is there an idiots guide to reproducing the fault I can follow? I did look back through the last couple of pages of messages but nothing jumped out at me.

[hoglet]

What is the exact problem we are trying to fix with the Pico version and is there an idiots guide to reproducing the fault I can follow? I did look back through the last couple of pages of messages but nothing jumped out at me.

To reproduce:
- Compile the Pico Console version with -Os
- Program onto Pico
- Connect to Pico over the USB UART with a terminal
- Enter PRINT PI

You then get PI printing in an endless loop.

It manfests in lots of other ways, but that was the first "wierdness" I encountered.

Dave

[Deleted User 9295]

- Enter PRINT PI
You then get PI printing in an endless loop.

So it's not returning to immediate mode, but somehow executing the same statement repeatedly? I wonder if it might be connected with the setjmp/longjmp mechanism, which my interpreter uses not only to handle errors but when returning to immediate mode on END (or after an immediate mode statement):

Code: Select all

	errcode = (setjmp (env)) ; // >0 = error, <0 = QUIT, 256 = END/STOP

It's setjmp/longjmp that's broken in GCC 10.3.0 on (64-bit) Windows, so at the very least it suggests that the GCC test suite doesn't have good coverage of this area. I'm not saying it's definitely a compiler bug, but that may increase the likelihood that it is.

[Deleted User 9295]

The warnings about void* to function pointer are a problem if the function signature of the passed function does not match the parameter signature but since the passed signature is erased the compiler cannot check.

As far as I can see, nearly all those warnings are related to the SYS statement. It is of course inevitably the case that the SYS statement in BBC BASIC cannot know the signature of the function being called: it's specified in the BASIC program and known only at run-time! So if I'm understanding the warnings correctly they are unavoidable.

There's nothing else I can see in your list that is remotely concerning. It doesn't seem to like a couple of empty function definitions, which are there simply to satisfy the linker; maybe those dummy functions should have a trivial body rather than an empty one, but they are never called anyway.