Turbo Compiler issue

[Andrew]

I try to compile a rather large program with Turbo. The source code is about 145k
It compiles without errors and runs without errors IF I compile it with "Include NOS"
But if I compile it with "Omit NOS" then the parser task ends without errors but the Codegen fails with error "Code generation failed at line 0 Codegen phase error"

I also tried to to compile a previous version of my code- it compiles without problems with or without NOS.
The difference between the versions is 1 procedure, at the end of the code.
If that procedure is present in the program, then Codegen fails
I tried to pinpoint the exact line in the procedure that might be the cause. Result:
- if the procedure is empty (just DEFINE and End Def) than the program compiles with No NOS
- if the procedure has at least 1 line e.g. Local i%, then codegen fails with No NOS but works with Include NOS
- The procedure name is irrelevant - I changed the name ... no difference

I could not find any mention in the Turbo manual regarding the Codegen failed error.

Has anyone encountered this before? How can I solve this?

[tofro]

I try to compile a rather large program with Turbo. The source code is about 145k
It compiles without errors and runs without errors IF I compile it with "Include NOS"
But if I compile it with "Omit NOS" then the parser task ends without errors but the Codegen fails with error "Code generation failed at line 0 Codegen phase error"

I could not find any mention in the Turbo manual regarding the Codegen failed error.

Has anyone encountered this before? How can I solve this?

I'm also regularly compiling relatively large programs with Turbo, but haven't encountered your problem (yet?).

The first thing that comes to mind is the data space available to both parser_task and codegen_task. I do remember I had to increase that once (too much doesn't hurt) to 200k (or whatever fits comfortably in your system) on both programs. Turbo comes with a tool (whose name escapes me at the moment, but you can also do that with SEXEC) to do that.

[Andrew]

I'm also regularly compiling relatively large programs with Turbo, but haven't encountered your problem (yet?).

The first thing that comes to mind is the data space available to both parser_task and codegen_task. I do remember I had to increase that once (too much doesn't hurt) to 200k (or whatever fits comfortably in your system) on both programs. Turbo comes with a tool (whose name escapes me at the moment, but you can also do that with SEXEC) to do that.

I will try this, but i doubt it will make a difference.
This is the second time i get this error.
First time, 3 subversions back, i just reverted to a previous subversion and then rewrote the procedures back, one by one. And then, magically, the program started to compile both with Include Nos and Omit Nos. I have no clue what the issue was, as i could not find any sintax errors. (but i have changed the logic of a couple of functions)

[tofro]

Phase errors typically occur when the (assumed) size of something (be it code or data) has changed between code generator passes (phases, codegen_task does two of them), which would result in address shifts between phases. So, likely, the problem is not in the PROCedure that you're adding, but somewhere before.
I'm not sure if that is really helpful, but I would look into the code before the inserted code to find something where the compiler could have doubts about sizes.

(It could of course be a bug in the compiler as well - this actually shouldn't happen)

[Andrew]

The first thing that comes to mind is the data space available to both parser_task and codegen_task. I do remember I had to increase that once (too much doesn't hurt) to 200k (or whatever fits comfortably in your system) on both programs. Turbo comes with a tool (whose name escapes me at the moment, but you can also do that with SEXEC) to do that.

I increased the dataspace to 200k and it still doesn't generate the code

[swensont]

Andrew,

Can you compile the problem procedure on its own (maybe with a short wrapper to execute it)? Could you be hitting a limit on the number of DEFines (bit of a wild guess here)? Have you tried a different version of Turbo? Have you tried a QDOS system vs an SMSQ/E system? These might sound like random suggestions, but I'm looking to scope the issue and narrow the failure to certain conditions.

Tim

[tofro]

Just as a side note: Sheer program size is likely not the problem - Turbo happily compiles itself

[Andrew]

Thank you Tim and Tobias for your suggestions!
I found the culprit - but I have no idea why this was causing a problem.
I have a procedure:

Code: Select all

10320 DEFine PROCedure DeleteFiles(Winflag%)
10325 REMark WInflag% =1 means ask for confirmatin and create the window for delete status;
10330 REMark WInflag% =0 means do not ask for confirmatin and do not create the window for delete status because it is already created by the caller
10335 LOCal source$(50), name$(50), panel%, x%, k%, a$(100), ch%,ch1%, Index%,left%,windef$(50),hgt%, wid%, top%
10336   AllConfirmed%=0: Quit%=0
................
10390   IF Winflag% THEN
10395     IF x%>0 THEN
10400       k%=DlgWnd%(240,60,' Delete Files ', '   Are you sure you want to delete'&CHR$(10)&'     '&x%&' files and directories ?')
10405     ELSE
10410       IF isDir%=1 THEN
10415       a$='directory '&name$
10420     ELSE
10425       a$='file '&name$
10430     END IF
...................
10525   END IF

I deleted WinFlag% parameter and, it's a miracle!, the program now compiles with and without NOS!
I checked the procedure 10 times: all IFs have an END IF, all variables are declared, all strings are dimensioned - I have no idea why WInflag% was causing the program not to compile without NOS.
Maybe Winflag% conflicts with something that is loaded on my system , I have no idea.

I tried a new test: I changed the name Winflag% to Winflg%. Well, if the variable is named Winflg% then the program compiles with and without NOS
If the variable is named Winflag% then the program compiles only with NOS, but no code is generated without NOS.
I guess this settles it - the culprit is the variable's name.

[tofro]

Thank you Tim and Tobias for your suggestions!
I found the culprit - but I have no idea why this was causing a problem.
I have a procedure:

Code: Select all

10320 DEFine PROCedure DeleteFiles(Winflag%)
10325 REMark WInflag% =1 means ask for confirmatin and create the window for delete status;
10330 REMark WInflag% =0 means do not ask for confirmatin and do not create the window for delete status because it is already created by the caller
10335 LOCal source$(50), name$(50), panel%, x%, k%, a$(100), ch%,ch1%, Index%,left%,windef$(50),hgt%, wid%, top%
10336   AllConfirmed%=0: Quit%=0
................
10390   IF Winflag% THEN
10395     IF x%>0 THEN
10400       k%=DlgWnd%(240,60,' Delete Files ', '   Are you sure you want to delete'&CHR$(10)&'     '&x%&' files and directories ?')
10405     ELSE
10410       IF isDir%=1 THEN
10415       a$='directory '&name$
10420     ELSE
10425       a$='file '&name$
10430     END IF
...................
10525   END IF

I deleted WinFlag% parameter and, it's a miracle!, the program now compiles with and without NOS!
I checked the procedure 10 times: all IFs have an END IF, all variables are declared, all strings are dimensioned - I have no idea why WInflag% was causing the program not to compile without NOS.
Maybe Winflag% conflicts with something that is loaded on my system , I have no idea.

I tried a new test: I changed the name Winflag% to Winflg%. Well, if the variable is named Winflg% then the program compiles with and without NOS
If the variable is named Winflag% then the program compiles only with NOS, but no code is generated without NOS.
I guess this settles it - the culprit is the variable's name.

Do you maybe have a variable "WinFlag" (without the %) somewhere in your program? That might explain Turbo assuming for a while that the variable needs 6 bytes, later on realizing the integer variable only needs two or vice versa (which might explain the phase error). Yet another argument for something like MasterBasic (which I recommended in another thread). Both S*Basic and Turbo don't have separate namespaces for separate types.

[Andrew]

Do you maybe have a variable "WinFlag" (without the %) somewhere in your program? That might explain Turbo assuming for a while that the variable needs 6 bytes, later on realizing the integer variable only needs two or vice versa (which might explain the phase error). Yet another argument for something like MasterBasic (which I recommended in another thread). Both S*Basic and Turbo don't have separate namespaces for separate types.

No, I don't have.
I will give MasterBasic a try when I'll find time for it. I have not used it because I write the code on PC, in Notepad++ and save it on a DOS drive that is mapped both in QPC and QEmulator, so I can test the program simultaneously in Minerva and SMSQ/E.