-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compiler front-end not handling prompted for submit file input #9
Comments
Is it stock CP/M 3? |
While I build things using an emulator on my mac mini or Raspberry Pi (zxcc, RunCPM and under SIMH AltairZ80), I verify and test on real hardware too. Mainly I use a Z280 running banked-memory CP/M 3 with Simeon Cran's ZPM3 enhanced BDOS replacement (The hardware is Bill Shen's Z280RC in RC2014 format). This is where I noticed this issue with submit file input. I'll switch to Digital Research's CP/M 3's stock standard BNKBDOS3 and RESBDOS3 (Y2K versions) and report back. |
So the problem I have is with zxcc. SIMH works perfectly ... |
I confirm same problem on simh cp/m-3 ... |
Yes that's the Z280RC. I wrote the banked memory CP/M 3 BIOS for it. Swapping to DRI's BDOS show's the same symptoms. I'll now install a copy of HI-TECH C on my Z80 MBC2 (which will be slow) and test it there. If needs be I can also fire up my almost 40 year old S-100 bus system - but it only has 8-inch floppies which may not be working (last fired up about 14 years ago to make disk images of all my old floppies!). |
It works properly under CP/M 2.2 on a real Z80
(sorry iI posted this to the wrong issue before) |
So quick look at it is the gets call in getargs after the prompt does not get anything ... it looks like the initialisation of the input being the console does not take into account input set by submit... (function nextch line 206). Will carry on investigating this week end if you want. I also validated that a normal program generated with the same libc as c.com works properly ...
So the scope of the issue is the front end of getargs ... |
The fact that the sign-on banner (written to stderr) loses the same number of characters that should be input to the c> prompt is suspicious. I've confirmed that increasing the command line reduces the banner by the same number of characters. I'm going to have lunch then look deeper... |
this is happening with all programs compiled with c.com contrary to what I thought. the more is written to stderr, the more is not taken into account in the input. |
Ok progress...
Removing this fsize adjustment resolves the problem Further digging needs to be I suspect ... I think further testing needs to be done . Interesting though is the fact that I did not have these two line in my pipemgr integration. I will also check whether it resolve my problem with the size adjustment... Interestingly ... the last problem I had (Issue #6) that was preventing c to work under cc is also gone. Everything works (i.e. the changes to stat, open, close I could not take ...). It is what I perceived as a bug in the cpm3 emulation of xxcc .... the following changes were causing grief and removing the lines above makes it work. The changes were in open.c commenting section around line 30:
in stat.c commenting section around line 57:
in close.c around line 16 changing
by
So if I remove those 2 lines in write.c, I am now able to run with exactly the same version as you, i.e. zxcc-htc and your project at 100% in line and only differ by cosmetics... Can you double check that on your you zxcc env? 2 birds with one stone I hope. |
Sorry, I had to attend to family commitments yesterday - so I didn't get to look into this further until now. The changes for the exact file sizes under CP/M 3 were done by Jon Saxton (jrs) and are explained in my README.md - simplifying file size calculations with backwards compatibility to CP/M 2.2. These then needed to be back-ported into John Elliot's original PIPEMGR (and the Van Nuys utilities). The code you found in the write() routine is suspicious - over-writing the read-write pointer. I began by looking for a missing call to fflush() which should be used when mixing reads and writes to the same stream. |
Yes, Actually now the changes of Jon Saxton are working in zxcc perfectly once I remove those 2 lines in write.c. did not before which is the problem I was experiencing with the c front end. |
I'm just confirming the change to write() works on CP/M 3 before pushing it. Thanks for spotting this before I did! |
Super cool!!! I am finally fully aligned with your code base 😉 |
I saw your .gitattributes issue. I use a mac and found it easier to just keep the sources with CR-LF line endings (which also is the way SIMH AltairZ80 exports files with the W command - and the reason I kept the ugly upper-case file names). Judicious use of dos2unix/unix2dos and the file commands fixes things - and I think there's a git setting to do this too. |
Sorry I was called away. This change does not fix this issue. Looking more closely at the code, there's two long words in the file control block for keeping the read write pointer (fc->rwp) and the file length (fc->fsize) in bytes. All this code in the write() routine is doing is updating the length of the file in bytes when the file is expanded. |
so I can confirm that the 2 extra lines compared to the HTC original
Do you have any idea/suggestion to pursue the testing and see side effects of removing them? I am a bit blind on this one as all my tests work. |
I only see this issue under CP/M 3 on my Z280RC and under SIMH AltairZ80. I'll go back and look at diffs and try doing a paper walk-through the I/O in getargs(). |
Ok the problem reappeared for me too on SIMH. So I unfortunately lost the fix that was working at some stage. |
I am so frustrated to having succeeded in making it work yesterday, I went through the same motion again but with a couple of tests I kept ... Added here a little litmus test. A simple submit:
and a simple program The output on sim with CP/M-3
So
For summary, the variant with fgets is a simple as that:
The problem seems to be in the management of the inputs/outputs (read, write, fcb) ... I don't know enough about the sharing of FCBs and Context, but it looks like the context/FCB of stdin and stdout are shared which does not make sense to me ... Follow up:
It work perfectly....
(ignore the 2 last lines, they are an issue with zxcc working or not)
in particular, when we do console write, creating a competition between CP/M Functions 10 and Function 1, which in a normal case never happens, the buffered console read being expected to be exclusive but in the case of the submit input, this is exactly happening.
in getargs.c for the prompt:
and c.c for the banner
PS: I found an unrelated small bug on getargs I am also chasing. After getargs is executed there is a missing carriage return or the EOL is displayed as a LF, hence my fprintf(stderr,"\n") after getargs .... |
Working solution description:
in signal.h:
in signal.c:
Working really well now. last small test with the c front end ... success 😀
|
And last, I think we could explore the usage of But I suppose it is another story. The number of case where the sigchk can interfere with a submit like scenario are legions: Examples of that any I/Os happening before or during console interactions, functions like getenv for example (reading files so calling _sigchk) |
You have been busy while I was sleeping. I also narrowed down some issues with gets() too and the problems of mixing of input and output to a stream.
Your solution seems fine - but there may be other traps lurking in other areas of the code. Also regarding the sensitivity to message lengths in the start-up code I noticed the x86 detection code in the start-up modules is broken (doesn't work when a compiler produced .COM file runs under MS-DOS as it should). I'll fix this as a separate issue and review/merge your recent pull request shortly after I have my breakfast! Tony |
Finally fixed this issue (fingers crossed)! |
The rebuilt compiler front end (from cpm/C.C) is not handling prompted for input when run from a submit file.
The compiler just sits at the c> prompt (I have entered the Ctrl-C to break back to CP/M's prompt).
Noticing that the sign-on banner loses the first 9-characters (that correspond to the 9 characters that should have been fed into the c> prompt input.
Suspect an issue with the streams handling routines.
The text was updated successfully, but these errors were encountered: