How to get the following to compile? It doesn't like any of the includes
and if I remove them it chokes on FILE etc.
dxforth <dxforth@gmail.com> writes:
On 9/08/2023 12:25 am, Nils M Holm wrote:
dxforth <dxforth@gmail.com> wrote:Via the undocumented ARCV.COM program? It crossed my mind but nothing I
tried worked.
Yes: `arcv file.arc` did it for me.
And I commented away all includes except the one for stdio.
And maybe renaming content to buf helped a bit too.
If there is as searchable A-C documentation somewhere, I'd like to get a pointer to it.
This one looks like images in a PDF only: <http://www.aztecmuseum.ca/docs/Aztec_C_1.06_User_Manual_Mar84.pdf>
On 9/08/2023 12:25 am, Nils M Holm wrote:
dxforth <dxforth@gmail.com> wrote:Via the undocumented ARCV.COM program? It crossed my mind but nothing I tried worked.
dxforth <dxforth@gmail.com> wrote:
How to get the following to compile? It doesn't like any of the includes
and if I remove them it chokes on FILE etc.
Did you unpack HEADER.ARC?
If there is as searchable A-C documentation somewhere, I'd like to get a pointer to it.
This one looks like images in a PDF only: <http://www.aztecmuseum.ca/docs/Aztec_C_1.06_User_Manual_Mar84.pdf>
Now you all got my curiosity up. <GRIN>thing, I decided to stop that program and give this a try...
I have been using the Aztec-C 1.05c and 1.06D compilers on my IMSAI 8080 replica to write a few programs as that was what I used to use on my old Kaypro II & 4's back in the day. Since I've been running my own blinkenlights program forever on this
Removing the references to include both string.h and stdlib.h, and fixing the fprintf() parameter error I was able to use the Manx Aztec CC.SUB submit file to compile the source into an ASM, assemble into object code, then link into a COM no errors.The program even runs correctly! Thanks for exercising my brain today and reminding me that PIP is still my favorite command of all time!!! ;)
I am curious why version 1.06D generated an ASM that then the AS command generated errors on out of the gate, yet version 1.05c generated an ASM that worked perfectly. That'll be tomorrow's project...Using the 8080 and z80 aztec 1.06D compilers on the simh altair simulator, the code compiles and runs without a problem, once the fprintf fix is done and the two header files that are not supplied with Aztec C, are removed.
Best,
-Mark
...
Note, using fread / fwrite / fputs rather than fprintf/ printf, reduces the executable size by nearly 15% and should be quicker. It also preserves null characters from the input file.
On 11/08/2023 10:22 pm, Mark Ogden wrote:It is not a bug.
...I know little about C. My interest was prompted after finding Forth's READ-LINE
Note, using fread / fwrite / fputs rather than fprintf/ printf, reduces the executable size by nearly 15% and should be quicker. It also preserves null characters from the input file.
ran slowly under CP/M. I wanted to see how C compilers under CP/M performed. Aztec C fgets proved to be 3x faster. I concluded it was due to the buffered I/O.
In contrast READ-LINE reads chunks at a time. If too much (most of the time) the
file pointer is shifted backwards for the next read. While not a problem under
MS-DOS, it's a performance killer under CP/M.
FWIW I noticed the Aztec C fgets/fprintf combo produced some unexpected results.
Unbeknown to me the source text file used included some 'foreign' characters with bit 7 set. These did not pass through correctly e.g.
E2 80 99
became
62 19
bug?
Other compilers e.g. Hitech C, do have open modes e.g. "rt" or "wt" to open a file as text and "rb" or "wb" to open as binary, implementing the differences beneath the covers.
Mark
On Sunday, 13 August 2023 at 04:29:01 UTC+1, dxforth wrote:
...It is not a bug.
FWIW I noticed the Aztec C fgets/fprintf combo produced some unexpected results.
Unbeknown to me the source text file used included some 'foreign' characters >> with bit 7 set. These did not pass through correctly e.g.
E2 80 99
became
62 19
bug?
Aztec C 1.06D does not have separate open modes for text and binary, but uses special functions e.g. agetc and aputc to handle text files.
Under the covers fgets calls agetc, which removes the top bit, detects 1A as EOF and also skips null and carriage return, hence the 80h is removed, as it becomes 0 when the top bit is removed.
Using fread/fwrite should avoid this, also using raw read/write with a buffer a reasonable multiple of the sector size, would avoid too many multiple buffer copies and should be the most performant.
Other compilers e.g. Hitech C, do have open modes e.g. "rt" or "wt" to open a file as text and "rb" or "wb" to open as binary, implementing the differences beneath the covers.
On 13/08/2023 5:43 pm, Mark Ogden wrote:I suspect is mainly due to history. It was not unknown for serial connected terminals to add a parity bit. As fgets is reading a line, rather than a binary stream, then removing the parity bit is not unreasonable. It would also have made reading
On Sunday, 13 August 2023 at 04:29:01 UTC+1, dxforth wrote:
...It is not a bug.
FWIW I noticed the Aztec C fgets/fprintf combo produced some unexpected results.
Unbeknown to me the source text file used included some 'foreign' characters
with bit 7 set. These did not pass through correctly e.g.
E2 80 99
became
62 19
bug?
Aztec C 1.06D does not have separate open modes for text and binary, but uses special functions e.g. agetc and aputc to handle text files.
Under the covers fgets calls agetc, which removes the top bit, detects 1A as EOF and also skips null and carriage return, hence the 80h is removed, as it becomes 0 when the top bit is removed.
Using fread/fwrite should avoid this, also using raw read/write with a buffer a reasonable multiple of the sector size, would avoid too many multiple buffer copies and should be the most performant.
Other compilers e.g. Hitech C, do have open modes e.g. "rt" or "wt" to open a file as text and "rb" or "wb" to open as binary, implementing the differences beneath the covers.If clearing bit 7 isn't a bug, perhaps a dubious feature :)
Hi Mark,In general C compilers for CP/M, MSDOS and Windows, treat the "t" modifier as the default. For Unix variants the modifiers are ignored, however processing CP/M or Windows text files on Unix variants has its own issues as the carriage return is passed
I'm using the version v3.09 of the HiTech C compiler.
Other compilers e.g. Hitech C, do have open modes e.g. "rt" or "wt" to open a file as text and "rb" or "wb" to open as binary, implementing the differences beneath the covers.
Mark... you're right about the "t" modifier (HiTech C considers 'text' mode as the default mode), but it has the "b" binary modifier (you can open a binary file using fopen(fname, "rb")
Ladislau
On Sunday, 13 August 2023 at 11:45:30 UTC+1, dxforth wrote:Wordstar documents straightforward, removing the top bits it used. It was only later that non ascii characters i.e. (80H-FFH) were more widely supported.
On 13/08/2023 5:43 pm, Mark Ogden wrote:I suspect is mainly due to history. It was not unknown for serial connected terminals to add a parity bit. As fgets is reading a line, rather than a binary stream, then removing the parity bit is not unreasonable. It would also have made reading
On Sunday, 13 August 2023 at 04:29:01 UTC+1, dxforth wrote:If clearing bit 7 isn't a bug, perhaps a dubious feature :)
...It is not a bug.
FWIW I noticed the Aztec C fgets/fprintf combo produced some unexpected results.
Unbeknown to me the source text file used included some 'foreign' characters
with bit 7 set. These did not pass through correctly e.g.
E2 80 99
became
62 19
bug?
Aztec C 1.06D does not have separate open modes for text and binary, but uses special functions e.g. agetc and aputc to handle text files.
Under the covers fgets calls agetc, which removes the top bit, detects 1A as EOF and also skips null and carriage return, hence the 80h is removed, as it becomes 0 when the top bit is removed.
Using fread/fwrite should avoid this, also using raw read/write with a buffer a reasonable multiple of the sector size, would avoid too many multiple buffer copies and should be the most performant.
Other compilers e.g. Hitech C, do have open modes e.g. "rt" or "wt" to open a file as text and "rb" or "wb" to open as binary, implementing the differences beneath the covers.
On 14/08/2023 12:59 am, Mark Ogden wrote:Wordstar documents straightforward, removing the top bits it used. It was only later that non ascii characters i.e. (80H-FFH) were more widely supported.
On Sunday, 13 August 2023 at 11:45:30 UTC+1, dxforth wrote:
On 13/08/2023 5:43 pm, Mark Ogden wrote:I suspect is mainly due to history. It was not unknown for serial connected terminals to add a parity bit. As fgets is reading a line, rather than a binary stream, then removing the parity bit is not unreasonable. It would also have made reading
On Sunday, 13 August 2023 at 04:29:01 UTC+1, dxforth wrote:If clearing bit 7 isn't a bug, perhaps a dubious feature :)
...It is not a bug.
FWIW I noticed the Aztec C fgets/fprintf combo produced some unexpected results.
Unbeknown to me the source text file used included some 'foreign' characters
with bit 7 set. These did not pass through correctly e.g.
E2 80 99
became
62 19
bug?
Aztec C 1.06D does not have separate open modes for text and binary, but uses special functions e.g. agetc and aputc to handle text files.
Under the covers fgets calls agetc, which removes the top bit, detects 1A as EOF and also skips null and carriage return, hence the 80h is removed, as it becomes 0 when the top bit is removed.
Using fread/fwrite should avoid this, also using raw read/write with a buffer a reasonable multiple of the sector size, would avoid too many multiple buffer copies and should be the most performant.
Other compilers e.g. Hitech C, do have open modes e.g. "rt" or "wt" to open a file as text and "rb" or "wb" to open as binary, implementing the differences beneath the covers.
It'd be interesting to know whether Manx persisted with this in later versionsThe 4.1B version of the z80 cross compiler, still has agetc and does not support the text/binary modifiers for fopen. However the agetc function no longer strips the top bit.
of the compiler. Hitech C fgets works fine with 8-bit characters.
On Monday, 14 August 2023 at 03:26:17 UTC+1, dxforth wrote:
...
It'd be interesting to know whether Manx persisted with this in later versions
of the compiler. Hitech C fgets works fine with 8-bit character
The 4.1B version of the z80 cross compiler, still has agetc and does not support the text/binary modifiers for fopen. However the agetc function no longer strips the top bit.
Note, it would be trivial to modify agetc.c to prevent the top bit being stripped in the 1.06D version, especially as the source is provided.
Mark
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 489 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 12:02:09 |
| Calls: | 9,665 |
| Files: | 13,712 |
| Messages: | 6,167,468 |