GCC for the TI

[Fabrizio Caruso]

@MarkB I can see the issue in the game but if I isolate the code I showed above, I cannot see the issue. So the problem is somewhere else. It is going to be harder to investigate.
In the game Horde, you start with number_of_arrows_per_shoot=1 and through several power-ups you get number_of_arrows_per_shoot=2 and the issue appears (arrows are not placed where they should).
On the other hand the snippet of code above is compiled correctly and if I start the game with number_of_arrows_per_shoot=2, the issue is no longer visible.
So maybe a register or a carry bit gets dirty somehow... It is hard for me to isolate it.

[Willsy]

Just out of curiosity, what happens if you do:

 

if((number_of_arrows_per_shot == 2) && i)
{
  offset = (i - 2) * (bow_x & 1);
}

 

I'm just wondering if it's being compiled as i-(2*(bow_x & 1)) 

[Fabrizio Caruso]

The problem with the Horde (and Stinger) game is very weird. One arrow is position at a wrong position by 1 byte. This problem does not occur if you print the corresponding variable (see _XL_PRINTD command in the code below).

Maybe something like a carry bit was not cleared and it is added.

@Willsy, that code taken alone is correctly compiled. Something else breaks it. Maybe a peep-hole rule.

How can I disable all peep-hole rules and optimizations ?

[Fabrizio Caruso]

Using -O1 instead of -O2 fixes the issue with the wrongly places arrows in Horde but triggers a worse bug that makes it impossible to complete the version level (last zombie does not movie and cannot die).

So I suppose I should use -O2. Is this what everyone is supposed to do? -O0 won't compile and produce errors about libti99.

[Fabrizio Caruso]

By the way, which thread should I use to discuss the new bugs?
 

[+MarkB]

11 hours ago, Fabrizio Caruso said:

By the way, which thread should I use to discuss the new bugs?
 

Let's use the new thread

[+MarkB]

13 hours ago, Fabrizio Caruso said:

Using -O1 instead of -O2 fixes the issue with the wrongly places arrows in Horde but triggers a worse bug that makes it impossible to complete the version level (last zombie does not movie and cannot die).

So I suppose I should use -O2. Is this what everyone is supposed to do? -O0 won't compile and produce errors about libti99.

Both should work.  Traditionally people used -O2 or -Os because -O0 was broken but also of course because they want want to squeeze as much performance as possible from the CPU.

[Fabrizio Caruso]

I have opened several issues for the new bugs in https://github.com/mburkley/tms9900-gcc/

I may open more issues because I have more new bugs in some other games.

In particular I have opened one where 28 - 0 = 27 with a minimal example with source code, map file and EA5 binary:
https://github.com/mburkley/tms9900-gcc/issues/62

[Fabrizio Caruso]

I can also confirm that Shoot game is miscompiled 😞
I can compiled Shoot now (by disabling some optional minor content).
The source code is here: https://github.com/Fabrizio-Caruso/CROSS-LIB/tree/master/src/games/shoot

So all my 9 games except the smallest 2 (Bomber, Trex) are miscompiled beyond repair in several places. For the moment the only way to get all my 9 games working is to build a version of GCC for the TI before the recent changes.

For level=2 the function:

```
uint8_t innerVerticalWallLevel(void)
{
    return ((level&7)==1) || ((level&7)==4) || ((level&7)==0);
}   

```

returns 1.

This is fixed/triggered in unpredictable ways by commenting out totally unrelated functions as if the result depended on the binary size and/or the position in memory of the function and/or the program counter and/or something that has changed elsewhere.

It can be reproduced and it is taking me very long to construct a minimal example for this other new bug because of the size of the game. For a minimal example please look at my **previous post** about 28 - 0 = 27.

[TheMole]

@Fabrizio Caruso, just to be sure... Are you compiling libti99.a itself with the same version of gcc? If I recall correctly, Mark's changes produce binaries that are not compatible with binaries built by the old Insomnia version.

 

*edit* nevermind, just saw the other thread...

Edited Friday at 02:40 PM by TheMole

[Fabrizio Caruso]

@TheMole Yes, I have recompiled both. Could you and/or someone else please double check these issues by just trying out the latest compiler with my short example?
One short example that produces one of the many bugs is here: https://github.com/mburkley/tms9900-gcc/issues/62

Edited Friday at 12:48 PM by Fabrizio Caruso