Making libraries in cc65

[ZeroByte]

At some point I'll be making some of my code into libraries and a recent thread about cprintf vs printf started talking about the code sizes of each. That got me thinking.

I notice that code modules seem to be loaded as "function.o" modules.

So does this mean that a good design for libraries is to make each function into its own separate source file? Suppose my library has 2 functions foo and bar.... If I had mylib.c containing both functions, and I used ar65 to make a library containing mylib.o - if a project uses foo but not bar, would bar get linked in anyway since it's in mylib.o?

To avoid this, should each and every function get its own .o file?

[Scott Robison]

That's a reasonable design for almost every platform (aka machine and toolchain). It really depends on just how advanced the toolchain tries to be.

By putting every function in its own source file, and including those in a library, the linker can include just the object files that have needed functions. But there is not a hard and fast rule that a linker should exclude unused functions (though I think most do). It could just say "you want stdio? I'm pulling everything in!"

Some toolchains are smart enough to write every individual function / declaration as a separately linkable entity, so it doesn't matter if you put everything in one file, it can still optimize the final file size by excluding unused pieces.

Where you're talking about cc65 and X16, then your plan is a sound one.

[Greg King]

You can go further.  If several of your functions use the same data or variables, in a way that doesn't conflict with each other, then you can put that data/variables into their own source files (those files might not have any code in them).  The idea is that your program won't have two copies of them even if that program is using two functions that need them -- it's less bloat.

[ZeroByte]

2 hours ago, Scott Robison said:

Some toolchains are smart enough to write every individual function / declaration as a separately linkable entity, so it doesn't matter if you put everything in one file, it can still optimize the final file size by excluding unused pieces.

I wonder if cc65's tool suite is smart like this - one might expect it to be, given the tight resources of 6502-based systems.

[Scott Robison]

1 minute ago, ZeroByte said:

I wonder if cc65's tool suite is smart like this - one might expect it to be, given the tight resources of 6502-based systems.

It could be, but I'll guess that it just uses the "individual file" approach. That's probably the very reason why their library is written that way to take advantage of "only link the object files used".

More than anything, I wanted to point out that not all toolchains are exactly alike.

[ZeroByte]

Not that it's hard to make a unique C / S file for every function (exported or not).

I suppose it would also make sense to have only the exported stuff (api calls, typedefs, structs, global variables, etc) defined in a common mylib.h / mylib.inc , and then have purely-internal h/inc files which #include the api header files and then go on to declare the internal utility functions/data structures that the API is not going to expose.

 

[ZeroByte]

related question: is there a command-line option for cc65 to compile and then assemble directly to .o files w/o having to first build .s and then run ca65 to assemble those .s files into .o files?

Or maybe a way to tell cl65 to stop at .o and skip the linking phase......

[Scott Robison]

cc65 has a number of different programs. cl65 is the "compile and link" driver that can do all the steps. The documentation says the -c command line option is probably what you want: "This option forces cl65 to stop after the assembly step. That means that C and assembler files given on the command line are translated into object files; but, there is no link step. Object files and libraries given on the command line are ignored."

[ZeroByte]

Hmmm that actually helps me with an issue I had with makefiles where Make was auto-inserting a -c no matter what I put in CFLAGS. I guess CC=cl65 would've fixed it...

[Greg King]

On 8/13/2021 at 11:00 AM, Scott Robison said:

Some toolchains are smart enough to write every individual function / declaration as a separately linkable entity, so it doesn't matter if you put everything in one file, it can still optimize the final file size by excluding unused pieces.

The LLVM linker works that way.