I was comparing performance against CP/M C compilers but unable to compile
for Aztec-C.

The distribution/demo EXMPL.C compiles fine:
http://www.retroarchive.org/cpm/lang/az106d.zip

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.

#include "stdio.h"
#include "string.h"
#include "stdlib.h"

main()
{ char buf[128];

FILE *fp1;
FILE *fp2;
fp1 = fopen("foo.txt","r");
fp2 = fopen("bar.txt","w");

if(fp1 == NULL || fp2 == NULL)
{
printf("\nFile error");
exit(0);
}

while(fgets(buf, sizeof(buf), fp1) !=NULL)
{
fprintf(fp2, "%s", content);
}

printf("\ndone");

fclose(fp1);
fclose(fp2);
return 0;
}

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?

--
Nils M Holm < n m h @ t 3 x . o r g > http://t3x.org

On 9/08/2023 12:25 am, Nils M Holm wrote:
> 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?
>

Via the undocumented ARCV.COM program? It crossed my mind but nothing I
tried worked.

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>

--
Take Back Control! -- Mesh The Planet!
I do not play Nethack, I do play GNUS! o;-)
Solid facts do not need 1001 pictures.

On 9/08/2023 2:46 am, yeti wrote:
> 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.

Well that's weird because now it works.

> 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>

The PDF file I had included only a few bookmarks. A while back I went
through and added the missing ones. It's here should anyone want it:

https://drive.google.com/drive/folders/1kh2WcPUc3hQpLcz7TQ-YQiowrozvxfGw

yeti <yeti@tilde.institute> writes:

> 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>

Typical magic: I need to ask to trigger finding it...

That one has search ability added:
<http://bitsavers.org/pdf/manx/Aztec_C_CPM_1.06_User_Manual_Mar84.pdf>

--
Take Back Control! -- Mesh The Planet!
I do not play Nethack, I do play GNUS! o;-)
Solid facts do not need 1001 pictures.

Now you all got my curiosity up. <GRIN>

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 thing, I decided to stop that program and give this a try...

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...

Best,
-Mark

On Tuesday, 8 August 2023 at 23:26:14 UTC+1, Mark Lawler wrote:
> Now you all got my curiosity up. <GRIN>
>
> 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 thing, I decided to stop that program and give this a try...
>
> 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...
>
> Best,
> -Mark
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.
The same applies using the MSDOS hosted cross compilers.
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.
In terms of raw performance, using a bigger buffer size (power of 2 e.g. 4096) and using rawio, i.e. open, read, write and close is most likely to offer the best performance and probably the smallest code.

Mark

On 11/08/2023 10:22 pm, Mark Ogden wrote:
> ...
> 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.

I know little about C. My interest was prompted after finding Forth's READ-LINE
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?

On Sunday, 13 August 2023 at 04:29:01 UTC+1, dxforth wrote:
> On 11/08/2023 10:22 pm, Mark Ogden wrote:
> > ...
> > 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.
> I know little about C. My interest was prompted after finding Forth's READ-LINE
> 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?
It is not a 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.

Mark

Hi Mark,

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 13/08/2023 5:43 pm, Mark Ogden wrote:
> On Sunday, 13 August 2023 at 04:29:01 UTC+1, dxforth wrote:
>> ...
>> 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?
> It is not a 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 :)

On Sunday, 13 August 2023 at 11:45:30 UTC+1, dxforth wrote:
> On 13/08/2023 5:43 pm, Mark Ogden wrote:
> > On Sunday, 13 August 2023 at 04:29:01 UTC+1, dxforth wrote:
> >> ...
> >> 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?
> > It is not a 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 :)
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 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 09:13:49 UTC+1, ladislau szilagyi wrote:
> Hi Mark,
>
> 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
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 through on input.

For all compilers replicating carriage return, followed by multiple line feeds, as was common for line printer interfacing, is more challenging to implement. For CP/M, MSDOS and windows writing in binary mode is an option, however although Unix variants can write the characters to a file, if writing directly to a device, the auto expansion of "\n" to "\r\n" needs to turned off.

On 14/08/2023 12:59 am, Mark Ogden wrote:
> On Sunday, 13 August 2023 at 11:45:30 UTC+1, dxforth wrote:
>> On 13/08/2023 5:43 pm, Mark Ogden wrote:
>>> On Sunday, 13 August 2023 at 04:29:01 UTC+1, dxforth wrote:
>>>> ...
>>>> 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?
>>> It is not a 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 :)
> 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 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.

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 characters.

On Monday, 14 August 2023 at 03:26:17 UTC+1, dxforth wrote:
> On 14/08/2023 12:59 am, Mark Ogden wrote:
> > On Sunday, 13 August 2023 at 11:45:30 UTC+1, dxforth wrote:
> >> On 13/08/2023 5:43 pm, Mark Ogden wrote:
> >>> On Sunday, 13 August 2023 at 04:29:01 UTC+1, dxforth wrote:
> >>>> ...
> >>>> 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?
> >>> It is not a 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 :)
> > 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 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.
> 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 characters.
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

On 14/08/2023 7:39 pm, Mark Ogden wrote:
> 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

I went ahead and made the change - if only to satisfy modern expectations.