Wow, it's been a while since I updated this. So I released a new set of patches, with really limited response. This makes me sad.

I've started making a C library to make development easier. This will also exercise the compiler a bit more.

I've noticed an annoying aspect of GCC, the divmod form is invoked for each div and mod operation. Even though the processor can compute both values in a single instruction, GCC does not take advantage of this. I found a comment on the GCC development forums where this is a problem for many archetectures.

Unfortunately, I'm not eager to change the internals of the compiler to accomodate the TMS9900. Even if it would make for better code, it would likely break forward compatibility.

Oh well.

I've noticed that R11 (return pointer) is incorrectly marked as a non-volatile register. This has been fixed, and R11 is still saved and resored as it should be. I've also doen a little cleanup.

I've also fixed all the bugs I can think of, so tomorrow would be a good time for another release.

All the stack stuff has now been fixed. Saved registers are pushed last onto the stack.

I've run the numbers on stack vs. nonvol reg usage. It turns out that it is better to use values in the stack if a nonvol value is used two or fewer times. For three or more ocurrances, it is better to use registers. Unfortunately, there is no good way to find the usage frequency or find out if it's used in a loop. Some of this info (usage count, not loop info) is stored in GCC, but not in a useful way. So I guess I'll just have to use non-volatiles as frequently as possible

The AtariAge people were concered about stack performance, and I was second-gussing myself, so I did cycle timings for 7 or eight different ways of stack setup and teardown. I'm glad I did his, since I found a form which saves 2 bytes and 12 cycles per call. I also found that there are problems with the current code.

For small nvreg usage, the old values are stored at the bottom of the stack. For large usage, the old values are stored a the top of the stack. The epiloge assumes old values are at the top of the stack. The stack offsets assume old values are at the top of the stack.

The faster form has the old values at the bottom of the stack. If I keep the old smaller form that means that the epilogue and the stack offset calcs will need to be changed. Ick. And the port documentation. Poo.

Also, stack-vs-nvreg calculations show that using the stack is smaller for less than three uses per function. It's faster too for less than five uses per function. So the allocator needs fixing too. Bah.

I've been super busy with work for the past week, so not a whole lot of TI work. I've updated the GCC port document, and annotized some examples.

During this work, I noticed a problem with function with arguments like (long, long, int, long). The last argument, which would spilll over into R7, is being lost. I'm not sure what's going on here.

The other thing I noticed is that non-volatiles were not bring used to store locals, everything was going to the stack. This seems to be a register cost balancing problem. I need to do the math to see where the break-even point is for non-vol versus the stack. This could be tricky.

I've submitteed patches to atariage, but I screwed up the patch file. I also noticed some bugs. For example, the data types were .byte and .short instead of byte and data. There were also some incompatibilities from the TI specs for the *si patterns. I've also chnaged the constants to use hex values instead of decimal values, this will make things easier to read.

So here's how patches are made:

diff -rupN {original} {modified} > patchfile

And to aply this file:

cd {path_to_original_files}
patch -p1 < patchfile

I now need to write docmumentation for the ABI, calling convention, and stack details.

GCC and Binutils patches

I wanted to post links to these patches on AtariAge, but their forum rules prevent creating a new topic which would make sense for this. So, I'm doing that here.

These patches will port the GNU tools to the TMS9900 processor. They use ELF-format for the object files. I have other tools to convert the resulting ELF executable to TI cartridge and memory image (EA5) formats. I don't have a converter for the TI linkable (EA3) format yet, but I'll probably get around to it. This is not a priority for me since I'm planning to use my own loader and do not intend to link to the TI routines anytime soon.

To the patches!

gcc-4.4.0-tms9900-1.0-patch.tar.gz

binutils-2.19.1-tms9900-1.0-patch.tar.gz