Jump to content
IGNORED

GCC for the TI


insomnia

Recommended Posts

Hey everyone, I've been out of the loop for a while, but I'm making it a point to spend more time doing compiler stuff.

 

First off, I've copied alll the build directions and latest patches to the first post in this thread. That should make it easier to find any changes or improvements.

 

Also, I've added a script to automate the patch and build process in gcc-installer.tar.gz

 

To use this, run the install.sh script and pass as an argument the directory. The script will download the unmodified files from gnu.org, patch, build, and copy the output files to the location specified.

 

For example, after decompressing the archive, and running this script, tms9900-gcc and friends will be copied to /home/eric/tms9900/bin

$ tar -xzf gcc-installer.tar.gz

$ install.sh /home/eric/tms99900

 

Let me know if anyone sees any problems

Edited by insomnia
  • Like 4
Link to comment
Share on other sites

Hey everyone, I've been out of the loop for a while, but I'm making it a point to spend more time doing compiler stuff.

 

Welcome back. I just wanted to take the opportunity to thank you for the work you've done. I don't think I would've gotten back to programming the very first computer I've ever owned if it weren't for your gcc port. So thanks!

Edited by TheMole
  • Like 1
Link to comment
Share on other sites

Wow, Thanks!

 

I'm having fun working on this, but It's been amazing seeing all the projects that everyone else has made with these tools. I'm always so excited to see people be able to express their talent and creativity, and I'm proud to think I had some smalll part in helping to make that easier.

Link to comment
Share on other sites

  • 1 month later...

Well it's been a really long time, but here's another set of patches.

 

I went through the comments posted since the last release and I think I fixed every issue mentioned here. To everyone who reported their problems, thank you. It's been incredibly helpfull.

 

So here's what's new:

 

Binutils

----------

Added support for numeric registers
Correct handling of comments
Added support for dwarf debugging information

GCC

-------

Changed order of jumps for less-than-or-equal tests to improve performance
Fixed several integer type conversion bugs
Corrected handling of variable shift by zero bits
Fixed signed division
Added support for dwarf debugging information

For the assember, I wanted to make sure I was being as compatible as possible with Editor/Assembler. It should be able to compile anything that E/A can handle and produce identical output. The obvious defect here was with GAS being unable to handle the numeric registers typically seen in TI assembly (EX: mov 1,2). The other problem was in properly handling assembly comments. There were problems with ambiguous parsing when the "*" comment character was used. I was initially using a simple character search for this, but it turns out that a grammar parser was needed to intellegently determine what was code and what was comment. (For example: "ai r1, value * comment") Tricky, but that seems to be working great.

 

There was more work needed in the compiler. The biggest problems here were yet more int-char type conversion failures (With any luck, we shouldn't see any more of these) and signed division gave nonsense results. Several comments were made about division, and much frustration was had. Sorry about that.

 

The other big thing here is the new support for Dwarf2 debugging. For the longest time I wanted to be able to see mixed source output, with both the original source code and the resulting assembly on a line by line basis. Prior to this, knowing where an assembly instruction came from was a tedious and error-prone task for moderately complicated source code. Now it's much easier to identify inefficient algorithms, or debug tricky logic. (I suppose it would also help to be able to find compiler bugs. If there were any. Which there aren't.)

 

The debug information can be used to view assembly at compile time or to view the source code of compiled programs. The other binutils programs (most importantly readelf and objdump) know how to work with these sections. The elf2cart and elf2ea5 programs I posted earlier will ignore these sections, so there's no problem doing development with debug on.

 

I should mention that a lot of additional non-TI-compliant text will be added to the assembly file if debugging is used. This clutter could make it harder to read, and the file will only compile with GAS. Just something to be aware of if you are using an exotic build method.

 

I've updated the first post with new attachments and the gcc installer has been updated to build this latest version.

 

If anyone has problems or finds any bugs, please post them here. I love bug reports, keep 'em coming. As always, there are more details on my blog.

  • Like 5
Link to comment
Share on other sites

I won't ask my usual question about whether anyone has a working installation for Windows they would like to share. Oops, I guess I asked it again... :)

 

I know I promised you this a while back, but in the mean time I've gone completely Windows-less (work allowed me to upgrade to a Mac) so it's becoming less likely that I'll be able to help you with this. I know Tursi is a Windows/GCC user, so he might be able to help out. Just curious though, does the new install script that Insomnia provides not work for you? At least on Mac it seems to work pretty much flawlessly.

Link to comment
Share on other sites

Just curious though, does the new install script that Insomnia provides not work for you? At least on Mac it seems to work pretty much flawlessly.

 

No. Are they supposed to work on Windows?

 

I guess I just have to try my luck with Tursi's video again. Last time I had to give up half way through.

Link to comment
Share on other sites

Yeah, if you're going to develop on Windows, you'll need Cygwin, for sure.

 

Cygwin tends to screw up file permissions, so the first thing I always do is this:

https://cygwin.com/cygwin-ug-net/using-filemodes.html

 

The relevant change is:

 

Open /etc/fstab and enter following line:

none /cygdrive cygdrive binary,noacl,posix=0,user 0 0

Link to comment
Share on other sites

ooooh, so that's what happened to my system! Thanks unhuman, I actually didn't know that! Been dealing with random file permission changes on and off for a long while now. ;)

 

Rasmus: I won't get to rebuild my own toolchain till probably next weekend, but if you haven't done it before me, I can zip up mine for you.

  • Like 2
Link to comment
Share on other sites

This is what I get when I try to make binutils under cygwin. I have no idea what it means.

Rasmus@RHLA5603A ~/binutils-2.19.1
$ make all
make[1]: Entering directory '/home/Rasmus/binutils-2.19.1'
make[2]: Entering directory '/home/Rasmus/binutils-2.19.1/libiberty'
make[3]: Entering directory '/home/Rasmus/binutils-2.19.1/libiberty/testsuite'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/home/Rasmus/binutils-2.19.1/libiberty/testsuite'
make[2]: Leaving directory '/home/Rasmus/binutils-2.19.1/libiberty'
make[2]: Entering directory '/home/Rasmus/binutils-2.19.1/intl'
rm -f stamp-h1
/bin/sh ./config.status config.h
config.status: creating config.h
config.status: config.h is unchanged
test -f config.h || (rm -f stamp-h1 && make stamp-h1)
make[2]: Leaving directory '/home/Rasmus/binutils-2.19.1/intl'
make[2]: Entering directory '/home/Rasmus/binutils-2.19.1/bfd'
Making info in doc
make[3]: Entering directory '/home/Rasmus/binutils-2.19.1/bfd/doc'
make chew.exe
make[4]: Entering directory '/home/Rasmus/binutils-2.19.1/bfd/doc'
make[4]: 'chew.exe' is up to date.
make[4]: Leaving directory '/home/Rasmus/binutils-2.19.1/bfd/doc'
./chew.exe -f ../.././bfd/doc/doc.str <../.././bfd/doc/../targets.c >targets.tmp
/bin/sh ../.././bfd/doc/../../move-if-change targets.tmp targets.texi
restore=: && backupdir=".am$$" && \
rm -rf $backupdir && mkdir $backupdir && \
if (makeinfo --split-size=5000000 --split-size=5000000 --version) >/dev/null 2>&                 1; then \
  for f in bfd.info bfd.info-[0-9] bfd.info-[0-9][0-9] bfd.i[0-9] bfd.i[0-9][0-9                 ]; do \
    if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \
  done; \
else :; fi && \
if makeinfo --split-size=5000000 --split-size=5000000   -I ../.././bfd/doc \
 -o bfd.info `test -f 'bfd.texinfo' || echo '../.././bfd/doc/'`bfd.texinfo; \
then \
  rc=0; \
else \
  rc=$?; \
  $restore $backupdir/* `echo "./bfd.info" | sed 's|[^/]*$||'`; \
fi; \
rm -rf $backupdir; exit $rc
bfd.texinfo:326: unknown command `colophon'
bfd.texinfo:337: unknown command `cygnus'
./elf.texi:11: raising the section level of @subsubsection which is too low
Makefile:394: recipe for target 'bfd.info' failed
make[3]: *** [bfd.info] Error 1
make[3]: Leaving directory '/home/Rasmus/binutils-2.19.1/bfd/doc'
Making info in po
make[3]: Entering directory '/home/Rasmus/binutils-2.19.1/bfd/po'
make[3]: Nothing to be done for 'info'.
make[3]: Leaving directory '/home/Rasmus/binutils-2.19.1/bfd/po'
make[3]: Entering directory '/home/Rasmus/binutils-2.19.1/bfd'
make[3]: Nothing to be done for 'info-am'.
make[3]: Leaving directory '/home/Rasmus/binutils-2.19.1/bfd'
Makefile:1094: recipe for target 'info-recursive' failed
make[2]: *** [info-recursive] Error 1
make[2]: Leaving directory '/home/Rasmus/binutils-2.19.1/bfd'
Makefile:3100: recipe for target 'all-bfd' failed
make[1]: *** [all-bfd] Error 2
make[1]: Leaving directory '/home/Rasmus/binutils-2.19.1'
Makefile:722: recipe for target 'all' failed
make: *** [all] Error 2

Link to comment
Share on other sites

This is what I get when I try to make binutils under cygwin. I have no idea what it means.

I had the same error with the latest version of cygwin, so I compiled it with an older version (2.738): http://lb3.one/public/TI99-GCC-1.9.zip

 

It seems to be a problem with texinfo: https://dev.haiku-os.org/ticket/9482

 

I love bug reports, keep 'em coming.

I found these two years ago (compiled with size optimization -Os):

 

void show_mem(char l,unsigned char* c,int n) {
    int i;
    *(volatile char*)0x8C02=l*32;
    *(volatile char*)0x8C02=l*32>>8|0x40;
    for(i=0;i<n*2;i++) {
        unsigned char c2;
        if(i%2)c2=c[i/2]&0x0F;
        else c2=c[i/2]>>4;
        if(c2<10)c2+=0x30;
        else c2+=0x37;
        *(volatile char*)0x8C00=c2;
    }
}

char ar1[8];
void bug1() {
    //R0 is used for the "indexed memory" addressing mode "@>XX(R0)"
    //when all the other registers are used
    int i;
    for(i=0;i<8;i++) {
        asm(
            "nop 0"
            ::
            :"r1","r2","r3","r4","r5","r6","r7","r8","r12"
        );
        ar1[i]=i;
    }
    //ar=7,0,0,0,0,0,0,0 instead of 0,1,2,3,4,5,6,7
}

char bug2(char c) {
    //when "c" is -1, R1 is >FFFF because of "SETO"
    //two's complement (NEG) is >0001 (byte value = 0)
    //-1 should be >FF00 (two's complement = >0100)
    return -c;
}

//int bug_3=0xABCD;
char bug3(char c) {
    /*when a switch instruction is compiled with a data table (CSWTCH table in the generated assembly)
    and the source file has no global initilization, CSWTCH is declared in the "cseg" segment instead
    of the "pseg" segment. And the "cseg" segment is not pointed by "_init_data" in "crt0_cart.asm"
    and "crt0_ea5.asm". (try to uncomment the "bug_3" declaration). */
    char ret=1;
    switch(c) {
        case 0:
            ret=3;
            break;        
        case 1:
            ret=2;
            break;
    }
    return ret;
}

void main() {
    volatile char c;

    //Should display 01020304050607 instead of 07000000000000
    bug1();
    show_mem(0,ar1,;

    //Should display 01 instead of 00
    c=-1;
    char c2=bug2(c);
    show_mem(1,&c2,1);

    //Should display 02 instead of 00
    c=1;
    char c3=bug3(c);
    show_mem(2,&c3,1);
        
    while(1);
}
Edited by lucien2
Link to comment
Share on other sites

  • 3 weeks later...

I compiled all my programs with the new version and I found no new bugs. Rush hour does not compile correctly (It did with gcc patch 1.6 / binutils patch 1.4). There is an R0 used for indirect addressing in the function "move_block" (bug #1 in my list of October 18th).

 

With bug#2 from my list, that's only 2 bugs for a total of 4058 lines of C source code compiled!

Edited by lucien2
Link to comment
Share on other sites

  • 5 weeks later...

OK, who's up for new patches?

 

First, a huge thank you to Lucien2 for tracking down these compiler bugs and making test cases for them. That was super helpful.

 

Here are the latest changes:

 

Binutils

---------

Restored ability to have label and code on same line
Minor code cleanup

GCC

-------

Prevented use of R0 as an address base
Moved jump tables into text segment to free up space for variables
Fixed bug which put initialized data in bss section
Fixed negation of byte quantities
Minor code cleanup

Basically, all the bugs here are the result of me making dumb mistakes. Sorry about that. But the good news is that If these were the most visible bugs still rattling around in the code, the compiler must be getting pretty darn stable. I'm really happy that as more projects are being worked on, the list of problems seems to be drying up. The number of untested edge cases (each potentially hiding a bug or two) must be pretty smalll at this point.

 

I feel kind of bad that I haven't been able to help anyone having problems with Cygwin, or Windows stuff in general. I do all my development in Linux, and don't really have any useful advice for those people. Another big thank you to everyone who has been able to provide that help.

 

At any rate, the patches and gcc installler have been updated in the first post. If anyone is interested there are more development details on my blog. As always, please let me know if you have any problems or see anything that could be improved.

  • Like 6
Link to comment
Share on other sites

I'm having a problem building this on OS X 10.10 (using LLVM). Usually I have to fiddle with some things a little bit to get things working, but here I'm stumped as to what might be going wrong.

 

This is as far as I get (and the modifications I did to get this far):

  • Patches apply fine
  • Binutils compiles fine
  • GCC starts to compile:
    • first I had to amend the ./configure line to point to where libgmp and friends can be found.
    • Then I had to modify a GCC version check to fix a compile error (and later link error) in toplev.c (simple #ifdef gcc-ism I had to strip out, nothing that should impact the code in the end)
    • Then I run into the error I can't seem to solve below:
/Users/danny/Documents/dev/build/gcc-4.4.0/build/./gcc/xgcc -B/Users/danny/Documents/dev/build/gcc-4.4.0/build/./gcc/ -B/Users/danny/Documents/dev/build/tms9900/bin/ -B/Users/danny/Documents/dev/build/tms9900/lib/ -isystem /Users/danny/Documents/dev/build/tms9900/include -isystem /Users/danny/Documents/dev/build/tms9900/sys-include -g -O2 -O2  -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition  -isystem ./include   -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc  -I. -I. -I../.././gcc -I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc -I../../../libgcc/../include  -DHAVE_CC_TLS -o _absvhi2.o -MT _absvhi2.o -MD -MP -MF _absvhi2.dep -DL_absvsi2 -c ../../../libgcc/../gcc/libgcc2.c  \
		-DLIBGCC2_UNITS_PER_WORD=2
In file included from ../.././gcc/tm.h:5,
                 from ../../../libgcc/../gcc/libgcc2.c:31:
../../../libgcc/../gcc/config/tms9900/tms9900.h:1132: error: expected ‘)’ before ‘*’ token
make[1]: *** [_absvhi2.o] Error 1
make: *** [all-target-libgcc] Error 2
=== Failed to build GCC ===

I looked at tms9900.h, tm.h and libgcc2.c and can't see any obvious mistakes (definitions seem to be complete and match up and all that...). Any ideas?

 

*edit* I want to add that I did get it to compile in the past with the LLVM that comes with XCode 5, but since upgrading to Yosemite and XCode 6 I hadn't tried recompiling the code base. The LLVM version is reported as follows:

Dannys-Mac-mini:dev danny$ gcc -v
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix
Edited by TheMole
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...