Alternate printf and other questions for minimal RAM C programs

[cpiker]

One of the charms of programming for ELKS is seeing how small we can make useful but readable programs. Currently I'm doing the following to try and keep memory usage small:

• Don't embed huge help text in binaries, write a manual page instead
• Don't overly repeat text output words in code, use a string table (2 byte pointer versus an N-byte string)
• Use ia16-elf-gcc -melks for tighter code
• Avoid malloc when data structures are a fixed size so that I don't need a heap
• Use chmem to drop the heap and stack (though chmem won't let me drop the heap to 0)
• For simple utilities, it's usually okay to trade speed for memory. End user can wait longer, they can't plug in more RAM.

Even with these, I presume some libc calls are big, especially fprintf. I seem to recall seeing an alternate vfprintf somewhere in the kernel tree that leaves out some formatting options for a large space savings, but I don't think that is available in the elks ia16 libc... or is it?

Any links on generating tight C programs specifically for ELKS are appreciated. I've already inspected these:

• Documentation/index.html
• processes-and-memory
• tiny_vfprintf.c

I also noticed that the tiny model is not supported in ELKS, but since CS and DS can overlap, that's probably not a loss, assuming the kernel doesn't fragment memory.

Apologies for any dumb questions and improper assumptions. I've never worked on systems this constrained and never had to pay attention to details such as these. The environment is fascinating, but I am new to it.

The fact that I have a current telnet session open to an 8088, while also logged into the console is just too cool to ignore!

[floriangit]

The fact that I have a current telnet session open to an 8088, while also logged into the console is just too cool to ignore!

💯

[ghaerr]

I presume some libc calls are big, especially fprintf.

It's really not that big, but everything's relative.

I seem to recall seeing an alternate vfprintf somewhere

elkscmd/lib/tiny_vfprintf.c. It isn't in the C library directly as the names conflict with the larger printf; it can be specified explicitly when desired, as is done in several elkscmd/Makefiles.

Use ia16-elf-gcc -melks for tighter code

The -melks option is required for producing ELKS binaries. Generally, the -Os (optimize for size) optimization is also required, as others produce far too much code. Being an optimizing compiler, GCC normally produces both extremely small and fast code for the 8086.

I also noticed that the tiny model is not supported in ELKS, but since CS and DS can overlap

No, CS and DS are not allowed to overlap, since ELKS a.out executables support shared code segments.

that's probably not a loss, assuming the kernel doesn't fragment memory.

The kernel supports a best-fit algorithm when placing code, data or other segments, but memory can get fragmented depending on the order of execution, on systems with a high task workload.

though chmem won't let me drop the heap to 0

You can use a low number like 16 to effectively set the heap to 0.

Don't overly repeat text output words in code, use a string table (2 byte pointer versus an N-byte string)

This isn't usually required, because GCC combines multiple identical strings automatically.