Jump to content
IGNORED

GCC for the TI


insomnia

Recommended Posts

A totally different issue I had to patch is in Shuriken:

https://github.com/Fabrizio-Caruso/CROSS-LIB/blob/master/src/games/shuriken/main.c#L804

where I had to patch the code with this:

            #if defined(BUGGY_GCC_TI99)
            uint16_t aux;
            aux = x_size*y_size;
            remaining_diamonds+=aux; 
            #else
            remaining_diamonds +=x_size*y_size;;
            #endif

because otherwise remaining_diamonds would be set to zero at the end of a loop invoking the above snippet.

You can reproduce it in Cross-Lib by removing the #if defined(...) directive and running:

xl clean && xl rebuild shuriken ti99

  • Like 1
Link to comment
Share on other sites

I also have two more (probably similar) old issues that I may already posted long ago in this thread:

These issues are about an error by 1 in a operation involving unsigned chars:

in the Chase game (built with `xl clean && xl rebuild chase ti99`)
https://github.com/Fabrizio-Caruso/CROSS-LIB/blob/master/src/games/chase/split_files/main.c#L595

and in the Shoot game (built with `xl clean && xl rebuild shoot ti99`)
https://github.com/Fabrizio-Caruso/CROSS-LIB/blob/master/src/games/shoot/split_files/main.c#L694

Link to comment
Share on other sites

Thanks @Fabrizio Caruso these are all related to ops on uint8_t values.  As mentioned, I think the machine description code for handling bytes is a bit suspect.  For example the test for zero for byte instructions md is:

 

(define_insn "tstqi"
  [(set (cc0)
       (match_operand:QI 0 "nonimmediate_operand" "rR,Q"))]
  ""
  {
    output_asm_insn("jeq  0",       operands);  /* +0: No-op instruction with zero at +1 */
    output_asm_insn("cb  %0, @$-1", operands);  /* +2: Compare value against the zero at +1 */
    return("");
  }
  [(set_attr "length" "4,6")])


which creates an assumption that the instruction immediately preceding the CB contains a zero as the last byte which I don't think is valid when the optimiser can remove or reorder instructions.

Probably better just to use a MOVB %0,%0 to compare a memory location to zero and a MOV if the operand is a register.  I just need to ensure that the compiler is zeroing the top byte of a register when doing byte ops with regs.  If not, I'll make a copy to a scratch reg and do ANDI >00FF first.  I'll do some more testing.  We should focus on getting it functional first and fast second.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, khanivore said:

I just need to ensure that the compiler is zeroing the top byte of a register when doing byte ops with regs.  If not, I'll make a copy to a scratch reg and do ANDI >00FF first.  I'll do some more testing.  We should focus on getting it functional first and fast second.

Not sure if this is relevant but over on the Forth compiler side we have resorted to using 

 SRL R?,8  

 

 after fetching a byte from memory with MOVB, to get the byte to the other side and clear the other bits in one instruction. 

  • Like 2
Link to comment
Share on other sites

24 minutes ago, TheBF said:

Not sure if this is relevant but over on the Forth compiler side we have resorted to using 

 SRL R?,8  

 

 after fetching a byte from memory with MOVB, to get the byte to the other side and clear the other bits in one instruction. 

Yep, the "zero_extendqihi2" (extend byte to int) does exactly that.  The compiler knows we are big-endian so it understands byte moves result in a high byte in a 16-bit reg.  It seems intermediate ops on byte values are upgraded to 16-bit so just a MOV as compare will probably be ok for regs. 

But "tstqi" is just a compare to zero.  The MOV works unoptimised but not when I apply -O2 so I just need to check the syntax of the machine def.

  • Like 1
Link to comment
Share on other sites

4 hours ago, khanivore said:

 
I just need to ensure that the compiler is zeroing the top byte of a register when doing byte ops with regs.  If not, I'll make a copy to a scratch reg and do ANDI >00FF first.  

Size/speed trade off there: 

SB R0,R0

vs

ANDI R0,>00FF

Reading IOP is I think faster  but takes 2 words. 
 

  • Like 2
Link to comment
Share on other sites

3 hours ago, khanivore said:

But "tstqi" is just a compare to zero.  The MOV works unoptimised but not when I apply -O2 so I just need to check the syntax of the machine def.

Debugging this, but have to sign off now.  For some reason that I haven't bottomed out on yet, gcc barfs on the %0 because it thinks the parameter should be a constant, but it's a register (!?).  Quick fix is just to delete the machine definition of tstqi (line 174 in gcc-4.4.0/gcc/config/tms9900/tms9900.md) which forces the compiler to do a comparison which works.

Link to comment
Share on other sites

3 minutes ago, Fabrizio Caruso said:

@khanivore I am trying to re-install the compiler on a new PC under Cygwin 64-bit what do I need to be able to use the install.sh script?
wget is necessary
It now fails with an error on patch. I suppose that is also necessary.
Any other dependencies?

Can you pm me the error?  Wget or curl is needed and couple of other libraries

Link to comment
Share on other sites

@khanivore

configure: error: Building GCC requires GMP 4.1+ and MPFR 2.3.2+.
Try the --with-gmp and/or --with-mpfr options to specify their locations.
Copies of these libraries' source code can be found at their respective
hosting sites as well as at ftp://gcc.gnu.org/pub/gcc/infrastructure/.
See also http://gcc.gnu.org/install/prerequisites.html for additional info.
If you obtained GMP and/or MPFR from a vendor distribution package, make
sure that you have installed both the libraries and the header files.
They may be located in separate packages.
=== Failed to configure GCC ===

 

Link to comment
Share on other sites

11 minutes ago, Fabrizio Caruso said:

@khanivore

configure: error: Building GCC requires GMP 4.1+ and MPFR 2.3.2+.
Try the --with-gmp and/or --with-mpfr options to specify their locations.
 

 

I'm afraid I don't know how to install those libs in cygwin.  In debian/ubuntu it's just "apt install" but I don't think apt is part of cygwin.  You built gcc before on cygwin though didn't you?  That part of the build hasn't changed.

  • Like 1
Link to comment
Share on other sites

@lucien2 Thanks!
@khanivore You can install all packages with the very same original installer used to install Cygwin. The problem one may have is that the name of the packages could change. I have been able to install all the packages listed by @lucien2 through the setup installer. It is now building...

I have read about apt-cyg that may work similarly to apt-get but I have no experience with it. It may be useful if the script could take care of all the dependencies also under Cygwin.

Link to comment
Share on other sites

@arcadeshopper sure, for two reasons:

1. Why not? as Cygwin and MSYS2 are POSIX-like environments and I want to support all POSIX environments including non-Linux systems such as Free BSD, MacOS, Windows/Cygwin, Windows/MSYS2, etc. and not just Linux. I also support Windows Subsystem for Linux and of course Ubuntu. Whoever decides to try Cross-Lib won't be forced to switch to Linux.

2. I primarily develop under Windows/Cygwin because Cross-Lib is about 200 different machines some of which are very rare and a good and dev-friendly emulator is only available under Windows. Wine is not always a practical solution in these cases. Same issue with some tools such as for example handle disk/tape/cartridge images.

 

For these two reasons I need the emulator working also under Cygwin.

You can try Cross-Lib under Ubuntu and it should just work.

Edited by Fabrizio Caruso
Link to comment
Share on other sites

I tried to install again the compiler under Cygwin 64-bit together with libti99, and after a few attempts I manage to install both.
Nevertheless it does not work and it requires more work 😞

When I try to build one of my games this is what I get:

 

/tmp/ccwfWD73.s: Assembler messages:
/tmp/ccwfWD73.s:1: Error: no such instruction: `pseg'
/tmp/ccwfWD73.s:2: Error: no such instruction: `even'
/tmp/ccwfWD73.s:4: Error: no such instruction: `def loc'
/tmp/ccwfWD73.s:5: Error: no such instruction: `loc'
/tmp/ccwfWD73.s:6: Error: no such instruction: `srl r1,8'
/tmp/ccwfWD73.s:7: Error: no such instruction: `a @gImage,r1'
/tmp/ccwfWD73.s:8: Error: no such instruction: `srl r2,>3'
/tmp/ccwfWD73.s:9: Error: no such instruction: `andi r2,>FFE0'
/tmp/ccwfWD73.s:10: Error: no such instruction: `a r2,r1'
/tmp/ccwfWD73.s:11: Error: no such instruction: `b *r11'
/tmp/ccwfWD73.s:12: Warning: .size pseudo-op used outside of .def/.endef: ignored.
/tmp/ccwfWD73.s:12: Error: junk at end of line, first unrecognized character is `l'
/tmp/ccwfWD73.s:14: Error: no such instruction: `ref gImage'
make: *** [Makefile_common:2719: cross_lib/display/display_macros.o] Error 1

 

Link to comment
Share on other sites

@mizapf

$ file /opt/gcc4ti/bin/tms9900-as
/opt/gcc4ti/bin/tms9900-as: MS-DOS executable

 

This Assembler was somehow working yesterday because I managed to build libti99. So I don't know what happened...

I am now trying to rebuild gcc for ti but the script won't rebuild it... Removing the target directory is not enough. I probably need to remove some temporary files.
I hope all of this were simple...

Edited by Fabrizio Caruso
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...