Jump to content
IGNORED

GCC for the TI


insomnia

Recommended Posts

GCC optimization levels

-----------------------

The optimizer doesn't really know how to generate fast code. It can optimize for size, algorithmic complexity, combine constants, and move constant expressions out of loops, inlining. You get the idea. These things will typically generate fast code, but this is not guaranteed. Also, GCC has no way of counting cycles or taking advantage of the speed of the scratchpad memory.

Actually, that's not what I meant.

You have access to the optimization settings and if it were beneficial, you could use faster or smaller stack code generation based on those settings.

 

 

Scratch pad memory usage

------------------------

I think it's safe to say you'd want the registers in scratchpad memory by default. The C stack is usually too large for that so you could only place it there for small programs. Since most variables are in the stack area it could make a significant speed difference.

 

I'm not familiar with the TI memory map but I *suppose* if scratchpad memory were part of a larger contiguous block of RAM you could put the registers at the top of scratchpad mem and the stack right below them. If the size of the stack exceeded scratchpad it could grow down into regular RAM. However, the inner loops where the stack is greatest usually need the most speed so that might not add up to the fastest executable.

 

If you knew the maximum size of the stack, you could place the stack where it would grow down into scratchpad memory for inner loops just as long as you couldn't overwrite your registers at the bottom of the scratchpad area. This would be set up by the startup code and would be application specific. I think using scratchpad in one of those manners makes much more sense than allocating it through a call.

 

Keep in mind if you use global or static variables for a lot of things like temporary values or commonly used structures, you could conserve scratchpad memory and improve the performance of your application.

Edited by JamesD
Link to comment
Share on other sites

  • 3 weeks later...

Well, it's time to release a new set of patches. This time I've made sure they are usable (I'm still upset about that)

 

Anyway, here's the bugs that got fixed for the GCC port:

 

1) Convert decimal constants to hex

This was a request a while back, and helps make the emitted assebly a bit easier to read.

 

2) Add "C *Rx+, *Rx+" optimization for 16-bit "+=4" operations

Yes, I shamelessly stole this from nouspiekel.com

 

3) Fix non-volatile register allocation

There was a bug in the allocator, which prevented non-volatile registers from ever being used. Instead, the stack was always used to store non-volatile values.

 

4) Optimize call pro/epilogue, make stack usage consistant

5) Saved registers at bottom of stack frame

There were some notes about this in earlier posts. I also noticed that in some cases, the saved registers would be pushed onto the stack first. In other cases, they would be pushed last. This didn't affect the functionality of the code, but it did make things confusing.

 

6) R11 no longer falsely marked as non-volatile register

R11 was considered a non-volatile register. but it makes more sense to consider it as non-volatile. Think about it this way: If a called function itself calls a function, R11 (the return pointer) will point to the address after the BL instruction. In order to treat R11 as a true non-volatile register, it would have to be saved and restored around all function calls on the caller side. This seems dumb. R11 is now considered non-volatile, but is saved in the function prologue, and restored before the function exit.

 

7) The last argument for functions like f(long a, long b, int c, long, d) were lost

The register allocator did not properly treat 32-bit quantities (stored in two consecutive registers), so the last argument, which would require more registers than are available, was lost. The allocator is smarter now.

 

 

 

 

Building from source

====================

 

Obtaining the base packge

---------------------

The GCC port to the TMS9900 provessor is based on GCC 4.4.0. It can be obtained

from gcc.gnu.org. THis version of GCC was released in April of 2009, and many ve

rsion have since been released. There is a good possibility that the TMS9900 pat

ch will work with a newer release, but this has not been tested. Proceed at your

own risk.

 

 

Patching for the TMS9900

------------------------

Once the source archve has been downloaded, extract the files to the directory

of your choosing. It is recommended that this be a different place than the

directory in which you intend the resulting binaries to be loacted. This will help

eliminate confusion, and make upgrading to later versions simpler.

 

Once the archinve has been expanded, run this command from the top-level

directory of gcc:

patch -p1 < gcc-4.4.0-tms9900-1.1.patch

 

 

Building GCC

------------

GCC will be configured to build only the C compiler. The other GCC languages are

available, and may work, but have not been tested. Object-oriented languages,

like C++ or Java are not likely to work since their constructores will be placed

in a .init section which will require additional processing by the linker.

Execute these commands to build and install the GCC tools. Be sure to replace

INSTALLDIR with your intended installation path.

 

./configure --prefix INSTALLDIR --target=tms9900 --enable-languages=c

make all-gcc

make install

 

 

Patching Binutils

-----------------

Binutils is patched using the same steps as GCC.

 

 

Building Binutils

-----------------

The build process for Binutils is more involved than for GCC.

Execute these commands to build and install the GCC tools. Be sure to replace

INSTALLDIR with your intended installation path.

 

$ ./configure --prefix INSTALLDIR --target tms9900

$ cd bfd

$ make all

$ cd ..

$ make all

$ make install

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

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

  • Like 1
Link to comment
Share on other sites

Just sent the link to this topic to the Y! group. This needs to be tested and played with by people more knowledgable than I. I know this can be the start of a huge amount of new software for the TI... I wish I knew enough to speak intelligently on this subject, because it's THIS exact thing I have been hoping for. Let's see what kind of interest we can drum up!

Link to comment
Share on other sites

  • 3 months later...

I had some difficulty building this... but then it's GCC so I'm not too surprised. :) I got the specified versions of GCC (using GCC-Core) and Binutils, and built under Cygwin. Your patches applied cleanly and only a couple of steps broke.

 

For one, I had to manually "make elf32-header.h" -- I'm not sure why but that got me through binutils/bfd.

 

The rest of the build seemed okay, but libiberty gave me all kinds of issues on the make install for GCC

 

I should note that I couldn't make your steps work.. I fell back on a really old instruction set that I've used for years at Hitmen's page (it was meant for doing an SH4-cross, I just made the changes to tms9900 and didn't hack the GCC makefile).

 

On the plus side, you seem to have done really well! All the tools built, which is worlds farther than my attempt got.

 

I created this test program:

 

int main() {
 volatile int y=10;

 return y+15;
}

 

This got a syntax error from the assembler:

 

test.s: Assembler messages:

test.s:13: Error: missing comma seperator

 

Test.s looks like this (and it is missing the , on line 13):

 

	pseg

def	main
main
ai r10, >FFFC
mov r11, @2(r10)
mov r10, r8
li r1, >A
mov r1, @2(r8)
mov @2(r8), r1
ai r1, >F
mov *r10, r11
c *r10+ *r10+
b *r11

 

Unless I'm reading this wrong, I think there's a bug in the output code. It looks like the return address and the y variable are both stored at the same address on the stack. (Note that because I declared the variable as volatile, the optimizer is not allowed to simplify access to it, this way all the code is output ;) ).

 

Assume on entry that R10 (stack pointer) is >3FFE:

 

main
ai r10, >FFFC    -> R10-4 = >3FFA
mov r11, @2(r10) -> Return address to >3FFA+2 = >3FFC
mov r10, r8      -> Save stack pointer in R8 (frame pointer) = >3FFA
li r1, >A        -> R1 (temp) = 10
mov r1, @2(r8)   -> Save R1 at R8+2 = >3FFA+2 = >3FFC (same as return address)
mov @2(r8), r1   -> Get value at R8+2 = >3FFA+2 = >3FFC, value is 10 (not bug! Variable is volatile)
ai r1, >F        -> Add 15 to the value, result is 25
mov *r10, r11    -> Get value at R10 into R11, R10 = >3FFA - not same address as return was written to!
c *r10+ *r10+    -> Add 4 to R10 (reset stack pointer) - syntax error due to no comma but code is correct
b *r11

-> Return to caller

 

I made a second version with a subroutine to see if it was a bug pertaining to main() only (just in case), but identical code is generated. I did a quick search to see if I could see where either code was generated. Now, it IS late and maybe I'm reading it wrong... ;)

 

When I correct the syntax error, the assembler runs, but because of the issues with libiberty I don't have a libgcc so it can't link.

 

Anyway, just wanted to report my results and see if you had any new patches available, since it's been a while! :)

 

 

 

 

Regarding your comments above, about coding the 9900 for speed or size, one thing to remember about the TI-99/4A is that the system is intensely memory-bound, due to the 8-bit multiplexer. As a result, smaller code tends to be faster than even very clever larger code almost every time just for the instruction fetch overhead, with the sole exception being code running in scratchpad RAM where there are no waitstates, and my experience is that 9 times out of 10 smaller code is faster there, too.

Link to comment
Share on other sites

First off, thanks for your interest in this. Even though I'm trying to be thorough, mistakes happen, and it's great to get a second look at things.

 

I've seen the missing comma bug you found. It's the result of a typo in the tms9900.md file for a peephole optimization. That fix will be in the next patch. Here are some other things that will make that patch:

 

Divide and modulus operations now merged when possible

 

Fix data symbol declarations, now TI compliant (The current code worked fine with the modified binutils assembler, but was invalid for any other assembler)

 

Fix "+=4" form, was missing comma in emitted code (Your first bug)

 

Fix alignment of code, in some cases it was possible to misalign code by using odd-length string constants

 

Your second problem (different save and restore addresses) really worries me. My GCC environment is currently in shambles and in no condition to confirm or fix what you found.

 

I'm also going to have to stall on the build procedures. I've tried to make sure I didn't skip any steps, but apparently I did. Once I get my environment back together I can get a better procedure out.

 

In my absence, I've been going in a couple different directions:

 

Working on a libc library for the TI

 

Playing around with the idea of reimplementing Basic calls in C form to ease the transition from basic to C for basic-only programmers.

 

Research and framework for a IEEE-compliant floating point library

 

Research on 16-bit floating point representation (goggle for "half" floating point format)

 

And the big time sink: restructure the register lifetime calculation in GCC to allow for the faster INV and ABS comparisons if the test value can be safely destroyed. This is turning out to be a lot more work that I expected, and is the reason my GCC environment is messed up. It's currently full of test and debug code which breaks when run against general-purpose code.

 

I guess the short version of all this is "I really appreciate your working with my code, and hang on a bit, help is on the way"

Link to comment
Share on other sites

That's a brilliant update, Insomnia. Thanks very much for your hard work on this project.

 

I am particularly interested in the floating point stuff, as I would like to add FP to TurboForth (as a loadable library) - I need to get a handle on how it all works first. I've done my fair share of googling, but most (all?) of the stuff I have read was meaningless scientific mumbo-jumbo to me. I was want a 'here's what each bit in a word means in FP' type of description, and a discussion of how to manipulate the bits for an add and a subtract.

 

Anyway, rant over...! And thanks again!

Link to comment
Share on other sites

Unfortunately I needed a compiler this week (the TI Faire is in just 10 days!!) Do keep up your work but unfortunately I won't be able to help as much as I expected to, at least not right now. So the pressure is off for now! (I might still be able to use it to save myself some time if I can find the prologue bug. Been about a year since I dug into GCC so I have to remember how to find that code ;) - I will take a peek this week). If you can show me where to fix the +4 comma bug, that would really help me too. :)

Link to comment
Share on other sites

I was want a 'here's what each bit in a word means in FP' type of description, and a discussion of how to manipulate the bits for an add and a subtract.

 

http://en.wikipedia.org/wiki/Floating_point

 

It is all there, however, there is nothing easy about IEEE binary floating point. Also, you absolutely must understand that BINARY floating point can NOT be used for money math, and should not be used where an exact number representation is required. IMO having binary floating point easily accessible in languages like C, Java, etc. is a mistake because people do not understand what the variable types really are; just ask these dead soldiers: http://www.ima.umn.edu/~arnold/disasters/patriot.html

 

Not having easy access to binary floating point forces people to "fake it", and they come up with a form of a DECIMAL representation which is ultimately what they probably wanted in the first place, and is a "good thing". I believe TI's base-100 floating point is a decimal floating point representation, but I need to confirm that. I recommend reading this website:

 

http://speleotrove.com/decimal/

http://speleotrove.com/decimal/decifaq1.html

 

Binary floating point has its uses, like calculating very large or very small quantities (like stars or atoms) where absolute "accuracy" is not required, or the speed of a sprite, etc. However, when you go to the bank or are being protected by a Patriot missile battery, you absolutely do not want them using binary floating point.

 

I have two strong opinions about this whole mess:

 

1. *ANY* one who considers themselves a professional programmer should know the difference between binary and decimal floating point (and heaven forbid that there are any professors teaching in universities who don't know), and when to use one over the other.

 

2. *ANY* language that offers the binary floating point types, float and double, should also have decimal floating point types, if only to force awareness on the programmer and make them select the correct data type for their application.

 

End of Line.

 

Matthew

  • Like 1
Link to comment
Share on other sites

Excellent points Matthew.

 

I really only learned this yesterday, whilst reading up on Wikipedia. Explains why VB has an actual Currency data-type.

 

It appears to me, that on resource constrained systems, one is better off with either fixed point, or even BCD or Packed BCD (if working in decimal). Not only can they yeild perfect accuracy (well, in the case of BCD) but the code to manipulate and perform arithmetic isn't too hard to understand. When one can understand, one can optimise ;-) I hate using code that I don't understand, requiring blind-faith... Far better to have a good understanding of it, obviously.

Link to comment
Share on other sites

Tursi:

 

The +4 bug can be found at gcc/config/tms9900/tms9900.md line 1023

 

This is in the addhi3 recipe, and the error gets invoked if a 16-bit ADD operation is called for when one of the addends has a constant integer value of four.

 

(define_insn "addhi3"
 [(set (match_operand:HI 0 "general_operand" "=rR>,Qi,r,rR>,Qi")
(plus:HI (match_operand:HI 1 "general_operand" "%0,0,0,0,0")
	 (match_operand:HI 2 "general_operand" "rR>LMNOP,rR>LNMOP,i,Q,Q")))]
 ""
 "*
{
 if (GET_CODE (operands[2]) == CONST_INT)
   {
     if (INTVAL(operands[2]) == 1)
return \"inc %0\";
     else if (INTVAL(operands[2]) == -1)
       return \"dec %0\";
     else if (INTVAL(operands[2]) == 2)
       return \"inct %0\";
     else if (INTVAL(operands[2]) == -2)
       return \"dect %0\";
     else if (INTVAL(operands[2]) == 4)
       return \"c *%0+ *%0+\";
     else
       return \"ai %0, %2\";
   }

 return \"a %2, %0\";
}"
 [(set_attr "length" "1,2,2,2,3")])

 

The existing line:

return \"c *%0+ *%0+\";

Should be:

return \"c *%0+, *%0+\";

 

I confirmed your results with the wrong load address for the return pointer, but I've been busy with work and don't have a fix yet.

 

The prologue and epilogue code is located in gcc/config/tms9900.c in functions tms9900_expand_prologue and tms9900_expand_epilogue. I'm looking into these now.

 

From the reaction here, I really should put the register lifetime changes on hold for now and crank out a new patch and procedures. Stay tuned.

 

Matthew:

I agree that professional programmers need to be aware of the limitations of any floating point implementation (even decimal floats), but remember that most people here are probably not professional programmers. Floating-point numbers are sometimes just the most direct tool available to solve a problem.

 

Honestly, I've only had a few projects where floats were appropriate. Usually fixed-point notation was the better choice due to precision, speed or size concerns. But using fixed-point numbers requires even more knowledge of the numbers which will be used. It's an easy way to get overflows, quantisation errors or other nonsensical results as the data's required precision butts up against the limits of the representation.

 

I just started looking at floats because I thought TI's implementation ate a lot of memory, and I thought I might be able to do better now.

Link to comment
Share on other sites

Excellent points Matthew.

 

I really only learned this yesterday, whilst reading up on Wikipedia. Explains why VB has an actual Currency data-type.

 

As well as COBOL, Java, PHP (with a library) and any RDBMS that is worth anything. Remember, C was designed to write operating systems.

 

It appears to me, that on resource constrained systems, one is better off with either fixed point, or even BCD or Packed BCD (if working in decimal). Not only can they yeild perfect accuracy (well, in the case of BCD) but the code to manipulate and perform arithmetic isn't too hard to understand.

 

All true. I know Packed BDC is what COBOL uses, and I'm sure many languages and databases that offer "currency" types use a form of BCD. The decimal floating point library I linked to in my previous post uses a form of Packed BCD.

 

When one can understand, one can optimise ;-) I hate using code that I don't understand, requiring blind-faith... Far better to have a good understanding of it, obviously.

 

Well, modern CPUs have native binary floating point registers and ALUs, so languages can offer those types for free and really not have to worry about how they work, except for a few specific function calls to display the numbers. Heck, modern CPUs will even convert from binary floating point to integer, and integer to binary floating point.

 

Matthew

Link to comment
Share on other sites

Matthew:

I agree that professional programmers need to be aware of the limitations of any floating point implementation (even decimal floats), but remember that most people here are probably not professional programmers. Floating-point numbers are sometimes just the most direct tool available to solve a problem.

 

Yeah, sorry, my rant was more general than specifically targeting your project or anyone here. I work with a bunch of "professionals" who are writing programs in C that work with money, and they don't realize you can't use a double for such things. It just gets me worked up.

 

Honestly, I've only had a few projects where floats were appropriate. Usually fixed-point notation was the better choice due to precision, speed or size concerns. But using fixed-point numbers requires even more knowledge of the numbers which will be used. It's an easy way to get overflows, quantisation errors or other nonsensical results as the data's required precision butts up against the limits of the representation.

 

Agree. The more I understand binary floating point the more I don't like it. I believe the history of the format was to make floating point faster on binary computers. Until then (late '50s early '60s) computers did decimal floating point, but for scientific work it was too slow. Something like that anyway.

 

Programmers use them (floats and doubles) because they are available, but they don't understand the data type.

 

I just started looking at floats because I thought TI's implementation ate a lot of memory, and I thought I might be able to do better now.

 

Well, TI used 8 bytes, like a double. I've glossed over the E/A pages describing the format, but I was not reading for comprehension. I can tell you this, BASIC uses TI-FP to pass parameters to assembly, and the format is easy enough that I was able to pull integer values from the passed variables without using the ROM conversion routines (I did this while making the sound player for Owen.) Also, there are ROM routines for working with TI-FP, so maybe you could take advantage of that?

 

By the way, your project and efforts are much appreciated! I'd get more involved, but I'm up to my neck in self-proclaimed projects already, and I need to get sprites working on my F18A video chip. :-)

 

Matthew

  • Like 1
Link to comment
Share on other sites

The +4 bug can be found at gcc/config/tms9900/tms9900.md line 1023

This is in the addhi3 recipe, and the error gets invoked if a 16-bit ADD operation is called for when one of the addends has a constant integer value of four.

 

Beautiful, thank you for the starting points. I expect I will get to play with this tommorrow and will see if I can get my copy generating functional code. :)

Link to comment
Share on other sites

1. *ANY* one who considers themselves a professional programmer should know the difference between binary and decimal floating point (and heaven forbid that there are any professors teaching in universities who don't know), and when to use one over the other.

 

Matthew

 

I did - and then I didn't. Now I do again.

Link to comment
Share on other sites

  • 3 weeks later...

Well, it's patch time again.

 

Here's what made it into this release:

 

Bintils

Allow TI-style quotes ('example')

Allow two-byte character constants for immediate expressions (li r0, 'ab')

Fix a BFD Makefile bug which prevented clean compilation

 

GCC

Fix tms9900_output_ascii, was emitting invalid code when non-text characters were used

Divide and modulus operations now merged when possible

Fix data symbol declarations, now TI compliant

Fix "+=4" form, was missing comma in emitted code

Fix alignment of code, in some cases it was possible to misalign code by using odd-length string constants

Fix stack frame load/save differences, was using different locations between function prologue and epilogue in some cases (Thanks Tursi!)

Save return pointer at bottom of stack. This may help for later stack trace construction

Add optimizations for compare-and-branch operations with 16-bit values against -2, -1, 0, 1, and 2.

 

Right now I only have optimizations for equality tests with -2, -1, 1, and 2 done. To get inequality tests, I need to convince GCC to emit tests against the overflow flag. GCC has no concept of this kind of instruction, so I need to play with that a bit more.

 

The other weakness is the divide and modulus instructions. I haven't been able to convince GCC to use convenient registers for the source and destination. This means that in some cases, I need to insert additional MOVs which really shouldn't be necessary. More playing around required here too, I suppose.

 

I've addressed all the problems Tursi found earlier, plus a few others. Unfortunately, libiberty is not on that list. Since a lot of those routines are OS-specific, and since there is no POSIX-like interface for the TI, these functions are of limited use right now. In the future that might change. (hint, hint)

 

So here's the build procedure for everything. I've made sure these have been tested several times. There should be no problems following them.

 

 

Patching the original files:

$ cd binutils-2.19.1

$ patch -p1 < binutils-2.19.1-tms9900-1.1.patch

 

$ cd gcc-4.4.0

$ patch -p1 < gcc-4.4.0-tms9900-1.2.patch

 

Building binutils

$ ./configure --target tms9900 --prefix INSTALLDIR

$ make all

$ make install

 

Building GCC

$ ./configure --target=tms9900 --prefix=INSTALLDIR --enable-languages=c

$ make all-gcc

$ make install

 

Notice that GCC uses equals after the options, while binutils does not. Kind of annoying and easy to mix up. At this point, you will have all the GNU compilation tools ready to use for TI work. The binary format is ELF, since that stores the extra data needed by the linker and other tools. In earlier posts I've attached code to convert from ELF to TI-cart format. I've also got prototype converters for EA5 and EA3 formats too, but I haven't tested them very much.

 

When compiling with GCC, I recommend using the -O2 and/or -Os options to reduce the overall code size. Using the default options can result in extra wordy code with unnecessary or duplicate instructions.

 

There's still quite a bit of work left to do for GCC, so there will be more patches coming. I need to fill out the missing math support for 32-bit values, make sure signed multiply and divide work, and the other stuff mentioned above. I especially want to add more optimizations to the compiled output, but that will come as I get more familiar with what instruction patterns GCC likes to use.

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

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

  • Like 1
Link to comment
Share on other sites

I just visited your "Imsomnia Labs" blog and was impressed :)

It makes a very interesting read.

 

Wouldn't it be great to have the vi editor running on the TI-99/4A ?

Even though I don't see any practical use, that would be very cool :P

 

hhmm, can hardly think a regexp engine would fit in the TI's memory?

Link to comment
Share on other sites

I just visited your "Imsomnia Labs" blog and was impressed :)

It makes a very interesting read.

Thanks, I've always enjoyed reading other peoples project blogs, and I was hoping someone would find mine interesting.

 

For a long time I've made it a point to keep a record of what was done for each day of a project. That makes it easier to review past progress and see if there was some feature or design idea that got overlooked or backed out for some reason. Additionally for this project, there have been periods of a few weeks or so where it had to be put on the back burner. Having a record of what state things were left in is really helpful to get back on track after being away for a while.

 

Wouldn't it be great to have the vi editor running on the TI-99/4A ?

Even though I don't see any practical use, that would be very cool :P

 

hhmm, can hardly think a regexp engine would fit in the TI's memory?

 

Probably not. It might be fun to try and squeeze one in there though.

 

By the way, if no one's run across this, check out the Contiki Operating System. This is a multitasking OS with a full IP stack and windowing system, built into 40K of ROM and 2K of RAM.

 

I'd love to build up to something like that for the TI. But first thing's first...

Link to comment
Share on other sites

By the way, if no one's run across this, check out the Contiki Operating System. This is a multitasking OS with a full IP stack and windowing system, built into 40K of ROM and 2K of RAM.

 

Yeah, we've covered Contiki on the Yahoo group countless times... it was one of the projects I examined when I first started my ethernet project back in 200?. But lack of a decent C compiler prevented progress. You may be able to fix that. ;)

 

One of the things I didn't like was the need to recompile all programs. I sort of wish they included a byte code so you could just run the app regardless of platform. ;) But again, a decent compiler reduces that pain. ;)

Edited by Tursi
Link to comment
Share on other sites

  • 1 month later...
  • 2 weeks later...

Well, I haven't been very productive lately, what with Christmas and all, but here's what I've been up to:

 

I'm still working on libc support, and have a few functions done:

 

strchr, strpbrk, memchr, strcmp, strrchr

memcmp, strcpy, strspn, memcpy, strcspn

strstr, memmove, strlen, strtok, memset

strncat, strncmp, strcat, strncpy

 

Here's the GCC features done since the last release:

 

Add optimisation to remove redundant moves in int-to-char casts

Remove invalid CB compare immediate instruction

Add optimisation to restore byte immediate comparison

Added optimisations for forms like (byte)X=(int)X>>N

Remove invalid compare immediate with memory

Improved support for subtract immediate

Fixed bug causing gibberish in assembly output

GCC recognises that bit shift operations set the comparison flags

 

I've also improved the error handling in the GAS assembler, so the messages are more helpful

 

Stuff I'm working on at the moment:

 

Make sure that the low byte of registers are not accessed directly. This happens because I'm lying to GCC. I told it that the TMS9900 actually has 32 8-bit registers, but can only use the even-numbered ones for byte values. Sometimes it gets confused, and tries to use the fake, odd-numbered ones instead. I think I have a fix, but I'm still testing.

 

I recently tried -O1 optimisation to see what would happen, and the compiler crashed. I'm still trying to figure out why.

 

I'm planning on doing more libc work, testing, and more optimisations. With any luck, there will be enough changes by January to make another GCC release worthwhile.

  • Like 1
Link to comment
Share on other sites

Very impressive work and I like reading your blog :)

 

So do you mind sharing some more information:

 

Where you involved with compiler stuff and 9900 assembly language before you got into the gcc conversion project?

Because that sure doesn't look like an easy project to tackle, especially considering the optimisation stuff your doing.

Link to comment
Share on other sites

Thanks everyone, I appreciate the support!

 

I've done assembly optimization before on a lot of machines (x86, ARM, POWERPC), but this is the first time I've done anything with the TMS9900. I got a Mini Memory cart at the tail end of my TI days, but was never able to make much use of it. Actually, I don't even have any of my TI stuff here with me, it's all in a box somewhere in my parent's basement. All the assembly info I have was cobbled together by trawling through forums, Google searches, and the odd technical paper here or there. Of course, after I had everything I needed to start TI work again, somebody posted it all together in a much more concise and convenient form here. (Grr!)

 

At any rate, even though I've written three (crappy, severely limited) compilers before, and I've used GCC before, this is the first time I've done any actual GCC development. The earlier experience helps some, but mostly, its been a lot of reading and trial-and-error to get here.

 

I spent a few months writing a lot of libraries in 99000 assembly to get used to the language. And now that I've got a handle on it, I've been reviewing the GCC output and trying to implement any improvements I can find.

 

Pretty much everything I've done so far has been posted on my blog. The only real stuff missing was the initial data-gathering part, and most of the research, which I can't imagine anyone would want to read anyway.

 

Short version: the first time I've seen any of this stuff was less than two years ago. (Wow, that seems like a long time now that I've written that down)

 

So this project is a whole pile of firsts for me. It's taking quite a bit longer than I originally thought, but things seem to be going well.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...