Thursday, December 24, 2009

There's been more planning and thinking than actual work lately. I've reached a point where I'm not sure what to work on next. I think the next items are going to be heap managent or process management, file interface or something like that.

I've changed the ABI to make R13, R14 and R15 non-volatile. This was done to make blwp and xop reasonable to use. I was working on the system call interface, and was annoyed by the amount of work needed to make the system work if those registers were kept as volatile. R12 has been made volatile to support easy CRU operation. Originally, that was a non-volatile register. using CRU instrustions incurred a similar level of annoyance. So now the register usage looks like this: R0-R8,R12 are volatile, R10,R11, R13-R15 are non-volatile. Basically, all special-purpose registers are non-volatile except R12. R9 has no special purpose, but I figured I should keep it non-volatile anyways.

As mentioned above, I've added a system call interface to the project. It doesn't actually do anything useful, but it works. I keep thinking that if I restrict the *print* calls to the system call interface, I can save 120 bytes. I'll make a final decision on this later.

I'm currently looking at heap management algorithms, so I guess that will be next.

Just for the heck of it, I've been thinking about a wolf-3d clone for the TI. I'm not sure if I'll actually do it, since I've got a lot going on right now, but it willl give me a better idea of what real-world programs will need.

I've also been thinking about writing a compiler best-practices guide as I continue working. I keep going back to Tursi's GCC port and his misguided insistance on a zero register, At some point I would like a C compliler, and I would like it to be good.

Monday, December 14, 2009

Not a whole lot of work done, but I have been working on documentation lately. I've put together some notes on dynamically-loaded libraries, and system calls in general. I think it could work, and thinking down these lines is helpful for later.

I've also put together some notes for my modifications to the GAS assembler. I was thinking about the fact that I don't have an Editor/Assembler manual, and that it would probably help to ask around to get the missing pieces. In order for someone else to see my gaps, I need to document what I have so far.
The assembler documentation is very sparse, but I think it's a decent start.

While digging around for more info, I found the "nop" and "rt" pseudo-ops in example code in a couple places, so that seems legitimate. "Nop" is encoded as "jmp 0" and "rt" as "b *r11". While I was in there, I added "or" and "orb" as aliases for "soc" and "socb" since I can't ever remember the real instructions.

I had problems adding these instructions, since I made a dumb mistake in the parser. I was assuming there was an argument, and skipping the intervening space. This resulted in skipping the null terminator for the line, and getting "junk at end of line" errors. This has been fixed.

Saturday, December 12, 2009

So last night I finally had time to finish the decimal printing routines. Along the way I found I had really misunderstood the function for the DIV instruction. I had thought that the OV flag would be set when the resulting quotient was zero. Looking back on the references, I can't see where I ever got that idea.

The *printf* routines take 446 bytes, not too bad, but I would have liked it to be smaller. Also, the stdio.asm file is a mess. It works, but there is little organization, and the layout is poor, with unnecessary B instructions.

I should start thinking about making a user-callable library for syscalls or somethihng. I don't want to go too far down the road of assuming a single-user, single-tasking environment. That works for now, but will all need to be ripped up later.

Honestly, a good chunk of the code (126 bytes) is encoding flags to discriminate the *print* forms.