Jump to content

Photo

GCC for the TI


299 replies to this topic

#26 JamesD ONLINE  

JamesD

    Quadrunner

  • 6,988 posts

Posted Wed Jun 23, 2010 2:55 PM

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, Wed Jun 23, 2010 3:59 PM.


#27 insomnia OFFLINE  

insomnia

    Star Raider

  • Topic Starter
  • 65 posts
  • Location:Pittsburgh, PA

Posted Sat Jul 10, 2010 12:58 AM

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

Attached Files



#28 retroclouds OFFLINE  

retroclouds

    Stargunner

  • 1,516 posts
  • Location:Germany

Posted Sat Jul 10, 2010 1:33 AM

Thanks for you hard work on this. Really interested seeing how this further evolves. :)

#29 Opry99er ONLINE  

Opry99er

    Quadrunner

  • 7,788 posts
  • Location:Cookeville, TN

Posted Sat Jul 10, 2010 9:20 PM

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!

#30 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,499 posts
  • Location:BUR

Posted Sun Oct 24, 2010 4:01 AM

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.

#31 insomnia OFFLINE  

insomnia

    Star Raider

  • Topic Starter
  • 65 posts
  • Location:Pittsburgh, PA

Posted Tue Oct 26, 2010 1:59 AM

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"

#32 Willsy OFFLINE  

Willsy

    River Patroller

  • 2,896 posts
  • Location:Uzbekistan (no, really!)

Posted Tue Oct 26, 2010 4:40 AM

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!

#33 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,499 posts
  • Location:BUR

Posted Tue Oct 26, 2010 5:01 AM

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. :)

#34 matthew180 OFFLINE  

matthew180

    River Patroller

  • 2,208 posts
  • Location:Castaic, California

Posted Tue Oct 26, 2010 7:50 AM

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..../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.e...rs/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.c...l/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

#35 Willsy OFFLINE  

Willsy

    River Patroller

  • 2,896 posts
  • Location:Uzbekistan (no, really!)

Posted Wed Oct 27, 2010 2:04 AM

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.

#36 insomnia OFFLINE  

insomnia

    Star Raider

  • Topic Starter
  • 65 posts
  • Location:Pittsburgh, PA

Posted Wed Oct 27, 2010 2:31 AM

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.

#37 matthew180 OFFLINE  

matthew180

    River Patroller

  • 2,208 posts
  • Location:Castaic, California

Posted Wed Oct 27, 2010 7:25 AM

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

#38 matthew180 OFFLINE  

matthew180

    River Patroller

  • 2,208 posts
  • Location:Castaic, California

Posted Wed Oct 27, 2010 7:37 AM

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

#39 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,499 posts
  • Location:BUR

Posted Wed Oct 27, 2010 3:55 PM

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. :)

#40 unhuman OFFLINE  

unhuman

    Stargunner

  • 1,126 posts
  • Location:Vienna, VA

Posted Wed Oct 27, 2010 6:45 PM

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.

#41 Opry99er ONLINE  

Opry99er

    Quadrunner

  • 7,788 posts
  • Location:Cookeville, TN

Posted Thu Nov 11, 2010 11:46 PM

Hey Tursi/Insomnia...

Any updates on this project? I wish I knew more, I would love to help. Unfortunately, C is as foreign to me as Korean. =)

#42 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,499 posts
  • Location:BUR

Posted Fri Nov 12, 2010 10:49 PM

I was forced to do my code in assembly due to time constraints (and lack of any suitable terminals for quick porting ;) ). So I haven't touched it.

#43 insomnia OFFLINE  

insomnia

    Star Raider

  • Topic Starter
  • 65 posts
  • Location:Pittsburgh, PA

Posted Tue Nov 16, 2010 11:00 PM

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.

Attached Files



#44 retroclouds OFFLINE  

retroclouds

    Stargunner

  • 1,516 posts
  • Location:Germany

Posted Thu Nov 18, 2010 2:02 PM

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?

#45 insomnia OFFLINE  

insomnia

    Star Raider

  • Topic Starter
  • 65 posts
  • Location:Pittsburgh, PA

Posted Thu Nov 18, 2010 6:33 PM

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...

#46 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,499 posts
  • Location:BUR

Posted Thu Nov 18, 2010 11:13 PM

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, Thu Nov 18, 2010 11:14 PM.


#47 unhuman OFFLINE  

unhuman

    Stargunner

  • 1,126 posts
  • Location:Vienna, VA

Posted Sun Dec 19, 2010 7:47 PM

Propping this up... :) Haven't seen any activity on this and this is probably my most looked forward to thing...

#48 insomnia OFFLINE  

insomnia

    Star Raider

  • Topic Starter
  • 65 posts
  • Location:Pittsburgh, PA

Posted Fri Dec 31, 2010 8:39 PM

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.

#49 retroclouds OFFLINE  

retroclouds

    Stargunner

  • 1,516 posts
  • Location:Germany

Posted Sat Jan 1, 2011 3:21 AM

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.

#50 insomnia OFFLINE  

insomnia

    Star Raider

  • Topic Starter
  • 65 posts
  • Location:Pittsburgh, PA

Posted Sat Jan 1, 2011 1:34 PM

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.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users