we are still working towards the 1.3 release. This is now a milestone in the tickets area.
The tickets have been cleared out excepting the ones pertaining to the PRT (rejection) test. I'll explain why below.
The regression runs up until the last step, cpints.
FPC 3.0.0 was evaluated for use in P5. It had only a few issues, but they were sufficient to necessitate waiting for the next (fix) release before integrating into P5.
The PRT has a series of known issues.
Subjects:
FPC (Free Pascal Compiler)
I evaluated this and found it was almost ready to use as an alternative compiler. The only reason I didn't move forward to script that with P5 is that it would have required changes to P5 specifically to make FPC run a clean compile, and those changes weren't according to ISO 7185. I don't think it serves anyone for me to require a custom patched compiler for P5 use. Thus I decided to wait.
The advantages of using FPC vs. GPC are:
FPC is a live project. GPC is end of life.
FPC can (I expect) run on alternative environments such as MAC OS X.
PRT
The PRT does not run as before, it has several tests that crash it. These need to be addressed. It then needs to be evaluated that it produces the same results as formerly. See the ticket about fixing the remaining PRT tests for exact lists of what fails and what does not.
Tickets have been filed against coverage in the PRT, in one case what PRT does not cover, in another a question as to why a code issue was not caught. These tickets are being held pending work to clean up the PRT run.
Self compile
The self compile second step cpints shows issues. This test is mainly difficult to fix issues in because it is unbelievably slow (it takes most of a day to run).
General P5 status
P5 is not showing complete stability and needs to be improved before the 1.3 version.
Thats it, thanks for your attention.
Scott Franco
Last edit: Scott Franco 2016-02-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have been pushing the self compile. It revealed that there were a lot more byte handling cases. Basically, the original compiler removed subranges from operands at a very low level in the handlers, so that everything was treated as an integer. This needed changing so that we could see if bytes instead of integers (4 bytes) were being dealt with. The subranges were to be sent to the highest level possible, then removed only when operands were brought to stack top.
So this needed to be propagated to several places in the compiler, then as a result, a lot of opx (byte operators) were generated, even for on stack operations. Since that is usually treated as integer, since it was loaded onto the stack, we just make those operators aliases for their integer equivalents. They were left as opx, because I believe that like the ord operator, each type processed needs to be flagged, even if there is no difference in treatment. If the back end does not want to waste opcodes on this, it is free to discard these operations.
Anywas, this work advances and I expect to get a self compile soon.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
News items:
Subjects:
FPC (Free Pascal Compiler)
I evaluated this and found it was almost ready to use as an alternative compiler. The only reason I didn't move forward to script that with P5 is that it would have required changes to P5 specifically to make FPC run a clean compile, and those changes weren't according to ISO 7185. I don't think it serves anyone for me to require a custom patched compiler for P5 use. Thus I decided to wait.
The advantages of using FPC vs. GPC are:
PRT
The PRT does not run as before, it has several tests that crash it. These need to be addressed. It then needs to be evaluated that it produces the same results as formerly. See the ticket about fixing the remaining PRT tests for exact lists of what fails and what does not.
Tickets have been filed against coverage in the PRT, in one case what PRT does not cover, in another a question as to why a code issue was not caught. These tickets are being held pending work to clean up the PRT run.
Self compile
The self compile second step cpints shows issues. This test is mainly difficult to fix issues in because it is unbelievably slow (it takes most of a day to run).
General P5 status
P5 is not showing complete stability and needs to be improved before the 1.3 version.
Thats it, thanks for your attention.
Scott Franco
Last edit: Scott Franco 2016-02-12
Update:
I have been pushing the self compile. It revealed that there were a lot more byte handling cases. Basically, the original compiler removed subranges from operands at a very low level in the handlers, so that everything was treated as an integer. This needed changing so that we could see if bytes instead of integers (4 bytes) were being dealt with. The subranges were to be sent to the highest level possible, then removed only when operands were brought to stack top.
So this needed to be propagated to several places in the compiler, then as a result, a lot of opx (byte operators) were generated, even for on stack operations. Since that is usually treated as integer, since it was loaded onto the stack, we just make those operators aliases for their integer equivalents. They were left as opx, because I believe that like the ord operator, each type processed needs to be flagged, even if there is no difference in treatment. If the back end does not want to waste opcodes on this, it is free to discard these operations.
Anywas, this work advances and I expect to get a self compile soon.