Since there is a lot going on, I wanted to post an update on P5 happenings.
Points:
We are trying to get a new version out, most likely 1.3.
Byte mode was implemented and passes regression.
Several new methods to self-strap the compiler have come online, or are coming online.
Welcome new developers.
New version
The new version is being evalulated. The criteria for a release (as usual) is that it passes all regression tests and "an effort made" to clear outstanding ticket backlog.
The new version will likely be 1.3. I typically increment the version number in the source for the next release. The problem with that method is that, since there are several people developing from the source, version 1.2 (the present label in the source), is already well known out there. I am probably going to institute an "experimental" version number system like 1.2.x in the near future.
Byte mode
It came to my attention while running regressions that P5 does not self compile in its present form. The accessor routines in pint rely on a type of 0..255 being expressed as a byte, that is, occupying a single byte and being an unsigned value. This P5 never did, but its host compilers did (IP Pascal, GPC). So P5 does not self compile.
At one time in the past, P5 did self compile. The old way of doing things was to type bytes as char, and do conversions to and from them to integer. At some point that got changed.
In any case, I decided the simplest and best thing going forward would be for P5 to treat 0..255 ranges as single byte values. This both fixes the issue with self compile, as well as issues with byte I/O on future uses of P5. For example, it can create and read byte files now.
New strap methods
If you have followed my discussions, you know that I, as well as others, have been affected by the increasing problems running GPC due to its being pinned to older versions of GCC. The good news is that several alternatives are coming online:
The pascal-p5c project is a sister project to Pascal-P5 that translates the ISO 7185 language to C. You can use that to translate both your own programs, and Pascal-P5 itself, to a target machine and run it. I hope to provide support for integration with Pascal-p5c soon in Pascal-P5, such as ability to configure both creating and using cross strapped pascal-P5 binaries.
One of the developers here, Reinhard Meyer, is working on a hand-translated verision of pint.pas. This allows you to strap a version of P5 by running its intermediates anywhere there is a GCC compiler. I will be also wrapping this into the configure process when it is available.
The FPC developers have a new version of their compiler that implements ISO 7185, and there will be extensive testing work going on with respect to that.
New developers
Welcome new developers:
Reinhard Meyer
Trevor Blight
We always welcome new developers, all help is appreciated. All that is required is:
Read the goals of the project. See the Wiki page.
Discuss changes with others in the project, preferably before making them.
Scott Franco
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Nested functions are in C99, and GNU has been working towards full C99 compliance. So you can specify original K&R C, ANSI C, or C99 as being the operative standard. C99 is well entrenched now. You are C compliant in my mind.
PS. Implementing Pascal as translated into C without relying on this C99 feature would have been a nightmare, IMHO.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Update: P5 is undergoing, and apparently passing, a full regression as I write this. It takes the better
part of a day to pass the final part of the self compile, cpints.bat. When I left it, it appeared to be running.
It was a very hard slog getting the self compile working, but it proved its worth. There were a lot of bugs found just from running that.
The next steps are the outstanding bug tickets.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Since there is a lot going on, I wanted to post an update on P5 happenings.
Points:
New version
The new version is being evalulated. The criteria for a release (as usual) is that it passes all regression tests and "an effort made" to clear outstanding ticket backlog.
The new version will likely be 1.3. I typically increment the version number in the source for the next release. The problem with that method is that, since there are several people developing from the source, version 1.2 (the present label in the source), is already well known out there. I am probably going to institute an "experimental" version number system like 1.2.x in the near future.
Byte mode
It came to my attention while running regressions that P5 does not self compile in its present form. The accessor routines in pint rely on a type of 0..255 being expressed as a byte, that is, occupying a single byte and being an unsigned value. This P5 never did, but its host compilers did (IP Pascal, GPC). So P5 does not self compile.
At one time in the past, P5 did self compile. The old way of doing things was to type bytes as char, and do conversions to and from them to integer. At some point that got changed.
In any case, I decided the simplest and best thing going forward would be for P5 to treat 0..255 ranges as single byte values. This both fixes the issue with self compile, as well as issues with byte I/O on future uses of P5. For example, it can create and read byte files now.
New strap methods
If you have followed my discussions, you know that I, as well as others, have been affected by the increasing problems running GPC due to its being pinned to older versions of GCC. The good news is that several alternatives are coming online:
New developers
Welcome new developers:
Reinhard Meyer
Trevor Blight
We always welcome new developers, all help is appreciated. All that is required is:
Scott Franco
"Pascal-P5 that translates the ISO 7185 language to C."
Small clarification:
Pascal-P5 that translates the ISO 7185 language to gnu c.
Gnu c has extensions beyond the standard c language that are needed by p5c, the most obvious of which is nested functions.
Yes and no.
Nested functions are in C99, and GNU has been working towards full C99 compliance. So you can specify original K&R C, ANSI C, or C99 as being the operative standard. C99 is well entrenched now. You are C compliant in my mind.
PS. Implementing Pascal as translated into C without relying on this C99 feature would have been a nightmare, IMHO.
Update: I have been running the FPC compiler against the code, and got a run of it going against P5.
We have an FPC that can do ISO 7185 code!
Update: P5 is undergoing, and apparently passing, a full regression as I write this. It takes the better
part of a day to pass the final part of the self compile, cpints.bat. When I left it, it appeared to be running.
It was a very hard slog getting the self compile working, but it proved its worth. There were a lot of bugs found just from running that.
The next steps are the outstanding bug tickets.
Update:
The full regression is taking 3 days to run !
The prt test is a relative disaster. It will take a while to get that straight.
Working on reducing the bug tickets to as close to zero as possible.