tinyPascal in BASIC

[voidstar]

This is still a work in progress, but I wanted to archive the work so far.

I came across a Tiny Pascal listing for the POLY88 system, using NorthStar BASIC. The listing is contained in a 42 page manual that describes the theory and operation (that manual is called "Byte Nybbles", I think affiliated with BYTE magazine). [ the code itself is only about 3 pages ]

The general gist is that this BASIC reads an input file, interprets the Pascal syntax, and generates "p-code" starting at a fixed address (I changed that address from $0000 to $2000).

From that, then there are two additional programs: #1) a "p-code emulator" that will interpret the "relocatable" p-code and do the operations in terms of BASIC. #2) another program that interprets the p-code and assembled it into 8080 instructions (this part corresponds to a "linker" to morph things into an actual executable).

We can use #1 to emulate and model what the generated code does, so that's convenient (we can test the "compiled results"). Then we refine #2 to make 6502 instructions instead.


Attached is a "sort of original" version of that code, now available as an ASCII text file. I took liberty of changing a few things:

- in NorthStar BASIC, comments were noted using \ instead of REM (so I changed the \'s to REM)
- NorthStar BASIC you could use ! (exclamation) to mean PRINT (many more modern BASICs used ? instead)
- NorthStar BASIC used the terms EXAM and FILL instead of PEEK and POKE.

Those are the easy differences. Then there are a few complicated differences:

- NorthStar uses a TRY(fn) call to detect the EOF. This is fairly easy, we can just do ST AND 64 instead.
- NorthStar has a much more sophisticated DEF FN capability. This is a little harder to "correct".
- NorthStar has some %4X type stuff in the PRINT, which I assume is a padding mechanism.

NorthStarBASIC has the same "two letter variable" limitation as many other early BASICs. But a neat thing about this Pascal compiler is you can define functions and variables with long names!


Regarding the DEF FN, I think we'll have to replace those with some GOSUB calls and just be careful about selecting some input/output variable conventions to those calls.

And this tinyPascal makes use of some multi-dimensional arrays. I think X16 BASIC will support that just fine.


I've got work and bouncing between other projects. But I think this tinyPascal is interesting since it does show the "rigor" of actually making a viable compiler, and done so from BASIC itself - it may not be a "great" Pascal compiler (limited functionality) but at least it can run on-system.

If anyone else gets time to "tear this apart" and update it to X16, I'm all for that. As I get time, I'm trying to adapt this over to BASLOAD, which I think in the long run would make it easier to expand on this (for example, I think it only supports the INTEGER type, so maybe we could add the REAL type).

[ahenry3068]

https://github.com/tangentstorm/tangent ... EMLINE.BAS

I've been looking at this to start Back Porting HANGMAN to BASLOAD. It might be useful to you for this as well. It should compile with QB64

REMLINE.BAS

(12.03 KiB) Downloaded 2989 times

I did peek at the source code. As its written it has a 400 line limit, But I think if you change that constant and compile it under QB64 it will handle a considerably larger number of lines. I think it was written originally for memory constraints under DOS. QB64 compiles native executables on Modern Linux and Windows. The memory constraints for all practical purposes should be non-existent. I was planning on changing the line limit to 9999 when I eventually compile it. You run out of memory before 6000 lines in CBM Basic anyway.

[voidstar]

I see, that's neat. I imagine it was useful during a migration from BASIC to QuickBASIC, exactly for this purpose of removing line numbers from long program.

I guess one approach I use for this is as follows:

Code: Select all

L10:FOR I = 1 TO 10
L20:  PRINT "HELLO ";I
L30:NEXT I
L40:GOTO L10

You can prefix your line numbers with Lnn and add a colon. So it "looks like regular BASIC" and BASLOAD will load it up just fine. Obviously for an existing very long program, it's tedious. But the thing is, you probably only GOTO/GOSUB to a relatively few places - you just "Add L-labels" to those lines and start removing all the rest.

Other approach is you can toss the file into Excel, and a little script to just remove the first character up to space (obviously only works if you did put a space after line numbers).

I thought QBASIC came with some versions of MS-DOS? Maybe I'm remember that wrong. But if so, yeah fire up DOSBOX and run that REMLINE

[ahenry3068]

REMLINE leaves the line numbers that are the target of GOTO, GOSUB, ON GOTO/GOSUB and RESTORE.

So after its done its work you just have to go back and create labels.

[ahenry3068]

And you don't have to fire up DOSBOX.. Download QB64 and compile it to run natively under Windows or Linux


QBASIC came with DOS 5.0 and later

[ahenry3068]

I owned a copy of QuickBasic 4.5 which was the full compiler version though. It was the first actual compiler I used on my own computer ( I had used HARRIS COMPUTERS, BASIC & FORTRAN compilers on a mini-computer previously though)

[Martin Schmalenbach]

Nice one Voidstar!!

I have the source from the original 3 part Byte Journal articles from 1978.

I typed them in and then ported it over to my iPad running TechBasic where I've been playing with it for a few years, getting it to generate code for the Pic24 series microcontrollers, with some success. The 6502 is quite a different beast than the PIC24, which is more like a 16 bit version of the MIPS architecture from back in the day, and a Harvard architecture too. Generating reasonably efficient code on the PIC24 quite easy - on the 6502 - not so much!!

I got it running on the X16 a couple months back with no issues, and I'm now working to extend it to handle strings and floating point variable types, make use of the X16's additional video & sound capabilities and work with 3 memory models:
1 - pCode interpreter running within the standard 64K memory map
2 - pCode interpreter running from any/all of the banked memory
3 - native 6502 code - at the moment this is very rough and generates assembly language for now - far easier/quick to develop that way for the moment.

I have the interpreter and the compiler running on my C64 quite happily under Blitz.

I'd like to 'Blitz' it on the X16 too, once Stefan is able to get the version he's working on to correctly handle file operations.

I've just spent the last 2 days moving the Tiny Pascal over to work with BASLOAD as this will speed up hugely the development work to extend TinyPascal to handle floats, strings and the larger memory models, video & sound hardware.

Just some testing to do on the BASLOAD version to make sure I didn't break something along the way - I usually do!

[voidstar]

Wow, I'm excited about that - on the possibility of running a Pascal compiler on-system (on the X16). There is the PA65 project that runs "off-system" and is supporting a lot of neat features.

And you say you've adapted your work over to BASLOAD? That's very excellent to hear. Keep in mind we do have ASMEDIT already that is an on-system 6502 assembler (I don't know if it utilizes any 65c02 features yet). It uses an older "dialect" of assembler - also I think the ".sor" files it uses are in some packed form. But point being, if a compiler can get to the assembly output stage, we have on-system tools that could take it from there on linking things together into an executable .prg (I'm not yet sure if asmedit handles multiple .s/.sor files)

But any compiler still needs "core support" for things like multiplying large numbers (byte vs word vs long type conventions) and keep the sign/wrapping.  And conceptually it could "borrow" BASIC's approach for handling floating points, but those hooks are a bit esoteric to tie into (at least for me, you have to know the ROM implementation very well).


From the tinyCompiler manual that I have, I'm going to key in the p-code emulator that corresponds to the sample entered earlier -- even if never used, it'll be "archived" here as a matching reference. Attached is the "reference manual" I was using. And to clarify for others: I think the work Martin is referring to is a "different lineage" than the one I'm using, but very much same/similar idea, just Martin I think is much further along is transitioning it over to the X16.

Appreciate any time you have to progress on this. I know there will be limitations, but there is a lot of interest of any on-system development tools (and an on-system language, of any kind, that supports records and pointers would be neat).

[Martin Schmalenbach]

Hi Voidstar,

Happy to collaborate with you!

We're actually working with the same lineage - the book you show looks very familiar. Is it hardback and with a kind of purple-brown / dirty mauve colored cover? If so, I have that too. It's the same as the Byte magazine articles - it's actually the Byte Book of Pascal. Note on the right hand page displayed in your photo, very bottom left of the page the "September 1978 (C) Byte Publications" message!

I just downloaded what you had typed in and posted here at the very start of this thread to check code lineage - it is the same lineage - exactly!

I was under the impression that the ASMEDIT program was incomplete and will or has been removed from the latest hardware implementation?

Maybe I'm getting that mixed up with something else? That wouldn't be at all unusual!!!

I had already been working on porting my C64 assembler written in basic over to the X16 with an updated CPU model to support the appropriate 65c02 processor instruction set. This all started many years ago when I came across the very excellent series of articles by Jim Crenshaw called "Let's Build A Compiler" in 15 parts running from 1988 to 1995.

So my plan is for now to continue with the BASLOAD version and get that running again on the X16.
Then comes support for strings and the file system.
Then I'll sort out access to memory locations - peek & poke stuff, followed by exposing access to the various bits of hardware, video etc.
Then perhaps support for floating points, longer integers.
After that it will be use of the expanded memory.

In parallel with this I am contemplating a run-time library which will have some optimized code for much of this, over time. Initially I may just provide it as a library of functions written in TinyPascal and bootstrap from there.

Either way - it should be fun!

One question I have - how or where do I get a running version of BASLOAD? Do I have to build it myself? I hope not!

Cheers

Martin

[voidstar]

Ah neat! My copy is just the ~42 pages of stapled loose paper, no cover.

Stefan does a good job at keeping current version of BASLOAD updated here:
viewtopic.php?t=6322
And in that, he also has a link to the github repo. And to clarify, BASLOAD doesn't really load BASIC files (not tokenized) It loads text files that contain a version of BASIC that doesn't use line numbers (it determines the necessary line numbers for you when tokenizing the BASIC into memory). Mainly, this allows for symbolic branching instead of line numbers.

Paul is working on Blitz for the X16. He's not quite as organized on releases, but generally the most recent .PRG is here:
https://github.com/paulscottrobson/blit ... in/release
The X16 version is of course similar to the "classic" C64 one. But for completeness in describing things: Blitz as currently available is given a tokenized .PRG (tokenized BASIC) and "converts"/compiles it to more native 6502 machine code. This eliminates the overhead of any parsing of tokens. But it is a tough tool to maintain as it has to "keep up" with all the X16 BASIC tokens. It also helps "normalize" numeric handling (like instead of 5 byte BASIC representation, it can use a more native representation of the processor).


Regarding ASMEDIT, you may have been thinking of CODEX. We all would like to see CODEX be successful, but it's been a bit on hold for a while. It is still currently in the ROM. I've only used it a few times, and "limited success" (I think it does work, but it has a bit of a learning curve). ASMEDIT is something different, and is described as linked below (towards the end of that discussion is a recent update). It has a very lengthy manual and seems fully capable (and like Blitz, it was derived from a "classic 80s" assembler - hence why it uses an older style of syntax; I've used it to make a few working executable examples). But it isn't the most intuitive tool (relative to some modern 6502 assemblers).
viewtopic.php?t=6729

X16EDIT is the on-system text editor, also maintained by Stefan (of BASLOAD). X16EDIT is incredibly robust (in my opinion) for large files, scrolling for long lines on a row, search, directory listing, even mouse support (to highlight and copy blocks). But integrating anything like modern "intellisense" or even syntax highlighting is still a bit of a dream.


Hope that helps as just an orientation of some existing tools that I'm aware of. Oh, there is another assembler that runs on-system for the X16. And interestingly enough, it is also written in BASIC:
viewtopic.php?t=6725
I've only used it a couple times also, and it does work as far producing 6502 assembler output. I think its charming in being fairly straightforward - and all of this is in the domain of "education software" or for instructive purposes, so bleeding-edge optimization and performance isn't the main focus.