BASIC cruncher for PC

Development tools discussion area.
User avatar
sydney
Posts: 1979
Joined: Wed May 18, 2005 9:09 am
Location: Newcastle upon Tyne

BASIC cruncher for PC

Postby sydney » Fri Sep 29, 2017 7:47 am

EDIT: I've removed the old zip and uploaded a new one with a couple of silly bugs removed.

I'm writing a roguelike in BASIC and I'm developing it in linux using a text editor, beebasm and beebem. The PUTBASIC command in beebasm needs line numbers but I'm not including them in my source so I need a way to automatically number the program. I'm also using long names for variables and procedures as well as lots of comments and whitespace to keep it all nice and readable. This is causing memory problems when running on a beeb so I also wanted to automatically format the text in a more memory friendly manner.

I've started off by simply removing all leading spaces from each line, removing blank lines and all lines which are only REM statements. Next on my list will be all REM's, followed by reducing variable/procedure names to two letter combinations, though this won't happen until I need it in my roguelike project or I'm finished it.

It's written in FreeBASIC so it should compile and work on any system FreeBASIC is available on which is linux,Windows,OSX and I think android.

It is a command line tool which takes a source file and an optional destination file as arguments, if there is no destination file stipulated the destination file will be the name of the source file with the extension replaced with 'crn'. The output file will be the BASIC program in the source file with each line numbered from 1 and all leading spaces, blank lines and REM only lines removed.

Feedback appreciated!

Example:

Code: Select all

REM ***********************************
REM *         BASIC ROGUE            *
REM *                                 *
REM *        A ROGUELIKE GAME         *
REM *    FOR THE BBC MICRO COMPUTER   *
REM *  WRITTEN ENTIRELY IN BBC BASIC  *
REM *        BY SIMON HOOPER          *
REM *                                 *
REM ***********************************

*FX119

MODE 128 : REM MODE 0 ON A BEEB, SHADOW MODE 0 ON A MASTER

IF PAGE<>&0E00 THEN PAGE=&1100

REM CREATE SPACE FOR MAP BELOW SCREEN MEMORY
HIMEM = HIMEM-2401
L%=HIMEM+1

REM USE PAGE &0A FOR MOSTER TABLE
M%=&A00

REM USE PAGE &0B FOR PLAYER ATTRIBUTES OR JUST USE VARIABLES
P%=&B00

REM OTHER TABLES AND VARIABLE MAY BE INITIALISED HERE
REM MUST USE 'RESIDENT' VARIABLES A%-Z% SO THEY WILL SURVIVE LOADING OTHER PARTS OF THE GAME

CHAIN "INTRO"



becomes:

Code: Select all

1*FX119
2MODE 128 : REM MODE 0 ON A BEEB, SHADOW MODE 0 ON A MASTER
3IF PAGE<>&0E00 THEN PAGE=&1100
4HIMEM = HIMEM-2401
5L%=HIMEM+1
6M%=&A00
7P%=&B00
8CHAIN "INTRO"
Attachments
beebcrunch.zip
(17.51 KiB) Downloaded 4 times

User avatar
Rich Talbot-Watkins
Posts: 1110
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: BASIC cruncher for PC

Postby Rich Talbot-Watkins » Fri Sep 29, 2017 8:11 am

Crunching is also a good way to slightly improve the performance of a BASIC program! When you get to shortening variable names, remember that variables are held in linked lists, one per start character. So for best performance, try to distribute the new names evenly across all start characters (e.g. go with a%, b$, c rather than a%, a$, a). For FN/PROCs there's no such advantage, but you can at least just try to keep the name as short as possible (remembering that _ and £ are also both valid identifiers in BBC BASIC).

Another thing you can do, where possible, is pack statements onto one line with colons. Some statements (like DEF PROC, IF and REPEAT) don't even need a colon afterwards.

You can replace -1 with TRUE for a small gain in memory and performance, and combine lists of 8 bit constants in VDU statements with their 16 bit equivalents (e.g. VDU28,0,15,39,0 can become VDU28;9999;0).

More tricky to spot, but also worthwhile, is to strip the brackets from function calls which don't need them, e.g. SIN(X) becomes SINX (but beware that you don't change SIN(X/2) to SINX/2!)

Maybe there's a few ideas you can use there!

User avatar
lurkio
Posts: 1245
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: BASIC cruncher for PC

Postby lurkio » Fri Sep 29, 2017 12:59 pm

I've often thought that a BASIC-Cruncher that runs on modern platforms might be useful.

In addition to Rich's suggestions, I'd just say that replacing any integer var that has a long name (e.g. counter%) with one of the unused resident integer variables (A%-Z%) could save user memory (because of the shorter name and because the values in A%-Z% are stored somewhere below PAGE -- I forget exactly where). I think this is done by the Pack routine in the PRES Advanced BASIC Editor ROMs, which also does a number of other useful optimisations.

Also, this is a possibly whacky idea, but would there be any value in the Cruncher utility being able to take labels and convert them to line-numbers? So then you could write your BBC BASIC program in a text editor or other IDE on a modern OS, without using line-numbers, but using labels like ":initialisation_routine" instead, and the Cruncher could then convert the labels to line-numbers while it numbers the whole program? I'm thinking that you could then GOTO labels instead of calling PROCs/FNs.* Would this save memory at all? But if so, would it also hit performance?

:?:

* Obviously GOTOs are considered harmful, etc., but I'm thinking solely of saving precious RAM here. (And anyway, the program, as it appears in the source file, pre-crunching, would still be "structured".)

User avatar
sydney
Posts: 1979
Joined: Wed May 18, 2005 9:09 am
Location: Newcastle upon Tyne

Re: BASIC cruncher for PC

Postby sydney » Fri Sep 29, 2017 2:00 pm

lurkio wrote:In addition to Rich's suggestions, I'd just say that replacing any integer var that has a long name (e.g. counter%) with one of the unused resident integer variables (A%-Z%) could save user memory (because of the shorter name and because the values in A%-Z% are stored somewhere below PAGE -- I forget exactly where).


This would be possible but may cause problems if the resident variables were already in use. I'd probably have to process the whole file in several passes to ensure this was taken account of which is very different to the line by line approach I'm using at the moment.

Also, this is a possibly whacky idea, but would there be any value in the Cruncher utility being able to take labels and convert them to line-numbers? So then you could write your BBC BASIC program in a text editor or other IDE on a modern OS, without using line-numbers, but using labels like ":initialisation_routine" instead, and the Cruncher could then convert the labels to line-numbers while it numbers the whole program? I'm thinking that you could then GOTO labels instead of calling PROCs/FNs.* Would this save memory at all? But if so, would it also hit performance?


This is an idea I'd also had so if it's something you'd use I'd be willing to have a bash at it later tonight - I've got a pretty good idea how to do it and it shouldn't take long.

User avatar
Rich Talbot-Watkins
Posts: 1110
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: BASIC cruncher for PC

Postby Rich Talbot-Watkins » Fri Sep 29, 2017 2:30 pm

Don't use GOTO/GOSUBs instead of PROCs/FNs!!!! Please, for the love of humanity, please no!!!!

</melodramatic>

(Yes, it will potentially affect performance too: a cached PROC should be found more quickly than a GOTO a high line number. But also, parameter passing and all that!)

User avatar
lurkio
Posts: 1245
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: BASIC cruncher for PC

Postby lurkio » Fri Sep 29, 2017 5:40 pm

sydney wrote:
Also, this is a possibly whacky idea, but would there be any value in the Cruncher utility being able to take labels and convert them to line-numbers? So then you could write your BBC BASIC program in a text editor or other IDE on a modern OS, without using line-numbers, but using labels like ":initialisation_routine" instead, and the Cruncher could then convert the labels to line-numbers while it numbers the whole program? I'm thinking that you could then GOTO labels instead of calling PROCs/FNs.* Would this save memory at all? But if so, would it also hit performance?

This is an idea I'd also had so if it's something you'd use I'd be willing to have a bash at it later tonight - I've got a pretty good idea how to do it and it shouldn't take long.

Yes, I'd be interested in seeing you update the Cruncher so that it lets you GOTO/GOSUB to labels.

Obviously it's generally not good programming practice to eschew functions for GOTOs -- and parameters for global vars -- but, hey, we're trying to save every last byte here, after all. And we're already obfuscating the code as a side-effect of compressing it by shortening variable names and removing spaces, etc., so why not go the whole hog..?

Plus, it'd really wind Rich up!

:wink:

dp11
Posts: 682
Joined: Sun Aug 12, 2012 8:47 pm

Re: BASIC cruncher for PC

Postby dp11 » Fri Sep 29, 2017 6:44 pm

For tips on possible things that could be done see !StrongBS by Mohsen Alshayef. This is for riscos , but would give clues to lots of things that could be done.

User avatar
sydney
Posts: 1979
Joined: Wed May 18, 2005 9:09 am
Location: Newcastle upon Tyne

Re: BASIC cruncher for PC

Postby sydney » Fri Sep 29, 2017 6:47 pm

First attempt at GOTO didn't work. I'm going to have to do at least another pass through the program to find all the labels before I can correctly add the GOTO's. Obvious when you really think about it. Putting the kids to bed soon then I'll have another look at it.

Richard Russell
Posts: 167
Joined: Sun Feb 27, 2011 10:35 am

Re: BASIC cruncher for PC

Postby Richard Russell » Fri Sep 29, 2017 7:00 pm

sydney wrote:It's written in FreeBASIC so it should compile and work on any system FreeBASIC is available on which is linux,Windows,OSX and I think android.

What a shame it's not written in BBC BASIC! I would have thought that was the 'obvious' choice, and of course it's also available on Windows, Linux (including Raspberry Pi), Mac OS and Android.

I should perhaps mention that the cruncher built into 'BBC BASIC for Windows' will do a pretty thorough job, for example it concatenates multiple short lines into long lines and replaces variable and PROC/FN names etc with short forms. However it aggressively removes unnecessary spaces and as a result the crunched program cannot always be edited; that can be an issue for some uses.

This is what the BB4W cruncher makes of your test program:

Code: Select all

      *FX119
      MODE128:IFPAGE<>&0E00THENPAGE=&1100
      HIMEM=HIMEM-2401:L%=HIMEM+1:M%=&A00:P%=&B00:CHAIN"INTRO"

Richard.

User avatar
lurkio
Posts: 1245
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: BASIC cruncher for PC

Postby lurkio » Fri Sep 29, 2017 7:24 pm

Richard Russell wrote:This is what the BB4W cruncher makes of your test program:

Code: Select all

      *FX119
      MODE128:IFPAGE<>&0E00THENPAGE=&1100
      HIMEM=HIMEM-2401:L%=HIMEM+1:M%=&A00:P%=&B00:CHAIN"INTRO"

Incidentally, that's exactly the same as the output of the Pack routine in the PRES Advanced BASIC Editor ROMs.

:idea:

User avatar
sydney
Posts: 1979
Joined: Wed May 18, 2005 9:09 am
Location: Newcastle upon Tyne

Re: BASIC cruncher for PC

Postby sydney » Fri Sep 29, 2017 7:46 pm

Richard Russell wrote:What a shame it's not written in BBC BASIC! I would have thought that was the 'obvious' choice, and of course it's also available on Windows, Linux (including Raspberry Pi), Mac OS and Android.

I should perhaps mention that the cruncher built into 'BBC BASIC for Windows' will do a pretty thorough job, for example it concatenates multiple short lines into long lines and replaces variable and PROC/FN names etc with short forms. However it aggressively removes unnecessary spaces and as a result the crunched program cannot always be edited; that can be an issue for some uses.


I've tried BBC BASIC (bbcsdl) before and didn't like either of the ide's, I prefer to use geany. Also I didn't seem able to compile my program as the compile option was greyed out so I'd not be able to run my program from a command line in the way I want. FreeBASIC worked exactly the way I wanted and was the first result when I googled "basic compiler linux".

While I agree BBC BASIC may be the obvious choice it didn't seem to meet my needs and I was already familiar with FreeBASIC.

Richard Russell
Posts: 167
Joined: Sun Feb 27, 2011 10:35 am

Re: BASIC cruncher for PC

Postby Richard Russell » Fri Sep 29, 2017 8:34 pm

sydney wrote:I've tried BBC BASIC (bbcsdl) before and didn't like either of the ide's

People's taste in IDEs differ, so it's impossible to please everybody. That's one of the main reasons why the BBCSDL IDEs are themselves written in BBC BASIC, making it relatively straightforward to customise them to suit individual preferences. I deliberately made SDLIDE as similar as possible to the BB4W IDE, since a lot of people using BBCSDL will be familiar with that.

Anyway I don't want to hijack this thread. You can discuss the IDEs and other features of BB4W and/or BBCSDL at the relevant forums.

Richard.

User avatar
jgharston
Posts: 2729
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: BASIC cruncher for PC

Postby jgharston » Sat Sep 30, 2017 4:40 am

Before crunching variables, the following can be programatically crunched (link).

Firstly, the following must not be crunched:
* constant strings, so:
a$="hello world"
does not becomes, eg:
a$="helloworld"
* *commands, so
*KEY 2 Hello world
does not become, eg:
*KEY2HelloWord

The following can all be crunched:
* all REMs, so:
PRINT "Hello":REM print something
becomes:
PRINT "Hello":
(note, that colon will be swallowed later)
* all assember \ or ; comments, so:
LDA #ASC"*":JSR OSWRCH:\ Print something
becomes
LDA #ASC"*":JSR OSWRCH:
* all empty lines, (unless the target of a GOTO/GOSUB/RESTORE) so
PRINT "Hello"

PRINT "world"
becomes
PRINT "Hello"
PRINT "world"
* all superflous colons, so
A%=5::PRINT "Hello":
becomes
A%=5:PRINT "Hello"
* all spaces before and after tokens, so
IF ASC A$=45 THEN PRINT "Hi" ELSE PRINT "bye"
becomes
IFASCA$=45THENPRINT"Hi"ELSEPRINT"bye"
* all spaces before and after statements, so
a=6 : b=7 : c=8
becomes
a=6:b=7:c=8

My *CRUNCH doesn't do this, and I haven't run through it mentally to check, but all spaces before and after arithmetic operators and brackets, so:
a = 6 + jim * 2 - 6 * ( fred > 7 )
becomes
a=6+jim*2-6*(fred>7)

When you start crunching further than this you have to be careful to avoid changing the semantics of the program, particularly if sloppy coding has been used. For instance, removing spaces from:
IF A% !112=0:PRINT "Hello"
gives
IFA%!112=0:PRINT"Hello"
which changes it from 'if A% then !112=0....' to 'if A%!112=0 then....'

Somewhere I've got the BASIC equivalent of *CRUNCH, but the source to *CRUNCH is here which should be commented enough to explain what it's doing.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

crj
Posts: 237
Joined: Thu May 02, 2013 4:58 pm

Re: BASIC cruncher for PC

Postby crj » Sat Sep 30, 2017 6:15 am

I guess one big, huge, glaring question to ask in crunching BASIC programs is: does the EVAL token occur anywhere?

If not, you've got a lot more latitude to shrink variable and function names. If you're really keen, run through the program finding all the names and their frequencies, then Huffman code everything except @% A% X% Y% C% P% O%.

Richard Russell
Posts: 167
Joined: Sun Feb 27, 2011 10:35 am

Re: BASIC cruncher for PC

Postby Richard Russell » Sat Sep 30, 2017 9:38 am

jgharston wrote:My *CRUNCH doesn't do this, and I haven't run through it mentally to check, but all spaces before and after arithmetic operators and brackets

The rules for removing spaces are complicated, as I've found to my cost (it took years for the edge-cases to be discovered and fixed in BB4W; as far as I know it's right now). But the first thing you need to ask yourself is whether you want the crunched program to be editable (by which I mean convertible from tokenised format to ASCII and back to tokenised format whist surviving intact). If not, then you can be more aggressive with space removal: the BB4W cruncher works this way because it's only used when building standalone executables. Otherwise some spaces must be retained to allow correct tokenisation even if they aren't needed at run-time.

Richard.

Richard Russell
Posts: 167
Joined: Sun Feb 27, 2011 10:35 am

Re: BASIC cruncher for PC

Postby Richard Russell » Sat Sep 30, 2017 9:47 am

crj wrote:I guess one big, huge, glaring question to ask in crunching BASIC programs is: does the EVAL token occur anywhere? If not, you've got a lot more latitude to shrink variable and function names.

Leaving all variable/function names intact just because there's a single EVAL in the program is rather drastic, and can hit performance. The way I tackled this in BBC BASIC for Windows was by introducing the REM!Keep compiler directive which allows the programmer to specify which (usually few) variables must not be crunched:

Code: Select all

      REM!Keep myvar$, DontCrunch%, FNinput, PROC_locate()

Richard.

User avatar
jgharston
Posts: 2729
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: BASIC cruncher for PC

Postby jgharston » Sat Sep 30, 2017 6:57 pm

Richard Russell wrote:
jgharston wrote:My *CRUNCH doesn't do this, and I haven't run through it mentally to check, but all spaces before and after arithmetic operators and brackets

The rules for removing spaces are complicated, as I've found to my cost (it took years for the edge-cases to be discovered and fixed in BB4W; as far as I know it's right now). But the first thing you need to ask yourself is whether you want the crunched program to be editable (by which I mean convertible from tokenised format to ASCII and back to tokenised format whist surviving intact).

Which is why my documentation says:
Note that crunching a program can make it completely uneditable, so you
should save the resulting program as a different file to the source
code.

Ah, the memories of trying to fix a crunched broken program with no access to the uncrunched version... :?

I've found that my *Crunch is "good enough" for most cases. I've never been in the habit of writing a = b + c * d so it slipped my mind to make it strip those spaces, I really should update it to catch those. And even without scrunching variable names it's good enough to get from this to this and makes writing the "source" a lot easier.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

Richard Russell
Posts: 167
Joined: Sun Feb 27, 2011 10:35 am

Re: BASIC cruncher for PC

Postby Richard Russell » Sat Sep 30, 2017 8:57 pm

jgharston wrote:Ah, the memories of trying to fix a crunched broken program with no access to the uncrunched version...

For amusement, here's a snippet from 'lblib.bbcc', the crunched library used by LBB. It includes an example of one of the tricky cases: a space between '6' and 'E' being retained because otherwise it would be read as a numeric constant in scientific notation!

Code: Select all

      DEFPROC_statictext(RETURNR%,RETURNE%,`$,X%,Y%,W%,V%)LOCALS%,@$(0),G%,Z%,F%,_$:@$(2)="Static":@$(3)=BackgroundColor$
      IFR%=FALSER%=FN6:E%=FALSE
      IF!R%>1ENDPROC
      LOCALI%,!(^@{}+4):I%=R%:IF!E%<>1ORE%!56 E%=FN6:!E%=1ELSEWHILEI%!72<>E%I%=I%!72:ENDWHILE:I%!72=E%!72
      WHILEI%!72 I%=I%!72:ENDWHILE:I%!72=E%:E%!72=FALSE:!(^@{}+4)=E%:I%=@.2&*256+@.1&:IFI%ELSEy%+=1:I%=y%:@.1&=I%:@.2&=I%>>8
      H$(I%)=@$(0):Y%(I%,FALSE)=F%:Y%(I%,1)=G%:CASE@$(2)OF
        WHEN"ComboBox":@.B%=F%:Y%(I%,FALSE)=FALSE
        WHEN"ListBox":@.B%=F%:Y%(I%,FALSE)=FALSE:Y%(I%,1)=FALSE:Y%(I%,2)=G%
        WHEN"Button":IFINSTR(FN_lower$(@$(0)),".default")S%OR=1
          IFS%AND&80THEN
            LOCALH%,`{}:DIM`{T%,W%,H%,B%,P%,M%}:H%=FN_loadbmp(`$):IFH%=FALSE@$(1)=`$:RESTORELOCAL:DIMS%LOCALTRUE:PROC3(S%,102,"Couldn't load bitmap file "+@$(1))
            SYSq%,H%,DIM(`{}),`{}:W%=`.W%+2:V%=`.H%+2:@.B%=H%:`$=""
          ENDIF
        WHEN"LBBEDIT":IFFN_menu(R%,"EDIT")
          @.4&=1
      ENDCASE:CASEFN_upper$(_$)OF
        WHEN"UR":Z%OR=&10000000:IF(S%AND&80)=FALSEX%-=&B
        WHEN"LL":Z%OR=&20000000:IF(S%AND&80)=FALSEY%+=&FELSEY%+=26
        WHEN"LR":Z%OR=&30000000:X%+=26:Y%+=26
      ENDCASE:IF@$(3)<>""@.K%=FN2(@$(3))ELSE@.K%=TRUE
      S%OR=&50000000:IF@.Z%AND2 Z%AND=NOT&200
      @.S%OR=S%:@.Z%OR=Z%:@.X%=X%:@.Y%=Y%:@.W%=W%:@.V%=V%:@.1$=@$(2):@.2$=`$:ENDPROC

Richard.

User avatar
sweh
Posts: 1845
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: BASIC cruncher for PC

Postby sweh » Sun Oct 01, 2017 12:33 am

sydney wrote:I'm developing it in linux using a text editor[...]I need a way to automatically number the program.

You might have the 'nl' command available:

Code: Select all

$ cat x
hello
there
everyone
$ nl x
     1  hello
     2  there
     3  everyone


If that doesn't exist then a simple AWK command will work:

Code: Select all

$ awk '{print NR,$0}' x
1 hello
2 there
3 everyone
Rgds
Stephen

User avatar
jgharston
Posts: 2729
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: BASIC cruncher for PC

Postby jgharston » Sun Oct 01, 2017 1:11 am

Richard Russell wrote:
jgharston wrote:Ah, the memories of trying to fix a crunched broken program with no access to the uncrunched version...
For amusement, here's a snippet from 'lblib.bbcc', the crunched library used by LBB. It includes an example of one of the tricky cases: a space between '6' and 'E' being retained because otherwise it would be read as a numeric constant in scientific notation!

Yes, that was one particularly annoying bug that my CSV writing code fell over on. Census Household Identifier 64E12 was read by Excel and displayed as 64 billion. I could have used the simplest solution of outputting everything as ="blah" but I was aiming to make the output file as compact as possible.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
lurkio
Posts: 1245
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: BASIC cruncher for PC

Postby lurkio » Sun Oct 01, 2017 6:12 pm

jgharston wrote:... For instance, removing spaces from:
IF A% !112=0:PRINT "Hello"
gives
IFA%!112=0:PRINT"Hello"
which changes it from 'if A% then !112=0....' to 'if A%!112=0 then....'

I seem to recall -- from bitter experience -- that that's the (one and only?) set of circumstances in which the Pack routine in the PRES Advanced BASIC Editor falls over.

:idea:

User avatar
sydney
Posts: 1979
Joined: Wed May 18, 2005 9:09 am
Location: Newcastle upon Tyne

Re: BASIC cruncher for PC

Postby sydney » Mon Oct 09, 2017 2:52 pm

sweh wrote:
sydney wrote:I'm developing it in linux using a text editor[...]I need a way to automatically number the program.

You might have the 'nl' command available:

Code: Select all

$ cat x
hello
there
everyone
$ nl x
     1  hello
     2  there
     3  everyone


If that doesn't exist then a simple AWK command will work:

Code: Select all

$ awk '{print NR,$0}' x
1 hello
2 there
3 everyone


I tried 'nl' but couldn't get the formatting right, beebem didn't like the spaces. I'd read about 'awk' but I'm not familiar with it and I'd already got it working with a simple bash script.

crj
Posts: 237
Joined: Thu May 02, 2013 4:58 pm

Re: BASIC cruncher for PC

Postby crj » Tue Oct 10, 2017 12:47 am

Code: Select all

nl -ba -v10 -i10 -s' ' -w1

...is probably a better nl rune for giving a BASIC program line numbers: number even blank lines, start at 10, step by 10, space after the line number, nothing before it.


Return to “development tools”

Who is online

Users browsing this forum: No registered users and 1 guest