Jump to content
IGNORED

GCC for the TI


insomnia

Recommended Posts

Lately I've been getting this error when running install.sh: "raising the section level of @subsubsection which is too low". This seems to be related to building the info documentation, which I will never use. The workaround I've found is to set "MAKEINFO=missing" before ./install.sh on the command line. Posting here for anyone else, and myself in the future when I forget.

  • Like 2
Link to comment
Share on other sites

I try to build GCC with the newest patch and all I get is:

mindlord@Myrthstation:~$ ./install.sh TMS9900NEW
Using these patches:
    binutils-2.19.1-tms9900-1.7.patch
    gcc-4.4.0-tms9900-1.17.patch

=== Creating output directory ===
=== Getting Binutils sources ===
=== Getting GCC sources ===
=== Make build directory ===
=== Decompressing and patching Binutils sources ===
=== Decompressing and patching GCC sources ===
=== Building Binutils ===
=== Building GCC ===
=== Installation complete ===

Nothing is in the folder. Not that I expected there to be.

Link to comment
Share on other sites

I can confirm that version 17 fixes the multiplication problem, so thanks for that!

I'm on to the next issue, which seems to be related to shifting of signed integers (and presumable longs as well). It get the following results:

post-33891-0-52959900-1540903571.png

post-33891-0-52360500-1540903578.png

 

This only happens with signed ints, not with unsigned ints where the results are as expected.

 

Just for context: this is the test code that I've used (fetch_input(a, b) fetches 'b' bytes from a file and stores it in memory location 'a') :

#define SHIFT1	 5
#define FETCH(x) fetch_input(&x, sizeof(x));
void test_shifts_int()
{
	int8 	input, fails = 0;
	int16	var = 0;

	cprintf("Integer shifts...");
	for (int i = 0; i < NUMLOOPS; i++)
	{
		FETCH(input);
		var = input << SHIFT1;
		if (input != (var >> SHIFT1))
		{
			cprintf("%d << %d = %d >> %d = %d\n", input, SHIFT1, var, SHIFT1, var >> SHIFT1);
			fails++;
		}
	}
}

I believe this is breaking my sprite positioning and scrolling routines in Alex Kidd. Last known working version for me was patch 12.

 

 

  • Like 1
Link to comment
Share on other sites

OK, I'm really embarrassed about this bug. It turns out that instead of emitting a right shift, we are emitting a left shift. As you discovered, this only affects signed integers.

 

I can only assume this was due to a cut-and-paste error somewhere that escaped testing.

 

This is a one-line fix, but I'll confirm that the rest of the shift operations work as intended before making another patch.

  • Like 5
Link to comment
Share on other sites

This is a one-line fix, but I'll confirm that the rest of the shift operations work as intended before making another patch.

 

Sorry for drip feeding these bug reports, but I'm reporting them as I run into them. If you would prefer to send me a patch for me to test prior to you officially releasing it (and assigning a version number), I'd be happy to help, just let me know.

Link to comment
Share on other sites

A new patch is now available in the first post, and the installer has been updated as well.

 

So in this patch, we only have two fixes:

 

Fixed 16-bit signed right shift
Fixed 32-bit unsigned right shift

The 16 bit shift was shifting in the wrong direction, and the 32-bt shift was performing signed shifts.

 

TheMole found the 16-bit shift bug, and I found the other one after doing some automated testing. Hopefully that's the last of these kinds of errors.

 

 

 

Sorry for drip feeding these bug reports, but I'm reporting them as I run into them. If you would prefer to send me a patch for me to test prior to you officially releasing it (and assigning a version number), I'd be happy to help, just let me know.

 

Making new releases takes no effort at all, so don't worry about that. Also, I appreciate bug reports no matter if they are drip fed or not. Thanks for doing these tests, clearly my own testing has some gaps.

  • Like 5
Link to comment
Share on other sites

How do you install a patch?

 

In general, there's a utility called "patch" that you can use to apply a patch to a code base. However, in this case it's a simple matter of downloading the gcc installer, unpacking it, removing the old patch file from the unpacked folder and dropping in the new one. The install script looks for the patch file in the folder it is run from and calls the patch utility.

  • Like 2
Link to comment
Share on other sites

I can confirm shifts are now working.

 

I'm on to the next problem though, I haven't identified the root of the problem yet, but I think it might be related to my use of function pointers. It seems like there's a problem passing variables. Passing literals as parameter seems to work, passing variables sometimes doesn't. I'll work on a more exact test case tonight, so hopefully I can come up with a more useful bug report :).

Link to comment
Share on other sites

Hello everyone. Grabbed the latest version and ran the install.sh script (preceded with 'MAKEINFO=missing' as mentioned above to avoid that same error). It made it this far and failed:

make[3]: Entering directory '/home/mrg/source/TI/build/gcc-4.4.0/build/libiberty/testsuite'
make[3]: Nothing to be done for 'install'.
make[3]: Leaving directory '/home/mrg/source/TI/build/gcc-4.4.0/build/libiberty/testsuite'
make[2]: Leaving directory '/home/mrg/source/TI/build/gcc-4.4.0/build/libiberty'
/bin/bash: line 3: cd: tms9900/libstdc++-v3: No such file or directory
Makefile:10623: recipe for target 'install-target-libstdc++-v3' failed
make[1]: *** [install-target-libstdc++-v3] Error 1
make[1]: Leaving directory '/home/mrg/source/TI/build/gcc-4.4.0/build'
Makefile:2475: recipe for target 'install' failed
make: *** [install] Error 2
=== Installation complete ===

Is the libstdc++-v3 library not built as part of this script?

 

Thanks for any help anyone can provide!

  • Like 1
Link to comment
Share on other sites

So, the problem is not specific to function pointers...

 

In my game loop, I call a function to render the main character sprite to a RAM buffer. Since this needs a different approach for the 9918a and the F18A, I call this function via a pointer (so that I don't have to have if-then-else structures littered around the game code). The call looks like this:

(*alex_func)(action, (player.xpos >>  - scroll_x, (player.ypos >> , player.direction);

player.xpos and player.ypos are unsigned longs, and represent the player's position in the world. You can think of them as 24.8 fixed point numbers, as the least significant 8 bits are "subpixels". Hence the shift right by 8: this generates a pixel value.

 

scroll_x is an unsigned int, and represents the scroll position in the level. Action and player.direction are an integer and an unsigned char respectively that represent the player stance (walking, jumping, ...) and which direction he is facing.

 

If running on a 9918a equipped console, this points to the following function:

void put_alex(int stance, int x, int y, unsigned char direction);

Now, with version 12 of the patch, this worked perfectly. However, since then (I'm in the process of compiling a version of the compiler with each patch since 12 to identify when the problem started), the player sprite is stuck against the left side of the screen, which implies that whatever value player.xpos has, it comes in as 0.

 

First thing I tried was just calling the function directly:

put_alex(action, (player.xpos >>  - scroll_x, (player.ypos >> , player.direction);

But that didn't change anything. So probably not related to function pointers at all :).

 

Just to see if it was a problem with the calculation, I tried it with the literal value 16 (which is what ((player.xpos >> 8) - scroll_x) should evaluate to at the start of a level), like so:

put_alex(action, 16, (player.ypos >> , player.direction);

That indeed put the player at the right x-coordinate, but now the y-coordinate comes in as 0 making it so that the player is stuck at the top of the screen. Note that in the previous example, the y parameter did actually work as expected, so the problem just shifted from one parameter to another.

 

I also tried using an intermediate variable instead of putting the calculation in the function call, but that didn't make any difference.

 

Anyway, I do apologize for not being able to provide a straightforward piece of code that reproduces this behavior. I haven't exactly figured out what triggers it. Simpler programs don't seem to have this problem. Hope the above is useful anyway...

  • Like 1
Link to comment
Share on other sites

How deep is the function call stack when this happens? Are you running out of stack space? (I wouldn't know how to test this in the C environment).

 

Mark

 

Good question, but I don't think I'm running out of stack space. The stack pointer is stored in r10, so easy to follow with the js99er debugger. It starts at 0x4000 and grows down. Upon entry of the put_alex function, the stack pointer is 0x3fd6 so only 42 bytes deep. There is code in the lower expansion segment, but it only goes up to 0x32dc so still plenty of room for the stack to grow further down (a little over 3k).

 

In terms of call stack depth, it goes like this:

main() -> do_level() -> _do_level() -> game_loop() -> put_alex(int stance, int x, int y, unsigned char direction)

 

(The do_level() -> _do_level() call may look a bit odd, but this is just to enable bank switching: main is in bank 1, do_level is a trampoline function in lower expansion memory, _do_level sits in bank 2). All of these, except for the last one don't pass parameters and rely on global variables for state, so maybe that's where I need focus my efforts. I'm going to try re-working the code to pass less variables, to see if that changes anything. But it did use to work in version 12 of the patch, and I don't see anything in the changelog that might have impacted parameter passing (I think :) ).

Link to comment
Share on other sites

  • 5 weeks later...
  • 1 month later...

Ok, this compiler fork has got some bugs. This is infuriating.

 

Tursi was able to track down the issue with rs232_getbyte and rs232_setbyte, however, still being bitten in the arse with char and int idiosyncracies, and I need to find a way around them.

 

Case and point, I have a routine in my protocol decoder, called Key, which does the following:

 

given a Key:

 

(a) If the key is less than 0x80, it's a keyboard key, ripple through the translate table, and send its appropriate one byte keycode.

(b) If the key is larger than 0x80, it is a special output sequence (such as an echo packet, or a touch event), escape it and send it out as a three byte key sequence

 

(a) has an additional constraint that handles access keys (e.g. international keys)

 

Its code is the following:

/*----------------------------------------------*
 *      Key                                     *
 *                                              *
 *      Send a 10-bit internal key. If a keyset *
 *      key, translate, else send as escaped    *
 *      sequence.                               *
 *----------------------------------------------*/

void
Key (padWord theKey)
{
  if (theKey >> 7!=0)
    {
      io_send_byte (0x1b);
      io_send_byte (0x40 | (theKey & 0x3f));
      io_send_byte (0x60 | ((theKey >> 6) & 0x0f));
    }
  else
    {

      if (FlowControl == 0)
        theKey = PTAT0[theKey];
      else
        theKey = PTAT1[theKey];

      if ((theKey & 0x80)!=1)
        {
          io_send_byte (0x1b);
          io_send_byte (theKey & 0x7f);
        }
      else
        io_send_byte (theKey);
    }
}

Which gets translated to the following:


Key
        ai   r10, >FFFA
        mov  r10, r0
        mov  r11, *r0+
        mov  r9, *r0+
        mov  r13, *r0+
        mov  r1, r9
        sla  r1, >7
        abs  r1
        jne  L86
        mov  @FlowControl, @FlowControl
        jeq  L87
        movb @PTAT1(r9), r9
        srl  r9, 8
        li   r1, >1B
        bl   @io_send_byte
        mov  r9, r1
        andi r1, >7F
        mov  *r10+, r11
        mov  *r10+, r9
        mov  *r10+, r13
        b    @io_send_byte
L87
        movb @PTAT0(r9), r9
        srl  r9, 8
        li   r1, >1B
        bl   @io_send_byte
        mov  r9, r1
        andi r1, >7F
        mov  *r10+, r11
        mov  *r10+, r9
        mov  *r10+, r13
        b    @io_send_byte
L86
        li   r13, io_send_byte
        li   r1, >1B
        bl   *r13
        mov  r9, r1
        andi r1, >3F
        ori  r1, >40
        bl   *r13
        mov  r9, r1
        sla  r1, >6
        andi r1, >F
        ori  r1, >60
        mov  *r10+, r11
        mov  *r10+, r9
        mov  *r10+, r13
        b    @io_send_byte
        .size   Key, .-Key
        even

What the hell is going on, and why are values that are below 0x80 (e.g. 0x41 for A), sending a three byte sequence?

 

This code works in nine other compilers, three of them GCC variants. It even works in Small C on Z80. I am beyond aggravated.

 

-Thom

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