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

[+khanivore]

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.

[+khanivore]

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

 

[+khanivore]

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.

[+khanivore]

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