Commander X16

In the interests of fun & exploration, I'm posting here the current working versions of the Tiny Pascal compiler and pCode interpreter.

NONE of the X16 functions are implemented, and there is no opportunity for the moment to manipulate memory directly.

I'll also post the original example test program that was part of the original 3 part series of articles in BYTE magazine starting September 1978.

For the compiler, when it asks for the RAM Bank - for now leave it at the default, so just press RETURN.
Ditto when it asks for the pCode starting address.

This means the pCode will be written to memory starting at address $A000 in RAM Bank 10 on the X16 and emulator.

When asked if you wish the pCodes displayed, answering Y means that as the compiler runs and compiles, it will print out the compiled pCode for each line it processes, and print out that line from the source.

Source code is expected to be a simple text file. Give it a file name - ideally locate it in the same folder as the compiler.

And then just sit back!

When compiled, the compiler will write the entirety of the RAM bank 10 from $A000 to $BFFF to disk using BSAVE.

It will have the same filename as the source code file BUT with ".OBJ" added on the end.

When you run the pCode interpreter, you will be asked for the pCode start address. For now, enter in 40960, and for the RAM bank stick with the default of 10.

Then give the full filename of the object pCode to run - including the ".OBJ" on the end.

It will then load that in to memory and examine and display the first pCode instruction.

You will be presented with the "INTERP>" prompt... pressing "?" and ENTER will display a list of all accepted commands. They are 1 character commands followed by the RETURN key. Any other info it needs it will ask for at the time.

Enjoy!!

Here's the test program I mentioned - for some reason I couldn't get it to upload here as a file.

I couldn't post the screencast here, so I've uploaded it and all other relevant files for your enjoyment on my google drive.

https://drive.google.com/drive/folders/ ... sp=sharing

Cheers

Martin

KNOWN ISSUES...
New as at 15:39 HRS MST 19NOV2023:

• For now the source pascal file needs to have at least 1 line of empty or any text after the "END." statement of the Tiny Pascal program.

+++ END

This is incredible!

You've compiled an actually-useful Pascal program, all while being "on system."

Features: calling a user defined function, including sub-functions, passing arguments, typed variable declarations, and those functions can return values.
(one question: the function arguments "carry the passed type" or for now are integer by default?)

And it is dusting off an approach from 1978 of using BASIC to implement this high-level language!

This is a great starting point that captures the original BYTE article. In 1978, microcomputers were still "mysterious" on what they could even be used for - you had the soaring mainframes, meanwhile pocket calculators crawled up and became desktop "appliance computers." So "historical projects" like this capture that moment of progress.

Turbo Pascal 1.0 for the PC came out in 1983.
There was an Apple Pascal in 1979, but it also needed its own OS.

"bootstrapping" a higher level language out of BASIC didn't really catch on, maybe because it remained difficult to construct programs larger than BASIC itself? You have to read an input file, and the buffer of that has to go somewhere. Then your generated "object code" (be it a tokenized intermediate, assembler, or actual opcodes) has to go somewhere, while your compiler code also has to go somewhere. Balancing all that on systems with under 32KB system RAM, and *maybe* a 160KB single sided disk drive, chewing on bytes at barely 1MHz Or maybe it didn't catch on since BASIC line numbers just has a complexity limit where you just get entangled, and now BASLOAD helps solve that.

But separate from those technical constraints, this project I think is a good early-look at how to start a high level language and the concepts involved, going through the full gamut involved for making executable software.

Thanks for taking this project up!! Would love to see a LONG or BYTE type, RECORD, ARRAY, maybe UNITS support, and even a form of inline assembly? FLOAT is nice, but to me a lower priority (just since I try to scale or solve things in a way that don't really need floating point).

voidstar wrote: ↑Tue Nov 21, 2023 3:05 am This is incredible!

Thanks - all I've done is take the work from the original authors Kin-Man Chung and Herbert Yuen from all those years ago and get it to run on the X16!

My interest in languages and compilers goes back a long way, and got more involved when I came across Jack Cranshaw's excellent "Let's Build A Compiler!" series from 1988 to 1995 or so. A Pascal-like language built from the ground up... in Pascal as it happens, and generating 68K assembly language. I took it from there to compiling on a PIC24/dsPIC33 microcontroller and added basic optimizations.

voidstar wrote: ↑Tue Nov 21, 2023 3:05 amYou've compiled an actually-useful Pascal program, all while being "on system."

Features: calling a user defined function, including sub-functions, passing arguments, typed variable declarations, and those functions can return values.
(one question: the function arguments "carry the passed type" or for now are integer by default?)

And it is dusting off an approach from 1978 of using BASIC to implement this high-level language!

This is a great starting point that captures the original BYTE article. In 1978, microcomputers were still "mysterious" on what they could even be used for - you had the soaring mainframes, meanwhile pocket calculators crawled up and became desktop "appliance computers."

Turbo Pascal 1.0 for the PC came out in 1983.
There was an Apple Pascal in 1979, but it also needed its own OS.

"bootstrapping" a higher level language out of BASIC didn't really catch on, maybe because it remained difficult to construct programs larger than BASIC itself? You have to read an input file, and the buffer of that has to go somewhere. Then your generated "object code" (be it a tokenized intermediate, assembler, or actual opcodes) has to go somewhere, while your compiler code also has to go somewhere. Balancing all that on systems with under 32KB system RAM, and *maybe* a 160KB single sided disk drive, chewing on bytes at barely 1MHz Or maybe it didn't catch on since BASIC line numbers just has a complexity limit where you just get entangled, and now BASLOAD helps solve that.

But separate from those technical constraints, this project I think is a good early-look at how to start a high level language and the concepts involved, going through the full gamut involved for making executable software.

Yep - lots of good stuff in it and those articles. I found it a tad tricky to start off with, trying to follow the compiler's logic in an unstructured language... it helped that I'd had previous exposure to compilers etc.

It's actually put together quite well, all things considered.

But there are limits to complexity - well, I suspect mostly to patience. Taking it over to the BASLOAD environment helps hugely.

voidstar wrote: ↑Tue Nov 21, 2023 3:05 amThanks for taking this project up!! Would love to see a LONG or BYTE type, RECORD, ARRAY, maybe UNITS support, and even a form of inline assembly? FLOAT is nice, but to me a lower priority (just since I try to scale or solve things in a way that don't really need floating point).

I'm planning LONG & BYTE. At the moment it only does INTEGERS, signed 16 bit. And single dimension arrays of the same. Characters are done via integers too! BYTE will be easy as it fits nicely in to the pCode instruction's 32 bits - each pCode is 4 bytes, with the first byte indicating the main opcode, the second byte indicating either a subset of the main opcode, or an index/hierarchy level to handle sub functions/sub procedures and accessing a parent/grandparent etc's local variables or parameters. It's this which makes having localized sub functions and sub procedures very easy to implement - just like many other 'serious' compiled languages do & their implementations do.

A high priority for me at the moment is adding some form of PEEK/POKE and SYS/USR capability so that the entirety of the machine is opened up, albeit it in a crude way for now. I'll likely do DEEK/DOKE and QUEEK/QUOKE for double (16 bit) and Lon (32 bit) values to set/read.

LONG will likely need to make use of a double pCode - 2 pCode instructions, or 64 bits... which at first glance makes for a complex stack-handling process, though previous experience with other compilers suggests this may not be as awkward/complex as it first seems.

I'll want to add pointers too, to help with string handling as well as improved array handling and so on. User defined SCALAR types in Pascal terms, like ENUMERATED and SUBRANGE should be quite straightforward to do, not sure sure though about the very useful 'IN' operator.

And I want to provide good access to the full 2 or 3.5Mb of address space of the X16, especially if we're to have RECORDs, which I'd love to implement too. And sets...

You asked about the INTEGERs in the parameter definitions - it's as you infer - because INTEGER is the only type. Bringing additional types on board is a little more challenging than it first looks due to questions of type strength and type casting. Especially in parameter passing and function value returns.

At the moment they are all 'pass by value' parameters - I'm toying with the idea of 'pass-by-reference' capability as well - one more reason for having a good pointer capability within the guts of it all!!

I am very open to the very useful UNIT capability, but I've not given that sufficient thought just yet. I do know though that I'll be making heavy use of the banked RAM, and wherever possible, the BASIC & KERNAL ROMs wherever it makes sense to!

BTW - those screen shots - are they of the Tiny Pascal compiler/interpreter running on actual hardware, or the emulator?

Looking further in to the UNITS feature... that should be fairly straight forward to do... and perhaps make the task of dead-code removal as a compilation optimization somewhat easy to implement 'well enough'...

Ditto with file handling... once I've got strings and/or arrays of chars implemented...

Yes, the images are from running on hardware!

voidstar wrote: ↑Tue Nov 21, 2023 4:22 am Yes, the images are from running on hardware!

Very excellent!