The 1.4 version of Pascal-P5 got posted today. This is (hopefully) the last
major source code change version. I wanted to take a break from work on
Pascal-P6 and Petit-ami, because there were a lot of fixups and improvements
from Pascal-P6 that applied to Pascal-P5. In addition, there were several more
error cases from the ISO 7185 standard that were not yet handled in either
Pascal-P5 nor Pascal-P6.
I'm happy to say that Pascal-P5 now completely covers the error cases in the
ISO 7185 spec.
I saw the other day that Pascal-P5 might be 10 years old! This was news to me.
The repo says 2014, but I have lots of projects that I don't commit until they
have been worked on a while, so 2010 could be the actual date.
Is Pascal-P5 popular? It shows 171 downloads on the last version, 1.3, which is
low by the standards of a lot of software. It has never been reviewed! Even a
bad review. Oh well.
To find out what goes on with Pascal-P5, you have to go web surfing. P5 has
been archived elsewhere, been modified, been translated into other languages,
and been extended. In one case, it was used as the basis for a magazine
article. Nice! I have never been published, but then, outside of a few irate
newspaper letters to the editor, I admit I never tried.
P5 was used as the basis of a Pascal to C translator by Trevor Blight. That gets
a lot of airplay on the web, which is cool.
One nice guy wrote a C version of the interpreter, which included the basics of
what you would expect: it used a modified version of pint.pas that output the
intermediate code in binary, then ran that on an interpreter written in C.
It was a good effort. In fact I liked the idea a lot, but his version was not
%100 compatible with the intermediate code generated by the regular pcom.pas
compiler, and that was really a minimum requirement for me. So I got
enthusiastic and knocked out a version of the interpreter that did do that, and
was %100 compatible. It runs a lot faster than the normal interpreter. Its in
the Pascal-P6 compiler, and I'll apologize right now for taking the nice
gentleman's idea, but not his code.
A lot of people send me code to add extensions of various kinds to the Pascal-P5
compiler. That's nice, but it's not really the mission of Pascal-P5. It IS the
mission of Pascal-P6, but I will admit I am not a fan of implementations that
just add various features to the language incrementally. I wrote a document for
IP Pascal that outlined the various extensions I used in that compiler since
about 1997, including the variable length array handling, a feature which I
studied for years in the early 1990s before deciding on an implementation. After
writing it all down, and including candidate features I wanted to add, I got a
feeling for how the features worked together, and worked hard for several years
to improve it into a specification for a new language, Pascaline.
What about compilation to actual code? Trevor's Pascal to C translator is one
way. I personally prefer a formal back end machine encoder for languages.
Cascading one language to another means you are dependent on other tools, other
compilers to get work done. I actually made a couple of starts on a backend for
Pascal-P5, but realized that any code generating implementation didn't make
sense without some basic extensions to the language, like file processing by
name, for example.
Would Pascal-P make a good compiler? Well, probably as much as you want. P5
determines the entire layout of the backend code at the start, but to tell the
truth, machines are fairly standardized these days. Byte accessable, word length
a binary power of bytes (8, 16, 32, 64), and everthing aligned on its length.
Pascal-P5 strips all of the identifiers out of it's intermediate (which oddly,
P6 puts back -- but only for debugging), but an address is as unique as a name.
More to the point, I would never fit a complex code generator to P5/P6, just
because its simplicity is its charm. P5 is a 10k line program. IP Pascal is over
100k lines, and its difficult to manage. However, I have looked at it and I
think P6 can get a fairly simple code generator that can give medium, but not
great, results. And that is all that is required.
What about VMs? I don't know why, but VMs or Virtual Machines are back in
fashion. The idea is for the cost of a small interpreter you get very compact
and secure runtime code. That's basically what the C interpreter for P6 gives
you (and indeed, in the article on Pascal-P5 they rewrote the interpreter in C).
That's actually NOT the most compact the interpreter can be. First, and very
typical of VMs, the code can be made a lot more compact. Each of the loads,
stores, and other intermediate operands that take and address can be packed into
new, short instructions that take signed offsets of (say) 8, or 16 bits.
The other thing you can do to reduce the size of the interpreter is what I call
"loop defining" the code. This is in regards to the system call code, the
instructions that do things like make writeln() work. This is actually a lot of
code (the C interpreter tries to fit it into the standard C library as much as
possible to save space). There is no reason that code can't be handled by code
running on the VM itself. To make that work, you need a mechanisim where the
code to execute SCs or system calls is entered before the main code, and a way
to indicate what routine in the SC code is executed where.
This actually dovetails into the "final solution" for the VM. I have done small
CPUs in Verilog (my 8080 core is on opencores.org). There is no reason a CPU
that executes Pascal-P code directly cannot be made. And indeed, this was done
back in the 1980's, using a chipset designed to execute PDP-11 code for Western
Digital.
Getting back to Pascal-P5 versions I see on the web, I notice that fairly few
bug reports get submitted back to me. I have even received bug reports like
"I found one of your bugs, fixed it, and it is in the version of Pascal-P5 I
modified over HERE...". Please. This is basically saying "go fish". If you like
Pascal-P5, then pay it back by filing proper bug reports.
I get a few folks encouraging me to try out the new ISO 7185 mode in FPC (Free
Pascal Compiler). I admit that when I first heard about that, I went gung ho and
created a series of directories and scripts to enable using FPC as a host.
Alas, the result of that, while finding out that the ISO mode was pretty good,
the system had too many bugs to use FPC as a host, so I gave it up (I'm sad).
In fact, the last go around with FPC was not even their fault. FPC did fix
issues with their compiler, but as I just went through tightening up the
ISO 7185 compliance in Pascal-P5, FPC (again!) could no longer compile
Pascal-P5. Hardly their fault that they are not hitting a moving target!
In any case, FPC is still on the "sometime soon" list.
Anyways, that's all for now. I am back to working on other things for a while.
Scott Franco
San Jose, CA
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here and there with Pascal-P5
The 1.4 version of Pascal-P5 got posted today. This is (hopefully) the last
major source code change version. I wanted to take a break from work on
Pascal-P6 and Petit-ami, because there were a lot of fixups and improvements
from Pascal-P6 that applied to Pascal-P5. In addition, there were several more
error cases from the ISO 7185 standard that were not yet handled in either
Pascal-P5 nor Pascal-P6.
I'm happy to say that Pascal-P5 now completely covers the error cases in the
ISO 7185 spec.
I saw the other day that Pascal-P5 might be 10 years old! This was news to me.
The repo says 2014, but I have lots of projects that I don't commit until they
have been worked on a while, so 2010 could be the actual date.
Is Pascal-P5 popular? It shows 171 downloads on the last version, 1.3, which is
low by the standards of a lot of software. It has never been reviewed! Even a
bad review. Oh well.
To find out what goes on with Pascal-P5, you have to go web surfing. P5 has
been archived elsewhere, been modified, been translated into other languages,
and been extended. In one case, it was used as the basis for a magazine
article. Nice! I have never been published, but then, outside of a few irate
newspaper letters to the editor, I admit I never tried.
P5 was used as the basis of a Pascal to C translator by Trevor Blight. That gets
a lot of airplay on the web, which is cool.
One nice guy wrote a C version of the interpreter, which included the basics of
what you would expect: it used a modified version of pint.pas that output the
intermediate code in binary, then ran that on an interpreter written in C.
It was a good effort. In fact I liked the idea a lot, but his version was not
%100 compatible with the intermediate code generated by the regular pcom.pas
compiler, and that was really a minimum requirement for me. So I got
enthusiastic and knocked out a version of the interpreter that did do that, and
was %100 compatible. It runs a lot faster than the normal interpreter. Its in
the Pascal-P6 compiler, and I'll apologize right now for taking the nice
gentleman's idea, but not his code.
A lot of people send me code to add extensions of various kinds to the Pascal-P5
compiler. That's nice, but it's not really the mission of Pascal-P5. It IS the
mission of Pascal-P6, but I will admit I am not a fan of implementations that
just add various features to the language incrementally. I wrote a document for
IP Pascal that outlined the various extensions I used in that compiler since
about 1997, including the variable length array handling, a feature which I
studied for years in the early 1990s before deciding on an implementation. After
writing it all down, and including candidate features I wanted to add, I got a
feeling for how the features worked together, and worked hard for several years
to improve it into a specification for a new language, Pascaline.
What about compilation to actual code? Trevor's Pascal to C translator is one
way. I personally prefer a formal back end machine encoder for languages.
Cascading one language to another means you are dependent on other tools, other
compilers to get work done. I actually made a couple of starts on a backend for
Pascal-P5, but realized that any code generating implementation didn't make
sense without some basic extensions to the language, like file processing by
name, for example.
Would Pascal-P make a good compiler? Well, probably as much as you want. P5
determines the entire layout of the backend code at the start, but to tell the
truth, machines are fairly standardized these days. Byte accessable, word length
a binary power of bytes (8, 16, 32, 64), and everthing aligned on its length.
Pascal-P5 strips all of the identifiers out of it's intermediate (which oddly,
P6 puts back -- but only for debugging), but an address is as unique as a name.
More to the point, I would never fit a complex code generator to P5/P6, just
because its simplicity is its charm. P5 is a 10k line program. IP Pascal is over
100k lines, and its difficult to manage. However, I have looked at it and I
think P6 can get a fairly simple code generator that can give medium, but not
great, results. And that is all that is required.
What about VMs? I don't know why, but VMs or Virtual Machines are back in
fashion. The idea is for the cost of a small interpreter you get very compact
and secure runtime code. That's basically what the C interpreter for P6 gives
you (and indeed, in the article on Pascal-P5 they rewrote the interpreter in C).
That's actually NOT the most compact the interpreter can be. First, and very
typical of VMs, the code can be made a lot more compact. Each of the loads,
stores, and other intermediate operands that take and address can be packed into
new, short instructions that take signed offsets of (say) 8, or 16 bits.
The other thing you can do to reduce the size of the interpreter is what I call
"loop defining" the code. This is in regards to the system call code, the
instructions that do things like make writeln() work. This is actually a lot of
code (the C interpreter tries to fit it into the standard C library as much as
possible to save space). There is no reason that code can't be handled by code
running on the VM itself. To make that work, you need a mechanisim where the
code to execute SCs or system calls is entered before the main code, and a way
to indicate what routine in the SC code is executed where.
This actually dovetails into the "final solution" for the VM. I have done small
CPUs in Verilog (my 8080 core is on opencores.org). There is no reason a CPU
that executes Pascal-P code directly cannot be made. And indeed, this was done
back in the 1980's, using a chipset designed to execute PDP-11 code for Western
Digital.
Getting back to Pascal-P5 versions I see on the web, I notice that fairly few
bug reports get submitted back to me. I have even received bug reports like
"I found one of your bugs, fixed it, and it is in the version of Pascal-P5 I
modified over HERE...". Please. This is basically saying "go fish". If you like
Pascal-P5, then pay it back by filing proper bug reports.
I get a few folks encouraging me to try out the new ISO 7185 mode in FPC (Free
Pascal Compiler). I admit that when I first heard about that, I went gung ho and
created a series of directories and scripts to enable using FPC as a host.
Alas, the result of that, while finding out that the ISO mode was pretty good,
the system had too many bugs to use FPC as a host, so I gave it up (I'm sad).
In fact, the last go around with FPC was not even their fault. FPC did fix
issues with their compiler, but as I just went through tightening up the
ISO 7185 compliance in Pascal-P5, FPC (again!) could no longer compile
Pascal-P5. Hardly their fault that they are not hitting a moving target!
In any case, FPC is still on the "sometime soon" list.
Anyways, that's all for now. I am back to working on other things for a while.
Scott Franco
San Jose, CA