P6 was started at the end of 2017 (git shows the initial commit at 2017-12-28).
I haven't noticed a lot of activity reading the discussion list. This is probably normal
for unreleased software, but it does not give me a lot of incentive to file reports,
so I thought would make up for that here.
=== Pascaline implementation ===
There has actually been a lot of activity on Pascaline features implementation. In fact,
what remains to be done are:
Also, the multitask parts of the modularity spec are not done, but that will be completed
shortly.
Because some of the features on the list were prioritized for how simple they were to
implement, what is left in the list above are some of the most difficult aspects.
A major exception to that was modularity, which actually took more than a month all told.
=== Debug mode ===
Debug mode, new with P6, is in the can and does need further shaking out. It is, however,
quite extensive and took more than a month as I recall.
=== Testing ===
Back about two months ago I noticed that the compiler crashed a lot on programs with
errors, and the problem was in fact getting worse. The good news is I have done a LOT to
fix that. The bad news is it has sucked down a lot of time.
The Pascal-P series was never designed for extensive error handling. This is
a big difference between a compiler as a toy and a compiler as a tool. The
main steps for resistance to errors are to both detect errors and fix the
internal data so that further errors or crashes don't result from those
errors.
Several steps were taken to enhance testing:
Regression testing is now required, and a report that includes not only what passed,
but also a "digest" of the software versions involved is printed, and that is required
to be posted with commits that affect mainline code.
Full self run (P6 running on P6) was put back into the test runs. It is very
expensive timewise, and is only run occasionally.
The spew test was ported from IP Pascal to C in Pascal-P6. This is an automated fault
injection test and has generated a lot (a LOT A LOT) of issues with error handling that
have been cleaned up.
I am running the BSI tests.
I have been running the BSI tests against the code. That found some issues, but is now
error free and I am completing the remaining test runs against it.
The result of this is that the stability of P6 is greatly improved. I expect this
testing phase to complete shortly.
After the full checklist for Pascaline is finished, the plan is to write a full set
of acceptance and rejection tests for Pascaline features. Some of this was done
previously for IP Pascal (but not enough).
Debug mode will get it's own test suite. It is very complex and command line driven.
=== Version 0.1 ===
When Pascaline mode in P6 is complete, and testing is complete, the plan is to create
a 0.1 release. This will constitute a full P6 implementation, but without a code
generator for real machines. Unlike P5, I don't consider P6 to be complete (and ready
for a 1.x version) until that is done.
=== Version 1.x ===
I expect the x386 (32 bit) code generator to suck up several months of time (remember
I am doing this work in my spare time). I have made a decision, after long consideration,
to use the IP I/O and lib stack as is with P6. This will save a lot of time and add
a lot of new code to the P6 project, which I will put under the BSD license.
=== Back to P5 ===
There has been a lot of material put into P6 that is relevant to P5, especially in terms
of bug fixes. Its not unusual for new versions to have bug fixes that apply to old
versions. P5 fixes many bugs in P4, but (mainly for historical reasons) those fixes
won't go back into P4. P4 is not my code, it belongs to Wirth (in the sense he/they
wrote it).
However, I do feel a responsibility to back the ISO 7185 standard and keep P5
maintained as a base for that. Please note that:
P6 is completely upward and downward compatible with P5. P6 can be used as
a replacement for P5 in virtually all cases. At worst you may need to specify the
standard processing flag ($s). The Pascaline manual goes into this extensively.
You can find fixes for P5 issues by examining the P6 codebase.
Most people choosing P5 will do so because they want to base off an ISO 7185
compiler without the extensions. I think P6 is a better starting point, but I don't
care what version you use as a starting point for your project. Some people
still use P4 or even P2. Its a personal decision. I would only HOPE you would
not do this because you don't know what P6 is about.
What should find itself back to P5 from P6 are:
Bugfixes.
New tests.
Documentation updates.
There's an open question as to if the P6 code generator should be backported to
P5 (usually by stripping it). Nobody else has implemented Pascal as a true compiler
in ISO 7185 form, including Wirth on the CDC series computers. I identified a way
to do it, but that does not make it a good idea. The jury is out on this one.
Thanks and until later,
Scott Franco
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Pascal-P6 midyear update
P6 was started at the end of 2017 (git shows the initial commit at 2017-12-28).
I haven't noticed a lot of activity reading the discussion list. This is probably normal
for unreleased software, but it does not give me a lot of incentive to file reports,
so I thought would make up for that here.
=== Pascaline implementation ===
There has actually been a lot of activity on Pascaline features implementation. In fact,
what remains to be done are:
6.13 Container arrays:
6.14 Parameterized variables:
6.18 Fixed types:
6.23 Extended function results:
6.25 Overloading of procedures and functions:
6.26 Operator overloads:
6.35 Matrix mathematics:
6.36 Properties:
6.38 Channels:
6.39 Classes:
Also, the multitask parts of the modularity spec are not done, but that will be completed
shortly.
Because some of the features on the list were prioritized for how simple they were to
implement, what is left in the list above are some of the most difficult aspects.
A major exception to that was modularity, which actually took more than a month all told.
=== Debug mode ===
Debug mode, new with P6, is in the can and does need further shaking out. It is, however,
quite extensive and took more than a month as I recall.
=== Testing ===
Back about two months ago I noticed that the compiler crashed a lot on programs with
errors, and the problem was in fact getting worse. The good news is I have done a LOT to
fix that. The bad news is it has sucked down a lot of time.
The Pascal-P series was never designed for extensive error handling. This is
a big difference between a compiler as a toy and a compiler as a tool. The
main steps for resistance to errors are to both detect errors and fix the
internal data so that further errors or crashes don't result from those
errors.
Several steps were taken to enhance testing:
Regression testing is now required, and a report that includes not only what passed,
but also a "digest" of the software versions involved is printed, and that is required
to be posted with commits that affect mainline code.
Full self run (P6 running on P6) was put back into the test runs. It is very
expensive timewise, and is only run occasionally.
The spew test was ported from IP Pascal to C in Pascal-P6. This is an automated fault
injection test and has generated a lot (a LOT A LOT) of issues with error handling that
have been cleaned up.
I am running the BSI tests.
I have been running the BSI tests against the code. That found some issues, but is now
error free and I am completing the remaining test runs against it.
The result of this is that the stability of P6 is greatly improved. I expect this
testing phase to complete shortly.
After the full checklist for Pascaline is finished, the plan is to write a full set
of acceptance and rejection tests for Pascaline features. Some of this was done
previously for IP Pascal (but not enough).
Debug mode will get it's own test suite. It is very complex and command line driven.
=== Version 0.1 ===
When Pascaline mode in P6 is complete, and testing is complete, the plan is to create
a 0.1 release. This will constitute a full P6 implementation, but without a code
generator for real machines. Unlike P5, I don't consider P6 to be complete (and ready
for a 1.x version) until that is done.
=== Version 1.x ===
I expect the x386 (32 bit) code generator to suck up several months of time (remember
I am doing this work in my spare time). I have made a decision, after long consideration,
to use the IP I/O and lib stack as is with P6. This will save a lot of time and add
a lot of new code to the P6 project, which I will put under the BSD license.
=== Back to P5 ===
There has been a lot of material put into P6 that is relevant to P5, especially in terms
of bug fixes. Its not unusual for new versions to have bug fixes that apply to old
versions. P5 fixes many bugs in P4, but (mainly for historical reasons) those fixes
won't go back into P4. P4 is not my code, it belongs to Wirth (in the sense he/they
wrote it).
However, I do feel a responsibility to back the ISO 7185 standard and keep P5
maintained as a base for that. Please note that:
P6 is completely upward and downward compatible with P5. P6 can be used as
a replacement for P5 in virtually all cases. At worst you may need to specify the
standard processing flag ($s). The Pascaline manual goes into this extensively.
You can find fixes for P5 issues by examining the P6 codebase.
Most people choosing P5 will do so because they want to base off an ISO 7185
compiler without the extensions. I think P6 is a better starting point, but I don't
care what version you use as a starting point for your project. Some people
still use P4 or even P2. Its a personal decision. I would only HOPE you would
not do this because you don't know what P6 is about.
What should find itself back to P5 from P6 are:
Bugfixes.
New tests.
Documentation updates.
There's an open question as to if the P6 code generator should be backported to
P5 (usually by stripping it). Nobody else has implemented Pascal as a true compiler
in ISO 7185 form, including Wirth on the CDC series computers. I identified a way
to do it, but that does not make it a good idea. The jury is out on this one.
Thanks and until later,
Scott Franco