Jump to content

File pointers in CC65!


rje
 Share

Recommended Posts

7 minutes ago, rje said:

Not to mention (although you hinted at it) that avoiding printf can shrink the binary size.

True, though I suspect avoiding printf by using cprintf probably doesn't help the binary size much. I would think that they both use the same formatting code underneath and the only real difference is whether the screen is targeted or a file stream pointer.

If they do not share the exact same formatting code, then that only makes things worse, especially on memory constrained 8 bit platforms!

Link to comment
Share on other sites

Posted (edited)

It's actually a thing.  I checked out the memory dump files created by cc65 and I could see how many bytes are used by the presence of each function... and while a function might be only a few hundred bytes... well, it can add up.

/Users/rje/git/cc65/lib/cx16.lib(_printf.o):
    CODE              Offs=003D6C  Size=0003A5  Align=00001  Fill=0000
    BSS               Offs=000359  Size=00002B  Align=00001  Fill=0000
    DATA              Offs=0000FA  Size=000003  Align=00001  Fill=0000

933 bytes...

 

Meanwhile, cprintf is different...

/Users/rje/git/cc65/lib/cx16.lib(cprintf.o):
    CODE              Offs=004299  Size=00002A  Align=00001  Fill=0000
    BSS               Offs=000384  Size=000001  Align=00001  Fill=0000

Tiny.  As you suggest, perhaps it has its string formatter in a utility function... but printf has some extra oomph.

 

In short, if I replace the printf's with cprintf, then I get a 900 byte reduction.

Edited by rje
Link to comment
Share on other sites

"(_printf.o)" is the common formatter function that everything uses.

"(printf.o)" has the printf() function.  But, it calls "(vfprintf.o)", which calls "(fwrite.o)", which calls "(write.o)".

Edited by Greg King
Link to comment
Share on other sites

I was wondering what the difference was. I know that in cc65, cprintf() fails to scroll the screen and interprets \n as CR whereas printf() scrolls and interprets \n as CRLF. cprintf could probably stand to be fixed in its cx16 implementation....

Link to comment
Share on other sites

9 hours ago, ZeroByte said:

I was wondering what the difference was. I know that in cc65, cprintf() fails to scroll the screen and interprets \n as CR whereas printf() scrolls and interprets \n as CRLF. cprintf could probably stand to be fixed in its cx16 implementation....

Their philosophies are different.  stdio is stream-oriented, while conio is screen-oriented.

A stdio program is expected just to print and print and print and...  It cares little about the height of a screen.

A conio program is expected to stay on a single screen.  It reuses that screen's real estate.  It overwrites old text with new text.
That's why conio has ...xy() positioning functions.  It's why there are cclear... functions.  And, it's why carriage return and line feed are separate characters.  We can use carriage return to type and retype on the same line.

  • Like 1
Link to comment
Share on other sites

A lot of it depends on the platform you're targeting. stdio.h is one of the language mandated standard headers, so it is well defined what it should do. conio.h is a "quasi standard". Many platforms have it, but it isn't mandated by the bodies that say "this is what you must have in a C environment" so it will vary a lot more based on the platform. It's been a while since I used conio on DOS, but i seem to recall it *did* scroll the screen when it wrapped around the bottom line. But because it isn't standardized, there is no requirement that be the case.

Even the processing of CR & LF is not mandated by the standard. The systems based on posix will treat LF as and end of line character that both advances to the next line (what LF is defined to do in ASCII) and to the beginning of the line (what CR is defined to do). This provides more "flexibility" on DOS & Windows platforms (though maybe not the most useful depending on your point of view) but keeps lines "shorter" in posix because you only need a single character to mark the end of a line.

Once you move outside of the standard libraries, there is no requirement that they behave the same way.

Link to comment
Share on other sites

20 hours ago, rje said:

It's actually a thing.  I checked out the memory dump files created by cc65 and I could see how many bytes are used by the presence of each function... and while a function might be only a few hundred bytes... well, it can add up.

Yes, it can. My (perhaps poorly phrased) point was that the difference is not as big as you might think it would be otherwise.

If you write a program that only uses printf, and one that only uses cprintf, and another that uses both, you'd see that the incremental size for both includes overlap when functionality is shared (like a common formatting function that both can use).

Link to comment
Share on other sites

  • 1 month later...

I'd like to fopen() files in the native filesystem, i.e. not the mounted SD image, while I'm just writing code and testing things out.

I'm not sure that can be done, though.  Except by using the KERNAL functions I suppose.  Anyone?

 

Edited by rje
Link to comment
Share on other sites

On 9/30/2021 at 9:25 AM, rje said:

I'd like to fopen() files in the native filesystem, i.e. not the mounted SD image, while I'm just writing code and testing things out.

I'm not sure that can be done, though.  Except by using the KERNAL functions I suppose.  Anyone?

You mean the "host" file system. And I don't think that's possible. IIRC, the emulator used a hack to load files from the host file system in early versions of the emulator. I could be wrong on this, but my take was that rather than open a file and deliver the bytes to the KERNAL through an I/O port, the emulator just shoves data directly into guest RAM. 

 

 

Edited by TomXP411
  • Thanks 1
Link to comment
Share on other sites

That makes sense to me.  No worries, I have a work-around for my current project... I'll load a file into banked RAM and then operate on that data.  Maybe create a fake stream function, or not.

 

 

Edited by rje
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use