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

New site up and running

So after a whole lot of procrastination, I've finally put a web site together for the work I've been doing. This will mostly be for the TI code, but I'll post other stuff I'm working on from time to time.

Since older posts were written well before this blog was built, and written mostly for my own use, some explanation is called for.

For years, I've tried to come up with an interesting way to use my old TI99/4A, and eventually came up with the idea of rewriting the firmware to give more capabilities to the old hardware. I thought using some Unix-like concepts would be an interesting challenge. Things like multi-user or multi-tasking support are strangely lacking in a home computer from the early eighties.

The idea is to eventually rewrite everything: firmware, disk formats, executable formats, the works. This will probably be a very long process, and will eliminate compatibility with authentic TI software, but it should be a lot of fun.