Crunchie for crunching BASIC

I am very impressed with !Crunchie and I am using to crunch a 156K program which still gas a handfull of GOTOs in it.

Removing the remaining GOTOs requires a fair bit of re-coding, so I intitially opted for putting a # at the beginning of the target lines. But that means that the program will not run unchruched.

So, I am looking for an alternative. I have altered the source code for crunchie to add SYS to the list of do-not-crunch-after keywords and then added a SYS “OS_ReadMonotonicTime”: to the beginning of every GOTO target line. My logic being that ReadMonotonicTime will never alter the logic of my program and the time overhead should be negligable.

Have I missed a more obvious solution?

Removing the remaining GOTOs requires a fair bit of re-coding, so I intitially opted for putting a # at the beginning of the target lines. But that means that the program will not run unchruched.

Doesn’t that mean that it won’t run crunched, either, or does Crunchie use # as a magic marker of some kind? If so, then shouldn’t it perhaps be using something that doesn’t affect the execution – such as some kind of REM directive along the lines of BB4W?

I have altered the source code for crunchie to add SYS to the list of do-not-crunch-after keywords and then added a SYS “OS_ReadMonotonicTime”: to the beginning of every GOTO target line.

Aside from just how ugly that is (and how counter-intuitive it will be to anyone else reading the code), doesn’t that mean that any line containing SYS will not be crunched?

My logic being that ReadMonotonicTime will never alter the logic of my program and the time overhead should be negligible.

Presumably the “do not crunch” directive means that the calls remain as

SYS "OS_ReadMonotonicTime"

and not

SYS &42

If so, isn’t there now a SWI name lookup overhead on each line? (Unless you’re putting SYS &42 on each line, in which case the counter-intuitive comment applies even more.)

Have I missed a more obvious solution?

I can’t help but think “yes”. Either don’t use GOTO, or don’t crunch incompatible programs.

I’ve not used GOTO for I don’t know how long; I’m honestly amazed that anyone still does. The idea of worrying about crunching any program that contains GOTOs fascinates me: so far as I’m concerned, any program that contains GOTOs was written so long ago that if it ran fast enough to be worth running at all in the days when it was written, it would be finished in the blink of an eye on any modern machine without being crunched at all.

To be honest, not all of the GOTOs are as old as other older parts of the program.

BBC Basic GOTOs are very fast. VERY Fast. Much faster than some other ‘structured’ program elements. Much faster than the blink of an eye. Think of GOTOs as a step between full structured programming and assembler.

It is the rest of the program which benefits from crunching.

does Crunchie use # as a magic marker of some kind?

Yes.

Sorry, I meant do-not-join-before rather than do-not-crunch-after.

a 156K program which still gas a handfull of GOTOs in it. […] So, I am looking for an alternative

By default Crunchie removes empty lines, which could be the target of GOTO. Use the switch “-emptyoff [-e]” to disable this. Let me know if it is working, because I never use GOTO. ;-)

BBC Basic GOTOs are very fast. VERY Fast. Much faster than some other ‘structured’ program elements.

I am surprised that you find this. Even though BASIC encodes line numbers after GOTO, which is a little quicker than reading a literal, it still has to find that line in the program, which it does by starting at the first line every time. A GOTO a line at the end of a large program suffers.

A call to a PROC, after the first call, has to look up the name in the list, but can then jump directly to the program address. This might not be so fast, depending on the relative parameters, but you also have to take account of the ‘Synergistic Cache Technology’. That is SW’s name for directly accessing PROC calls etc from their program address. This is very fast indeed, but only when cache hits are made, and that generally means in tight loops.

does Crunchie use # as a magic marker of some kind? – Yes.

That may be misleading, and I am not sure it is what you meant.

If Crunchie has the -translate switch set then it can do GOTO a label. Labels start with #. However, such a program will not run until it has been translated.

By default Crunchie removes empty lines, which could be the target of GOTO. Use the switch “-emptyoff [-e]” to disable this. Let me know if it is working, because I never use GOTO. ;-)

Yes, that particular bit works fine. Although, in my case, I finish up with loads of other empty lines not related to GOTOs.

But the standard BASIC$CRUNCH removes all such lines when the program is run. So the GOTOs still do not work, unless the standard BASIC$CRUNCH is disabled which affects all other programs.
EDIT: Investigation appears to show that this statement was wrong. Sorry.

I am surprised that you find this. Even though BASIC encodes line numbers after GOTO, which is a little quicker than reading a literal, it still has to find that line in the program, which it does by starting at the first line every time. A GOTO a line at the end of a large program suffers.

Oh! I thought I read somewhere that BASIC held the target line numbers in a list, like PROCs
EDIT: Looking through my code reveals that the frequently used GOTOs are all in PROCs at low line numbers

That may be misleading, and I am not sure it is what you meant.

I agree it is misleading. I was using #tags just to stop !Crunchie removing the line number. I still used GOTO linenumber, not GOTO tag. Either way, as you say, the program will not run in its raw form.

I’ve not used GOTO for I don’t know how long; I’m honestly amazed that anyone still does.

There is a certain class of problems (e.g. state machines) that might benefit from using GOTO to make the code a lot clearer. Usually, you find a lot of state variables and clever if-then-else constructs if someone was really keen to avoid GOTOs without having an idea why this is only a general rule, but not a universal rule to follow.

Unfortunately, BBC BASIC V does not support labels, so you are forced to work with line numbers, which reduces code readability, so the “case for GOTO” is less clear in BBC BASIC V world.

I’ve not used GOTO for I don’t know how long; I’m honestly amazed that anyone still does.

I can’t resist to wholeheartedly agree, no matter how much I respect Steffen Hubers reply. I’ve always been puzzled by the fact that BASIC still supports it.

Usually, you find a lot of state variables and clever if-then-else constructs if someone was really keen to avoid GOTOs

That puzzles me too. It suggests that using GOTO is something intuitive, that can only be avoided deliberately by constructing complex code. I’ve never felt it that way. On the contrary even. Using GOTOs would imply line numbers to begin with. It’s not even aesthetic!

Line numbers are useful – for pinpointing errors. I only turn them on when I get an error message, which conveniently points out a line for me.

As far as I know, you don’t need to turn line numbers on to find the culprit line (with F5). I know that, because I always face an impressive amount of errors, and I never have line numbers switched on.

But the standard BASIC$CRUNCH removes all such lines when the program is run. So the GOTOs still do not work, unless the standard BASIC$CRUNCH is disabled which affects all other programs.

Could you add an *Unset Basic$Crunch in the !Run file just before you start your program, and *Set Basic$Crunch Yes again immediately after?

I, like many others, stopped using GOTO in 1982, when I started using BBC BASIC. Changing Crunchie to avoid removing lines which are GOTO targets would I suspect be a major change, requiring an additional source scan to find and remember the target lines of any GOTOs.

As for performance, each GOTO execution causes a search from the start of the program for the line number.

Out of interest, are the program sizes you have quoted the uncrunched source sizes, or the crunched sizes?

Organizer source is about 2MB, reducing to 360KB after Crunchie.

I do not mind GOTO label, so long as the jump does not cross scope boundaries (though scoping is so simple in BASIC that the problems associated with crossing scope boundaries are less likely to appear). It is line numbers that are the problem. Confusing editing features with programming features meant that each aspect dragged the other down.

Could you add an *Unset Basic$Crunch in the !Run file just before you start your program, and *Set Basic$Crunch Yes again immediately after?

I had already edited that post to say that my statement was wrong.

I can confirm that when the variable is unset and set again that the GOTOs work after -emptyoff

Out of interest, are the program sizes you have quoted the uncrunched source sizes, or the crunched sizes?

Uncrunched 156K
Crunched with -emptyoff 72K
Crunched without -emptyoff 68K

I am about to start testing for a crunched version of a BASIC program which is 240K uncrunched.

Still small compared with yours.

As far as I know, you don’t need to turn line numbers on to find the culprit line (with F5).

Is that StrongEd, Edit, or Zap? If it works in Zap, I’ve been missing a trick! :-)

(Edit: it does, and I have. The other use I’ve had for them in the past was in teaching – it helps to be able to refer to lines in a way that makes them easy to find. But it’s twenty-five years since I was a teacher.)

Unfortunately, BBC BASIC V does not support labels, so you are forced to work with line numbers, which reduces code readability

I just mentioned that both Crunchie and Basalt support labels, but in both cases the program has to be translated before it is run. A couple of years back I did a little utility for David F to use labels in BASIC, which you might consider a nascent Crunchie. ;-)

Of interest, Basalt’s GOTO#label jumps straight to the address, so it is undoubtedly quick. Sorry, but until I get assembly sorted that it is not going to be useable. ;-(

I mention it, because it would be quite feasible for BASIC to do this.

Changing Crunchie to avoid removing lines which are GOTO targets would I suspect be a major change, requiring an additional source scan to find and remember the target lines of any GOTOs.

Crunchie starts by using BASIC’s CRUNCH %1111. This does not remove empty lines, and the manual before the current one says it does not because it “may cause problems in constructs that expect an empty line as the target (e.g. GOTO, GOSUB, IF THEN, RESTORE).” If Crunchie -emptyoff switch is set it does nothing to change this.

To implement labels with Crunchie -translate there is indeed an additional scan, and empty lines can be removed.

WARNING: I have been off my machine and the latest version of Crunchie is deeply flawed. Watch this space!

WARNING: I have been off my machine and the latest version of Crunchie is deeply flawed. Watch this space!

I am back and version 0.76 is uploaded. I think it is now ok. ;-)

I did a little utility for David F to use labels in BASIC

And thanks for this :)