Tiny Pascal Compiler - V1 NOW AVAILABLE!

[Martin Schmalenbach]

Hi Folks,

A usable first version of the Tiny Pascal compiler that was first published in the September-November 1978 issues of BYTE magazine is now available for the X16.

You can download it at this discussion post point here, along with some additional, though brief, instructions on using it.

viewtopic.php?p=30441#p30441

Some of you will be aware that there has been a wee discussion on this topic over recent weeks.

It is my intention to develop this compiler further so that it supports most, if not all, of the X16 capabilities accessible via BASIC.

The Tiny Pascal compiler is written in BASIC and generates an object code file that is designed to run on an emulated virtual machine - it generates a simple pCode.

I also have a pCode machine emulator and simple user interface environment for it - it too is written in BASIC.

As soon as BLITZ is able to correctly support reading and writing sequential file operations as well as BLOAD and BSAVE I will provide BLITZ versions to significantly speed up the compilation process and the pCode execution.

I do intent to have the compiler generate native 65C02 machine code but that is someway down the road.

For now none of the X16-specific features are supported. I want to get some more testing done on where things are right now - it only supports signed 16 bit integer values and arrays. I plan to add strings, 32 bit integers and float support.

Also right now it doesn't support peek & poke functionality, but I am working on addressing that as my #1 priority.

I heartily recommend you tracking down those editions of the BYTE magazine I referenced above and reading the articles on Pascal and Tiny Pascal - it's good stuff!

Enjoy this first version, have a play and let me know by way of comments below if you run in to any problems or have feature requests.

Cheers!

Martin

[Martin Schmalenbach]

EDIT: CURRENTLY AT COMPILER V1.2.2 AND PCODE INTERPRETER V1.2.2

I will post the latest versions here as I evolve it, so everything is in one place for your convenience.

And I'll also list known issues, bug reports etc and feature requests here too.

DOWNLOADS:

TPINTERPV1.2.2.PRG

pCode Interpreter V1.2.2

(8 KiB) Downloaded 285 times

TPX16BASLOADV1.A.PRG

Tiny Pascal Compiler V1.2.2.1

(12.51 KiB) Downloaded 273 times

NOTE - This version (1.2.2) supports the READLN and WRITELN Pascal commands.


Here's a sample code that compiles and runs under this version of Tiny Pascal:

Code: Select all

CONST CR=13; LF=10;
VAR A,B,C,D:INTEGER;
FUNC MAX4(X1,X2,X3,X4);
   FUNC MAX2(X1,X2);
      BEGIN
         IF X1>X2 THEN MAX2:=X1
         ELSE MAX2:=X2
         END;
   BEGIN
      MAX4:=MAX2(MAX2(X1,X2),MAX2(X3,X4))
      END;

BEGIN
   REPEAT
      READ(A#,B#,C#,D#);
      WRITE('THE LARGEST IS ',MAX4(A,B,C,D)#,CR,LF)
      UNTIL A<0
   END.

Known Issues For Compiler

1. [X] Doesn't handle comments at all well - FIXED - uses same comments syntax as 'C' language.
2. [ ] Not yet 100% blitzable

Known Issues For pCode Interpreter

1. [X] Doesn't provide for peek & poke functionality - FIXED - addresses for now must be signed 16 bit values
2. [ ] Not yet 100% blitzable
3. [ ] Can't break out of it during an INPUT

Feature Requests For Compiler

1. [ ] Integrate with built in X16 editor
2. [X] Provide peek & poke functionality, including RAM & ROM bank control - FIXED - addresses must be signed 16 bit values
3. [X] Handle single & multi-line comments
4. [ ] Handle strings and arrays of strings
5. [ ] Handle 32 bit signed integers and arrays of same
6. [ ] Handle MSFT format 40 bit floating point

Feature Requests For pCode Interpreter

1. [ ] Integrate with built in X16 editor
2. [X] Provide peek & poke functionality, including RAM & ROM bank control
3. [ ] Modernize / make more 'fluid' the user interface and experience
4. [ ] Handle strings and arrays of strings
5. [ ] Handle 32 bit signed integers and arrays of same
6. [ ] Handle MSFT format 40 bit floating point

[Martin Schmalenbach]

OK - I've tested the PEEK/POKE functionality. It was always there, just not properly tested.

I have updated the TP interpreter to V1.1 to support this better.

To PEEK a memory location, use something like the following:

Code: Select all

// TPRT002.PAS
CONST CR=13; LF=10;
VAR A,B: INTEGER;

/*
  DEMONSTRATE PEEK FUNCTIONALITY
*/

BEGIN
	A:=%8400;
	B:=MEM[A];

	// NOTE THAT '%' SUFFIX RENDERS VALUE IN HEX FORMAT
	WRITE('MEM LOCATION $',A%,' HOLDS VALUE: $',B%,CR,LF);
	WRITE('+++ END.',CR,LF)
END.

[Martin Schmalenbach]

I've done some further testing on the PEEK/POKE functionality.

It works fine. There are some bounds checking issues that have been fixed in V1.2 - I haven't released this just yet as I'm wanting to have it handle BYTE data types too. This should be relatively easy as they're essentially a subset of INTEGER... I'm pondering having signed and unsigned BYTE and also implementing unsigned INTEGERs too.

V1.2 will also be able to call machine language routines - just like SYS... it is already there in V1.1 but is a bit flaky.

Addresses can be expressed either as a 16 bit signed value OR a 16 bit unsigned value. Internally the compiler converts unsigned to signed if the expressed value >32767 by subtracting 65536 from it.

The interpreter essentially POKE's the expressed value, a 16 bit signed value, with that value ANDed with 255.

When it is performing the PEEK functionality, the value returned will always be a positive byte value.

[Martin Schmalenbach]

OK - I went ahead and released V1.2 WITHOUT the BYTE and other data types - implementation of those will take a wee bit longer than I thought.

What is now working quite well in V1.2 is accessing memory and calling machine language routines.

To PEEK a memory location use "MEM[addr]" where 'addr' is a signed or unsigned 16 bit number. Any unsigned value > 32767 is converted internally to a 16 bit signed value.

Think of memory as an array of integers called "MEM[]" where the element values are always in the range of 0...255.

To POKE a memory location simply assign a value to the appropriate index or address in the "MEM[]" array.

Any 16 bit signed values are accepted to be poked in to that memory location BUT only the least significant byte is actually poked in to memory, by ANDing the value to poke with 255.

To call a machine language routine use "CALL(addr)" where 'addr' is a signed or unsigned 16 bit value, just as described above for the PEEK functionality.

Enjoy!

[BruceRMcF]

The final target for the pcode interpreter should probably be to implement it in assembler.

Note that the way that the old m-code Pascal compilers were done was to write a m-code interpreter in the target system assembler, and user another system that already had an m-code compiler to compile the m-code Pascal compiler in Pascal, and then use that compiled m-code on the target system to compile the compiler. Then you do a test if the two results are identical, and if not, you know the m-code interpreter has a bug. If it compiles to the same m-code that it running the compiler, then the m-code interpreter is working.

So if you can write the Tiny Pascal compiler in Tiny Pascal, and the p-code interpreter in 6502 assembler, then the Tiny Pascal compiler in Basic can compile the Tiny Pascal compiler into pcode, and now you have a much faster Tiny Pascal compiler.

[Martin Schmalenbach]

The final target for the pcode interpreter should probably be to implement it in assembler.

Note that the way that the old m-code Pascal compilers were done was to write a m-code interpreter in the target system assembler, and user another system that already had an m-code compiler to compile the m-code Pascal compiler in Pascal, and then use that compiled m-code on the target system to compile the compiler. Then you do a test if the two results are identical, and if not, you know the m-code interpreter has a bug. If it compiles to the same m-code that it running the compiler, then the m-code interpreter is working.

So if you can write the Tiny Pascal compiler in Tiny Pascal, and the p-code interpreter in 6502 assembler, then the Tiny Pascal compiler in Basic can compile the Tiny Pascal compiler into pcode, and now you have a much faster Tiny Pascal compiler.

Ooh - interesting!

Crafting the pCode interpreter in 65c02 assembler is a relatively straightforward task in relative terms. Writing the compiler in Tiny Pascal shouldn't be too difficult either, given we already have it in a high level language, albeit a relatively unstructured one. This is perhaps the way I'll go when I look to give it some of the more ubiquitous compiler optimization capabilities.

Thank you!

[Martin Schmalenbach]

UPDATE - V1.3 DELAY

Just a heads-up folks.

Implementing additional data types is going to take longer than I thought. The original authors of Tiny Pascal were able to avoid a lot of code and logic needed for handling multiple data types by having only 1 data type - integers... even though the first data type I'm trying to add is BYTE, a subset of the existing INTEGER data type.

This is the only aspect or addition I'm currently working on for the Tiny Pascal compiler because having this capability opens the doors to so many other additions and upgrades.

[mortarm]

A usable first version of the Tiny Pascal compiler that was first published in the September-November 1978 issues of BYTE magazine is now available for the X16.

You can find them on Internet Archives. Here's a direct link to those issues:
https://archive.org/details/texts?query ... %221978%22

[BruceRMcF]

Just to be clear (because with "compiler A compiling compiler B and compiler B compiling compiler B", it is easy to get lost), the bug test for the assembled p-code is:

* (1) Compile the p-code compiler with the Basic version of the compiler

* (2) Use the result of (1) to "self-compile" the Pascal version of the compiler using the Basic p-code interpreter.

* (3) Use the result of (1) to "self-compile" the Pascal version of the compiler using the assembled p-code interpreter

* (4) Do a test if the outputs of (2) and (3) are identical.

This doesn't test whether the Pascal compiler is bug free, but it does verify that whether bug-free or buggy, the result is the same using both p-code interpreters.