GCC for the TI

[Tursi]

So I downloaded your TESTLIB1 and ran it here under Classic99 and it worked fine... what does the debug say when you load it? Maybe it's not loading right?

 

[Fabrizio Caruso]

@tursi, sorry I have put good images...

I have attached bad image of one of my games (which works on a different installation of gcc for ti).
 

XBOMBER1 XBOMBER2

[Fabrizio Caruso]

@tursi, the problem could be on my side somehow, then, and only affect my project...

[Fabrizio Caruso]

I need to double check if my wrongly configured system is linking the same libti99.

[Tursi]

Yeah, I can't investigate your game as I don't have source code. I don't know what it's /trying/ to do, so how can I tell where it goes wrong?

 

A small example is always better. Can you build and run example.c from the libti99 source? It should build to EXAMPLE1. 

[Fabrizio Caruso]

@Tursi I am sorry.
The problem is most probably in my build-chain. Both the latest compiler and your lib are fine and work together with no issue for me.
Your "make example" produced EXAMPLE (not EXAMPLE1). I could run it and it worked fine.

So, this means that the problem is in my build-chain.
It is not in my code because the very same code of mine works fine on a different PC of mine.
Same code compiled on PC with old gcc 4 ti under Cygwin 32-bit: OK
Same code compiled on PC with latest gcc 4 ti under Cygwin 64-bit: KO

Maybe I am doing something wrong when I link the object files. The produced binaries are different as shown a previous post of mine.

My (ugly) build chain is basically a portion of my Makefile:
https://github.com/Fabrizio-Caruso/CROSS-LIB/blob/master/src/Makefile_common#L2629

[+MarkB]

On 11/10/2023 at 10:28 AM, Fabrizio Caruso said:

The different between the good (right) and the bad (left) is just a couple of bytes (in my case here start around $0000E0):

Decoding from memory 🙂 I think cc0e is mov 14,*0+ which is saving r14 to the stack which wasn’t before. On the previous line 022a fff8 is allocating 2 more bytes than before on the stack so that looks ok. Probably moving some code around means the compiler needs r14 so has to save it now. The problem is elsewhere I’m afraid.  I’ll debug when I’m back home.  Thanks for the testing though.

[Tursi]

7 hours ago, Fabrizio Caruso said:

@Tursi I am sorry.
The problem is most probably in my build-chain. Both the latest compiler and your lib are fine and work together with no issue for me.
Your "make example" produced EXAMPLE (not EXAMPLE1). I could run it and it worked fine.

I'm sure it's in your build chain, but EXAMPLE is small enough to quickly determine exactly what went wrong, and that can hep fix it.  Post it!

 

[Fabrizio Caruso]

Thanks @Tursi!
I am not sure what you mean by compiling your example with my build chain because my build chain, as is, won't compile a single file.
My build chain does a bunch of things, one of which is linking whatever you want to compile with my library source files (my so called library is just source files that are recompiled each time).
So I cannot compile just your isolated example with Cross-Lib. I could embedded in the Cross-Lib project and compile it with my build-chain. Not sure this is useful.

Do you mean to compile your example with your make file (make example) on the PC where I can't get my own Cross-Lib build chain to produce working examples?
Your example works fine in any configuration.
I have attached EXAMPLE (built under the PC where Cross-Lib is not working)

On the other hand I have a helloworld example in Cross-Lib:
https://github.com/Fabrizio-Caruso/CROSS-LIB/blob/master/src/examples/helloworld/main.c

which I have compiled with my OK config and my KO config. I have attached both here.

XHELLOWORLD1_KO EXAMPLE XHELLOWORLD1_OK

[Tursi]

I no longer understand what the problem is supposed to be. I know my toolchain works. I'm not thinking about mine. But I do not understand what these binaries you are providing are if you can't compile a single file with yours.

 

[Fabrizio Caruso]

@Tursi, sorry for the confusion.
My so called build-chain can take one single file but what my script does is several things including: compile some tools if necessary, compile the single file, compile the library source files, convert the abstract assets into something that can be included or linked with the other files, link all these things, apply some post-processing to produce disk/tape/crt images.
To be precise this is what I am doing:
https://github.com/Fabrizio-Caruso/CROSS-LIB/blob/master/src/Makefile_common#L2629

This can be reproduced in Cross-Lib by running the following commands from the src directory:
xl clean && xl clean tools && xl rebuild helloworld ti99

Do you want me to provide the single .o files generated during the compilation?

I never thought your make was not OK but I thought that maybe the newly modified gcc for ti was not OK. I now think it has no problem.
I think I am doing something wrong and/or stupid.

[Fabrizio Caruso]

@Tursi So I know think that maybe I am linking the wrong things on the newly configured system of mine.
Or I something my scripts do, depend on something that is very different in one system vs the other.
Maybe I am linking a different version of the your library or the crt that I had compiled with a previous compiler. Something stupid like that maybe.
I see that the binaries differ quite soon, so maybe the crt.

[Tursi]

Well... I'm still a bit confused, but if it's not something I can help troubleshoot by stepping into the executable, then it might be over my head

 

[Fabrizio Caruso]

After double-checking what my Makefile is doing. I will try to reinstall gcc for ti, your library and redo all steps from scratch...
I suspect I may be linking things that do not "match" in my script because gcc for ti is correctly building your examples.
If I compile a single file as I do with your "make example", I get the right result. So it is a problem in my script.

I thought someone with Assembly skills and knowledge of the TI99/4A could look at the produced binaries and see what is wrong in the one that does not work.

[+MarkB]

1 hour ago, Fabrizio Caruso said:

I thought that maybe the newly modified gcc for ti was not OK

@Fabrizio Caruso @Tursi greetings from Portugal.  The mods to gcc are almost certainly not ok.  Please don’t waste time trying diagnosing non-issues with libti99.  I’ll debug the compiler when I get get home on Friday.  Thanks for your patience.

[Tursi]

1 hour ago, khanivore said:

@Fabrizio Caruso @Tursi greetings from Portugal.  The mods to gcc are almost certainly not ok.  Please don’t waste time trying diagnosing non-issues with libti99.  I’ll debug the compiler when I get get home on Friday.  Thanks for your patience.

I wasn't. i was trying to help with your compiler work by identifying where it went wrong

 

[+MarkB]

22 hours ago, Tursi said:

I wasn't. i was trying to help with your compiler work by identifying where it went wrong

 

No prob.  If it helps, I was still seeing stack frame storage collisions so I don’t think my work-around of two separate SP adds during the prolog is working.  That shouldn’t be necessary anyway; it feels to me there is a misconfig somewhere in tms9900.h.

Also, the handling of byte operations doesn’t feel right.  It shouldn’t be necessary to patch the compiler for this.  TMS9900 is not the only big endian CPU.  The compiler knows how to handle BE byte storage in 16-bit words.  So this patch to prevent creation of a subreg feels wrong and could (probably is) causing the assertion we’re seeing in tstqi.

To add a backend should require just creating a machine description and configuration .h file.  I can’t see that tms9900 is so terribly different from other CPUs that anything more should be required.  More digging required.

[+MarkB]

Some quick updates ....

I found an issue with stack frames.  The "elimination offset" wasn't calculated correctly but that is fixed now.  I've tested passing many parameters to a function (since the first 5 params get registers allocated) and this seems to working now.

I'm still wrestling with byte (QI) multiply and divide.  I'm starting to understand why insomnia patched the compiler.  MPY and DIV on tms9900 use 16-bit (HI) / 32-bit (SI) operands and the compiler seems to assume it can treat a register holding a QI as a HI but that isn't the case (>02 * >02 is >04 but >200 * >200 is obviously not >400).  I'm seeing if I can implement insns to do byte operations where I can do a right shift before and left shift after but getting it to match my new insn is tricky.

(another problem is that MPY is unsigned so for signed multiply we need to get the operand signs and do ABS first and then NEG after the op if the sign is negative)

Bear with me.  Hope to have a new version soon...

[+MarkB]

There is new code for review here https://github.com/mburkley/tms9900-gcc/pull/13 if anyone has time to take a look.

This is still on gcc-4.4.0.  The port to gcc-13.2 was successful, but the output was exactly the same, and the build time jumped to several hours, so for expediency, I'm sticking with gcc-4 for now.

 

This PR tidies up the byte move, compare and arithmetic operations as well as fixing the stack frame and parameter ordering.

(edit: the install process is still the same, use ./install.sh to download and build src code.  I can create .deb packages with just binaries but don't know how and couldn't test any packaging scheme for windows / cygwin.  Volunteers welcome 🙂 ) 

[TheMole]

Awesome, I'm going to try building this on my mac tomorrow and I'll get back with my findings.

 

BTW, I think the main benefit of re-basing it off of a more modern gcc is to make sure it can still be built on modern machines without having to jump through a bunch of hoops, so the fact that you had it up and running on 13.2 is so great to hear! Also, being able to use some of those C23 improvements might be cool as well...

 

Edited December 4, 2023 by TheMole

[Tursi]

It will be a little time before I can play with it, but I'll run through and compare it to the old one in a few weeks. There's a lot of byte code in SSA and the more I can trust that the happier I'll be

 

[TheMole]

Ouch... I'm having flashbacks to when I originally tried to build this on macos all those years ago and suddenly remember why I'm sticking to an x86 binary on my arm machine ;).

After a few tricky-but-solvable issues (curl not working, the scripts not handling paths with spaces very well, not realizing I needed to remove the build directory, etc...), I finally got to the stage where i tries to build something, but clang isn't even able to build binutils here. It throws up a gazillion warnings and then bails while trying to compile libiberty, complaining about undeclared library functions. I tried building some of the subdirectories manually, but same thing.

 

Maybe I should install (a modern) gcc and use that instead of clang...

[TheMole]

Okay, managed to build it!

 

First, let me document the steps to build it on a modern arm mac:

• rm -rfd build
• brew install wget
• brew install gcc (clang won't work)
• brew install gmp mpfr
• Edit the install.sh script:
  • Add --with-gmp=/opt/homebrew --with-mpfr=/opt/homebrew to the gcc ./configure arguments (around line 145)
  • (should look like this:  ../configure --prefix $PREFIX --target=tms9900 --enable-languages=c,c++ --with-gmp=/opt/homebrew/ --with-mpfr=/opt/homebrew/ )
• export CC=/opt/homebrew/bin/gcc-13
• Edit build/gcc-4.4.0/gcc/config.host (because gcc cross compilers won't build cleanly on arm macs yet, according to this post I found: https://github.com/riscv-software-src/homebrew-riscv/issues/47)
  • Find the generic darwin config section (search for "# Generic darwin host support")
  • comment out (#) the following two lines:

    • out_host_hook_obj=host-darwin.o

    • host_xmake_file="${host_xmake_file} x-darwin"

• ./install.sh target_dir

The installer will error out when trying to compile libgcc.a, but it has always done that for me, so I just ignored it like I've always done. If I understand it correctly, libgcc.a implements certain long and float operations, but I haven't had a need for those yet.

 

Looks like I've succesfully built an arm binary:

Dannys-MacBook-Pro tms9900-gcc % file ~/My\ Drive/tidev/toolchain/tms9900/bin/tms9900-gcc
/Users/-----------------/My Drive/tidev/toolchain/tms9900/bin/tms9900-gcc: Mach-O 64-bit executable arm64

 

Great!

 

However, trying to build ghostbusters with this, it segfaults on the first .c file which just happens to be my crt0.c file:

bank0/crt0.c:1: internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make: *** [bank0/crt0.o] Error 1

 

I then tried just compiling a short .c file by itself, outside of my build system, and got the same result. I'm happy to provide you the source files, but since it happens in the exact same way with every file that I try compiling, I don't think it's related to the code itself. Probably an issue with building on arm macs in general? It's worth noting that it doesn't segfault when you just run the compiler without any input files, so the binary does seem to 'run' somewhat at least.

 

The only other thing I can try is building it on my old intel mac and see if it works there. I'll see if I can find some time to do that tomorrow.

 

[+MarkB]

I've made some fixes to the branch and merged to main.

I renamed the "build" dir to "dev" in the source repo to fix the problem where patch is trying reapply patches.  Install should be a bit more straightforward now. 
I haven't gone near binutils so don't know why that would be failing now.  There are millions of warnings in gcc-4.  It is very annoying.  gcc-13 is much better in that regard.

(Now I'm chasing another weird bug where initialising a long to a negative number causes a compiler abort.  I've just noted it as an issue for now.  Any constant value outside 0-32767 has problems which makes no sense to me.)

[+MarkB]

15 minutes ago, TheMole said:

The installer will error out when trying to compile libgcc.a, but it has always done that for me, so I just ignored it like I've always done. If I understand it correctly, libgcc.a implements certain long and float operations, but I haven't had a need for those yet.

Yes, fixing libgcc is on the todo list, but is broken for now.  I have some float functions courtesy of @mrvan but some conversion between gcc internal float and ti float is needed.  I'm also moving some of the 32-bit arithmetic ops into libgcc as well.
 

17 minutes ago, TheMole said:

I then tried just compiling a short .c file by itself, outside of my build system, and got the same result. I'm happy to provide you the source files, but since it happens in the exact same way with every file that I try compiling, I don't think it's related to the code itself. Probably an issue with building on arm macs in general? It's worth noting that it doesn't segfault when you just run the compiler without any input files, so the binary does seem to 'run' somewhat at least.

Strange.  Please feel free to pm me the code to test.  I have a few unit tests in the ./test directory which I'm using to verify behaviour is the same on host (x86-64) as target.  They build fine with and without -O2 as does libti99