6502 BASIC Compiler

Discuss all aspects of programming here. From 8-bit through to modern architectures.
User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

6502 BASIC Compiler

Postby Elminster » Tue May 30, 2017 9:22 am

In this topic I was thinking about adv basic for 6502. This has lead me to think about BASIC compilers.

I have dug up the manual for the ABC BASIC Compiler (the one by Paul Fellows and later published by OAK and then Castle).

There is a lot of back and forth about whether a BASIC Compiler is a good idea (then and now), due to forcing you down certain programming styles. But I am wondering if this is such an issue with the Beeb as it would be with RISC OS. I.e. Generally no windows or mouse to worry about (apart from specific use cases like gfx programs etc), less BASIC commands to use (even adv. BASIC is missing a few RISC OS BASIC 5 features) and due to memory the programs are smaller (although that could also work the other way, I.e. Lots of strange things done, due to low memory, that Acorn never envisioned).

And I see potentially one extra advantage of doing it on the Beeb. If you use Adv BASIC (BASIC 5ish) it only runs on 65c102 co pro, so you get all those lovely extra feature, but you can (back in the day anyway, before pitube direct!) only run on a Master with a 2nd processor, which would have been expensive. Edit: (forgot to put in advantages). You could potentially compile out BASIC V to assembly that would run on a BASIC II Beeb or Electron. Assume you would need to do something clever with ABC distribution library to achieve this.

Not sure even if the source was available anyone with take on the job of converting ARM version of BASIC V Compiler to 6502 (would need to know BASIC, 6502, ARM, compilers, interpreters all inside out. Not to mention lots of spare time) but interesting idea.
Last edited by Elminster on Tue May 30, 2017 8:38 pm, edited 1 time in total.

User avatar
tricky
Posts: 1921
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: 6502 BASIC Compiler

Postby tricky » Tue May 30, 2017 11:31 am

There have been several discussions about this and I seem to remember that EVAL was the hardest thing to do (I don't know if it is even in your basic).
There were some hacks for basic2 to call functions by name, again, probably not suitable.
Is the goal to get a faster basic or a more fully featured one?
If faster, maybe the tokenizing/execution could be targeted instead?

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: 6502 BASIC Compiler

Postby Elminster » Tue May 30, 2017 12:00 pm

Yes eval is an issue, and other things like closing 2 For with one Next. And a raft of other stuff. I must admit a lot of the examples I don't even understand what they do, let alone use them in my own programs.

I think it would be 3 reasons, the two original reason for ARM, and one new one for 6502:
- Compiler validates your code, helping correct bugs
- code is smaller, and may run faster (I.e. Are case where runs slower)
- write basic V code that runs on unexpanded beeb, Electron

Is the goal to get a faster basic or a more fully featured one?
If faster, maybe the tokenizing/execution could be targeted instead?


Yes all those :) did you have a particular program in mind, or just that a tokeniser is an easier project?
Last edited by Elminster on Tue May 30, 2017 12:03 pm, edited 1 time in total.

cmorley
Posts: 263
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford

Re: 6502 BASIC Compiler

Postby cmorley » Tue May 30, 2017 12:03 pm

BASIC on the Acorn 8 bit computers essentially runs on a virtual machine (abstracted 32bit integers and 5 byte floating point IIRC). VMs have a major advantage of reducing code size at the expense of speed. Good examples are Steve Woz's Sweet 16 and the Zork VM (many online references for both of these). So compiling BASIC to 6502 code would likely use more program memory.

e.g.

Code: Select all

10A%=B%+C%*D%

This entire program comes in at 18 bytes (quick count with Exmon). But there is no way you can do that in 18 bytes with 32bit integers in 6502 asm.

So on an Arc with lots of memory that isn't an issue. Take the speed increase of no VM. But on a B (or Master) code size could be a problem.

What kills BASIC programs is bloat... long variable names... unnecessary whitespace... line overhead... and at runtime orphaned variable which get used once and eat space forever.

What would be of more use for the 8-bit BASIC machines is a smart minifier. You can leave REMs and comments in the code then. Pretty print it with whitespace and few statements per line. Then crunch it. It could even have an SSA variable assigner to cram almost every variable into A%-Z% and A-Z. Minified code runs quicker because the interpreter has less work to do. Dead code elimination... constant sub expression elimination... hoisting.. strength reduction... the list of features that could be added is _long_!

So I'd suggest compile BASIC to... er... BASIC.

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: 6502 BASIC Compiler

Postby Elminster » Tue May 30, 2017 12:06 pm

Yes but that miss my main point. I am talking about using BASIC V on a non 65c02. Size, speed, code validation are just secondary features, that were the main ones for ARM.

I.e. Compile BASIC 5 to BASIC 2 is also going to be bigger. Or using a multistage basic 5 IF, where if converted to basic 2 would blow the line length.

P.s. You can of course port BASIC 5 to Beeb but that is another idea for another thread.

cmorley
Posts: 263
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford

Re: 6502 BASIC Compiler

Postby cmorley » Tue May 30, 2017 12:13 pm

Once you've tokenised BASIC V and created an AST you can emit it as BASIC II with any line length. Line numbers would not be preserved... off the top of my head BASIC2 has a 240 char line length limit? You can emit procedure/function calls for the BASIC V functions which don't exist in 2 to implement them (from a library).

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: 6502 BASIC Compiler

Postby Elminster » Tue May 30, 2017 12:24 pm

But the if would break the line and the code.

E.g. BASIC V

If blah then
Statement 1
Statement 2
...
Statement n
Else
Statement 1
Statement 2
...
Statement y
Endif

In basic 2 you would have to do that all one one line.

Just one example, and you could program around it, but wondering if it would be better to convert that straight into Asm rather than try to get it to work in BASIC2.

Same for while and case.

(This all some about really from looking for an interesting way to use if,while and case in basic but able to run it on other beebs.) [cross compiling in C is going to be easier but this just peaked my interest]

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: 6502 BASIC Compiler

Postby Elminster » Tue May 30, 2017 12:35 pm

cmorley wrote:What would be of more use for the 8-bit BASIC machines is a smart minifier. You can leave REMs and comments in the code then. Pretty print it with whitespace and few statements per line. Then crunch it. It could even have an SSA variable assigner to cram almost every variable into A%-Z% and A-Z. Minified code runs quicker because the interpreter has less work to do. Dead code elimination... constant sub expression elimination... hoisting.. strength reduction... the list of features that could be added is _long_!.


Also packers breifly in this post viewtopic.php?f=55&t=13129

Be interesting to do a B5 to B2 tokeniser (with packing) and a Compiler. Somehow probably unlikely one with get done let along both. A pity that basic V isn't in mainstream Beeb (as a 2 x 16k rom), rather than going down the 6502 copro adv basic, or the micro power basic extension rom.

Edit: I remember doing a Compiler and interpreter module at uni nearly 25 years ago, remember virtually nothing except it was the hard module out of everything. Made Z, COBOL(although the dot in column 8 used to get me every time) and lisp fun modules by comparison.

cmorley
Posts: 263
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford

Re: 6502 BASIC Compiler

Postby cmorley » Tue May 30, 2017 1:44 pm

In your example you could emit the IF as an IF with GOTOs (or GOSUBs/PROCs)

e.g.

Code: Select all

10 IF NOT blah GOTO x
20+ huge amount of stuff over multiple lines for true
...
"x-10" GOTO y
"x"+ huge amount of stuff over multiple lines for false
...
"y"

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: 6502 BASIC Compiler

Postby Elminster » Tue May 30, 2017 1:52 pm

cmorley wrote:In your example you could emit the IF as an IF with GOTOs (or GOSUBs/PROCs)

e.g.

Code: Select all

10 IF NOT blah GOTO x
20+ huge amount of stuff over multiple lines for true
...
"x-10" GOTO y
"x"+ huge amount of stuff over multiple lines for false
...
"y"


Don't use them. Defeats the point of going to a more structured basic if you are then going to use Gotos. Yes I know you are going to argue that this is not the source code so gotos should be allowed. But turns my stomach.

Edit: I always set an elseif flag rather than use a goto. Regardless as an academic exercise it would be interesting to do both.
Last edited by Elminster on Tue May 30, 2017 2:04 pm, edited 2 times in total.

cmorley
Posts: 263
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford

Re: 6502 BASIC Compiler

Postby cmorley » Tue May 30, 2017 2:02 pm

Elminster wrote:Don't use them. Defeats the point of going to a more structured basic if you are then going to use Gotos. Yes I know you are going to argue that this is not the source code so gotos should be allowed. But turns my stomach.


The conversion would be done by the compiler/minifier, you would not have GOTOs in your BASIC V source. It is the same as a compiler emitting JMP assembler statements for example. The code generator must preserve the structure of the original BASIC V program.

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: 6502 BASIC Compiler

Postby Elminster » Tue May 30, 2017 2:04 pm

cmorley wrote:
Elminster wrote:Don't use them. Defeats the point of going to a more structured basic if you are then going to use Gotos. Yes I know you are going to argue that this is not the source code so gotos should be allowed. But turns my stomach.


The conversion would be done by the compiler/minifier, you would not have GOTOs in your BASIC V source. It is the same as a compiler emitting JMP assembler statements for example. The code generator must preserve the structure of the original BASIC V program.


That is what I said you would say :)

Still want to see a Compiler though, not a case of being good or bad. Just want one because it could be done.

cmorley
Posts: 263
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford

Re: 6502 BASIC Compiler

Postby cmorley » Tue May 30, 2017 2:24 pm

2/3 of the work would be the same between an AST minifier and a compiler. You just have separate modules for the code emit. One to 6502 asm and one to BASIC 2.

Or indeed a BASIC V front end for GCC then?

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: 6502 BASIC Compiler

Postby Elminster » Tue May 30, 2017 2:55 pm

All interesting ideas. Not thought of a BASIC to C 6502 cross Compiler.

If I already had all the skills I might have a go at one or more of the ideas. but by the time I had done something to make it portable basic 5 (maybe faster, maybe smaller) a reality I would have forgotten why I wanted to do it in the first place.

End of the day would probably be easier just to help get the gcc6 cross Compiler working nicely. And then have all the features of basic v and more. But C isn't very retro Beeb, seems like cheating.

Edit: trouble with the Beeb is you start off just doing a simple BASIC program and get distracted into re-writing half the language and tools. Or is that the fun bit?

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

Re: 6502 BASIC Compiler

Postby jgharston » Tue May 30, 2017 7:24 pm

cmorley wrote:What would be of more use for the 8-bit BASIC machines is a smart minifier. You can leave REMs and comments in the code then. Pretty print it with whitespace and few statements per line. Then crunch it. It could even have an SSA variable assigner to cram almost every variable into A%-Z% and A-Z. Minified code runs quicker because the interpreter has less work to do. Dead code elimination... constant sub expression elimination... hoisting.. strength reduction... the list of features that could be added is _long_!
That's what I wrote my LINK and CRUNCH utilties for. LINK removes unused code, CRUNCH removes un-needed fluff such as comments, empty lines, superflous spaces, etc. That lets me write my "source" with high verbosity and "compile" it to a packed "executable".

Code: Select all

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

cmorley
Posts: 263
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford

Re: 6502 BASIC Compiler

Postby cmorley » Tue May 30, 2017 7:31 pm

jgharston wrote:That's what I wrote my LINK and CRUNCH utilties for. LINK removes unused code, CRUNCH removes un-needed fluff such as comments, empty lines, superflous spaces, etc. That lets me write my "source" with high verbosity and "compile" it to a packed "executable".

Cool. Google found me the *. thread. Sounds excellent I will take a look.

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: 6502 BASIC Compiler

Postby Elminster » Tue May 30, 2017 7:34 pm

Elminster wrote:Also packers briefly in this post viewtopic.php?f=55&t=13129


I already mentioend it above. Or at least to where it was mentioned in the other thread. Has all the links in there.

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: 6502 BASIC Compiler

Postby Elminster » Tue May 30, 2017 7:38 pm

jgharston wrote:
cmorley wrote:What would be of more use for the 8-bit BASIC machines is a smart minifier. You can leave REMs and comments in the code then. Pretty print it with whitespace and few statements per line. Then crunch it. It could even have an SSA variable assigner to cram almost every variable into A%-Z% and A-Z. Minified code runs quicker because the interpreter has less work to do. Dead code elimination... constant sub expression elimination... hoisting.. strength reduction... the list of features that could be added is _long_!
That's what I wrote my LINK and CRUNCH utilties for. LINK removes unused code, CRUNCH removes un-needed fluff such as comments, empty lines, superflous spaces, etc. That lets me write my "source" with high verbosity and "compile" it to a packed "executable".


I am assuming that as you didnt write a compiler you are in the, isnt worth the effort camp? How about the Tokenizer Basic V to Basic 2 suggestion?

I already plan to Crunch/link the code using your utils. Not tried yet.

SteveBagley
Posts: 129
Joined: Sun Mar 15, 2015 8:44 pm

Re: 6502 BASIC Compiler

Postby SteveBagley » Wed May 31, 2017 10:20 am

cmorley wrote:BASIC on the Acorn 8 bit computers essentially runs on a virtual machine (abstracted 32bit integers and 5 byte floating point IIRC). VMs have a major advantage of reducing code size at the expense of speed. Good examples are Steve Woz's Sweet 16 and the Zork VM (many online references for both of these). So compiling BASIC to 6502 code would likely use more program memory.

e.g.

Code: Select all

10A%=B%+C%*D%

This entire program comes in at 18 bytes (quick count with Exmon). But there is no way you can do that in 18 bytes with 32bit integers in 6502 asm.


If you wrote a threaded code compiler (as, if I remember correct, at least one of the BASIC compilers did on the Arc) the code bloat wouldn't be that great over a typical program, i.e. the above would become

Code: Select all

JSR pushD%
JSR pushC%
JSR mulINT
JSR pushB%
JSR add
JSR popA%


which would be… 18 bytes :) Of course, you also need to factor in the code to implement all the subroutines but this would get amortised over a longer program.

Steve

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: 6502 BASIC Compiler

Postby Elminster » Wed May 31, 2017 11:15 am

SteveBagley wrote:
If you wrote a threaded code compiler (as, if I remember correct, at least one of the BASIC compilers did on the Arc)


Was there more than 1 Arc Compiler? I only found details about the ABC one, which was written by Paul Fellows and later owned by Oak and then Castle. Was there more?

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

Re: 6502 BASIC Compiler

Postby Rich Talbot-Watkins » Wed May 31, 2017 11:49 am

I think an important trick when compiling 6502 BBC BASIC is (if possible) to determine the size of variables by some kind of static analysis. If you can use 16-bit (or even 8-bit) values to replace integer variables, this is clearly a big performance and size improvement. So FOR loop variables can have their range determined pretty easily. Likewise, variables which are just used as booleans. There are more complex cases that could probably be proved by complex static analysis, but that's a difficult problem. You could provide directives to the compiler through REM statements specifying concrete types for variables, where it's difficult to deduce.

I wouldn't necessarily generate pure threaded code (a stream of JSRs); small operations could easily be inlined. Also a peephole optimization pass to remove pops with an adjacent push.

I think a bytecode interpreter approach is another option for speeding up BASIC. I think there were BASIC interpreters which generated bytecode from the source code at the beginning of the RUN process (essentially identifying common variable/procedure names, and condensing it down into a single token, and preprocessing expressions into some kind of RPN form). I've wondered in the past if a replacement 6502 BASIC could do all that at line entry / tokenisation time (at the expense of potentially rearranging typed expressions when LISTed) - would give a big speed improvement, but I'm not sure how variable / PROC names would best be handled in this way.

A bytecode stream in its purest form would barely be different in performance to the threaded code example you gave above!

SteveBagley
Posts: 129
Joined: Sun Mar 15, 2015 8:44 pm

Re: 6502 BASIC Compiler

Postby SteveBagley » Wed May 31, 2017 1:43 pm

Elminster wrote:
SteveBagley wrote:
If you wrote a threaded code compiler (as, if I remember correct, at least one of the BASIC compilers did on the Arc)


Was there more than 1 Arc Compiler? I only found details about the ABC one, which was written by Paul Fellows and later owned by Oak and then Castle. Was there more?


I had a hooky copy of one when I was at school back in the nineties but I didn't think it was ABC… I think it may have been RiscBasic -- looking at the lists of old software

Steve

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: 6502 BASIC Compiler

Postby Elminster » Wed May 31, 2017 2:36 pm

Ah yes appears to be two compilers.

RISC basic was by Silicon Vision.

Once you know what you are looking for it is quite obvious. General feeling from posts is that risc basic was better than abc.

Edit: 3 if you call ABC and ABC2 different versions. Comparison article in acorn user issue 88.

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: 6502 BASIC Compiler

Postby Elminster » Thu Jun 01, 2017 12:43 am

So if I understand the article correctly the summary is.

- compiled code much faster unless float based
- Compiler code size much bigger ( ABC has runtime library, riscbasic adds to each program)
- restrictions on code, more so with ABC

They both support libraries, Like *link on mdfs, but requires ARX extension for ABC

I don't think the basic baseline is crunched/packed, that would have made it go faster I should think.

User avatar
ctr
Posts: 94
Joined: Wed Jul 16, 2014 2:53 pm

Re: 6502 BASIC Compiler

Postby ctr » Thu Jun 01, 2017 4:54 pm

Elminster wrote:So if I understand the article correctly the summary is.

- compiled code much faster unless float based
- Compiler code size much bigger ( ABC has runtime library, riscbasic adds to each program)
- restrictions on code, more so with ABC

They both support libraries, Like *link on mdfs, but requires ARX extension for ABC

I don't think the basic baseline is crunched/packed, that would have made it go faster I should think.


BBC BASIC permits some horrible code so I think restrictions are unavoidable if you want the compiled program to run quickly. For example, what does this produce?

Code: Select all

   10PROCa
   20PRINT"END"
   30END
   40DEFPROCa
   50PROCb
   60IFI%=1THENNEXT
   70PRINT"A"
   80DEFPROCb
   90FORI%=1TO5
  100PRINT;I%
  110ENDPROC


Anyway, to get a feel for the scale of this I made a brief overview of everything in BASIC 2. There's loads, though much of it is routine. It would be interesting to see an analysis of existing BBC BASIC code to see what features are used, how structured it is, how many distinct variables are used and so on.

Code: Select all

Pseudo variables and constants:

COUNT - the number of characters output by PRINT on the current line
ERL - last error line number
ERR - last error code
FALSE - 0
GET - read a character - OSRDCH
GET$ - CHR$(GET)
HIMEM - top of the stack (works down from here) - OSBYTE &84
LOMEM - start of variable allocation
PAGE - start of program - OSBYTE &83
PI
POS - horizontal cursor position - OSBYTE &86
RND - a random integer; can also have a parameter
TIME - OSWORD 1 (or OSWORD 2 for assignment)
TOP - the end of the program - tokenised as TO+"P".
TRUE - NOT FALSE
VPOS - vertical cursor position - OSBYTE &86

Pseudo-variables that can be assigned to:

HIMEM,LOMEM,PAGE,TIME,PTR#

Unary functions:

ABS float - absolute value
ACS float - arc-cosine in radians; -1<=n<=1 or "-ve root" error
ADVAL int - OSBYTE &80 return X+Y<<8
ASC string - ascii code of first character
ASN float - arc-sine in radians; -1<=n<=1 or "-ve root" error
ATN float - arc-tangent in radians
BGET# int - get byte from file - OSBGET
CHR$ int - make a single character string
COS float - cosine from angle in radians
DEG float - radians to degrees
EOF# int - have we reached the end of the file? - OSBYTE &7F
EVAL string - evaluate the string as a BASIC expression
EXP float - e^x
EXT# int - length of file - OSARGS 2
INKEY int - wait for key or test a key - OSBYTE &81
INKEY$ int - CHR$(INKEY)
INT float - floor function
LEN string - length of string
LN float - natural logarithm
LOG float - base 10 logarithm
NOT int - invert the bits
OPENIN string - open a file for input - OSFIND &40
OPENOUT string - open a file for output - OSFIND &80
OPENUP string - open a file for update - OSFIND &C0
PTR# int - file pointer - OSARGS 0 (or OSARGS 1 for assignment)
RAD float - degrees to radians
SGN float - sign of number (-1 or 0 or 1)
SIN float - sine from angle in radians
SQR float - square root
STR$ float - convert number to string using @%
TAN float - tangent from angle in radians
USR int - call machine code and return A,X,Y and PSR in 32-bit int
VAL string - parse a number

Other functions:

INSTR(string1,string2[,pos]) - position of string2 in string1 starting at pos or zero
LEFT$(string,len) - return up to n characters from the left of string
MID$(string,pos,len) - return a substring
POINT(int,int) - return the colour of the pixel - OSWORD 9
RIGHT$(string,len) - return up to n characters from the right of a string
STRING$(count,string) - concatenate n copies of the string

Integer binary operators:

AND - bitwise AND
DIV - integer division
EOR - bitwise EOR
MOD - integer modulus
OR - bitwise OR

Real binary operators:

+ - * / ^

+ and - also seem to have integer versions but not *, / and ^
+ also concatenates strings
- is also the negation operator

Indirection operators:

? - byte - can use ?n or M?n=?(M+n)
! - word - can use !n or M!n=!(M+n)
$ - string - terminates with &0D.

Statements:

BPUT# int,int - put byte to file - OSBPUT
CLG - clear graphics screen - VDU 16
CLOSE# int - close a file
CLS - clear text screen - VDU 12
COLOUR int - set the text colour - VDU17,n
DRAW int,int - VDU25,5,int;int;
END - terminate the program
ENVELOPE ints*14 - OSWORD 8
GCOL int, int - graphics colour - VDU 18,n,n
MODE int - VDU 22,n
MOVE int,int - VDU25,4,int;int;
OSCLI string - OSCLI
PLOT int,int,int - VDU25,int,int;int;
SOUND ints*4 - OSWORD 7
STOP - END with a line number message
WIDTH int - set page width - is this just a BASIC thing using COUNT?

Grammar words, control statements and weird syntax:

CALL - call machine code
CHAIN - this could be supported
CLEAR - delete all variables except @% to Z%
DATA - see READ and RESTORE
DEF - define PROC or FN
DIM - dimension an array OR reserve memory
ELSE - see IF, ON
ENDPROC
FN
FOR var=float TO float [STEP float]
GOSUB
GOTO
IF expr THEN stmt [ELSE stmt]
INPUT - see LINE, TAB and SPC
INPUT# int,varlist
LET - can't be used with pseudo-variables
LOCAL - see DEF
NEXT
ON n GOTO|GOSUB line,line,... [ELSE stmt]
ON ERROR GOTO|GOSUB line
OPT - and all the other assembler stuff
PRINT
PRINT#
PROC
READ - see DATA
REM
REPEAT
REPORT - print the last error
RESTORE - see DATA and READ
RETURN - from GOSUB
SPC int - see PRINT and INPUT
STEP - see FOR
TAB(int[,int]) - see PRINT and INPUT
THEN - see IF
TO - see FOR
TRACE - is this supportable?  Maybe a build flag?
UNTIL - see REPEAT
VDU - expressions followed by a semicolon are sent as 2 bytes - OSWRCH

Program management:

AUTO
DELETE
LIST
LISTO
LOAD
NEW
OLD
RENUMBER
RUN
SAVE

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: 6502 BASIC Compiler

Postby Elminster » Thu Jun 01, 2017 5:08 pm

I think it is more that it is hard to write structured programs in basic 2, by the time you get to 5 you need less 'tricks'. You can write horrid code in C but have the option to write 'good' code.

So being forced to write 'good' basic v so it could be compiled might be interesting

Of course the definition of good code is a bit subjective. My anti flame caveat.


Return to “programming”

Who is online

Users browsing this forum: No registered users and 1 guest