GCC for the TMS9900 (new thread)

[+MarkB]

Hi,

 

I'm starting a new thread as the old gcc thread is very long and it is not as easy to find information as it should be.

 

The GCC for the tms9900 project adds the tms9900 as a back end for the GCC compiler and a collection of binary utilities (binutils) for assembling, linking, etc.  Any front-end language supported by GCC is supported (C, C++, etc).  The source code is on github here:

https://github.com/mburkley/tms9900-gcc.  The main branch always contains the most recent tested release.  The latest released version of GCC is 1.31 and binutils is 1.11.  The 1.31 release primarily adds support for aarch64/arm64 (used as default by Raspberry Pi 5). 

 

There are a few options if you want to install and use this compiler.  You can pull the source code and build using the script install.sh.  As far as I know this is the only option if you are a Mac user.  To do this, clone the repo and run the install script.  The target directory is wherever you want gcc to be installed (e.g. ~/tms9900-gcc or /usr/local/tms9900-gcc) :

git clone https://github.com/mburkley/tms9900-gcc.git
sudo apt install build-essential libgmp-dev libmpfr-dev
cd tms900-gcc
./install.sh <target>

 

If you are running a debian derived Linux distro natively or in WSL for Windows then you can fetch a pre-compiled debian package from ti99ers.com.  Here there are two options as well.  You can fetch a specific .deb directly from the repo if you know the version number.  e.g.

wget https://ti99ers.com/tigcc/pool/main/t/tms9900-gcc/tms9900-gcc_1.30_amd64.deb
sudo dpkg -i tms9900-gcc_1.30_amd64.deb

 

Alternatively, you can add the repo and associate public key to your sources list as follows.  There are more steps here, but it does mean you will always get the latest version for your architecture when you run apt update:

sudo mkdir -p /root/.gnupg
sudo chmod 700 /root/.gnupg
sudo gpg --recv-keys --keyserver keyserver.ubuntu.com 3F3CB45EF87C257D
sudo gpg -ao /etc/apt/trusted.gpg.d/tms9900-gcc-archive-keyring.asc --export 3F3CB45EF87C257D
sudo echo deb [signed-by=/etc/apt/trusted.gpg.d/tms9900-gcc-archive-keyring.asc] https://ti99ers.com/tigcc bookworm main | sudo tee /etc/apt/sources.list.d/tms9900-gcc.list
sudo apt update
sudo apt install tms9900-gcc

 

The future development branch gcc14 is upgrading the version of GCC from 4.4.0 to 14.1.0 and the version of binutils from 2.19.1 to 2.42.  Once stable, I'd like to make this the mainline version as it is much newer.  It needs a bit of work yet though.

 

Thanks

 

Mark

 

 

[Gary from OPA]

looks great, glad the ti99ers repo is working out well. if any other ti99/geneve developers need a directory for files or projects to serve them to the ti99 community online via the ti99ers.com domain, just send me a PM and I will arrange it for you.

 

I am running myself a windows linux sub-system on my windows 11 desktop, which is of course on amd-x86-64bit system, so what is the best way for me to setup the apt so its always updated on my setup, as i see the above script you posted mentioned bookworm, and i have no want yet to compile on a raspberry.

 

thanks.

 

p.s. if someone like a mod (cs1 where are you), could edit the first post of the older GCC thread, to point to the new thread, that would be great as well.

Edited July 29 by Gary from OPA

[+MarkB]

5 minutes ago, Gary from OPA said:

what is the best way for me to setup the apt so its always updated on my setup, as i see the above script you posted mentioned bookworm, and i have no want yet to compile on a raspberry.

What distro did you install in wsl? If it’s a recent Ubuntu the same steps should work. The repo had debs for both amd64 and arm64

[Gary from OPA]

4 minutes ago, MarkB said:

What district did you install in wsl? If it’s a recent Ubuntu the same steps should work. The repo had debs for both amd64 and arm64

i am running ubuntu 20.04.6 -- i know there is now newer ones, but currently i need to be using 20 until i made some changes to other things i am running.

[+MarkB]

6 minutes ago, Gary from OPA said:

i am running ubuntu 20.04.6

Looks like you’re still on bullseye in that case. Im not sure I have any machines still running bullseye but will take a look.

[Gary from OPA]

10 minutes ago, MarkB said:

Looks like you’re still on bullseye in that case. Im not sure I have any machines still running bullseye but will take a look.

yeah, i need to do an upgrade. have to see how soon i can do that without breaking what i am running. but with windows sub-system, i can have more than one distro running, so i could spin up another one using the newer ubuntu as well, i will have to look at that later on this week. the problem i had before is i want to use wsl 1, as the newer wsl 2 breaks the way i am networking some devices, and doesn't allow me to properly host my own apache server that is available to the outside world as well, i had no issues with wsl 1, but it installs 20.04 whereas wsl 2 installs 22 -- i have more playing around to do to see how i can run the latest distro and still keep my setup working.

Edited July 29 by Gary from OPA

[+MarkB]

15 hours ago, Gary from OPA said:

yeah, i need to do an upgrade. have to see how soon i can do that without breaking what i am running.

I have good news ... with a slight caveat.

I found an older VM that was running bullseye so I fired it up, ran install and created a 1.30 deb package and uploaded it to the repo.

The only problem is I can't have different distributions with the same component in the same pool.  So for bullseye, I changed to component to "contrib" instead of "main".  You'll need to replace "bookworm main" with "bullseye contrib" and apt update again.  I've tested this here and it seems to work.

[+FarmerPotato]

Attempting to build on MacOS  Ventura 13.6.   XCode 15.0 command line tools.

 

% uname -srpm
Darwin 22.6.0 x86_64 i386

 

Issues with  binutils-2.19.1

 

1. configure doesn't define STDC_HEADERS=1 in config.h and compile fails.  Workaround: edit every config.in file to define it.

2. ./bfd/doc/elf.texi at line 11 @subsubsection causes makeinfo to error out.  Workaround: replace with @subsection

 

 

/* Define to 1 if you have the ANSI C header files. */
#define STDC_HEADERS 1

 

Issues with gcc-4.4.0

 

1. same as #1 above.  

2. functions not declared in header:  tms9900_asm_output_dwarf_delta, tms9900_asm_output_dwarf_offset

 

Workaround: I added the function prototypes into tms9900.h

Last error: same for tms9900_address_type.

 

 

 

 

[Gary from OPA]

7 hours ago, MarkB said:

I have good news ... with a slight caveat.

I found an older VM that was running bullseye so I fired it up, ran install and created a 1.30 deb package and uploaded it to the repo.

The only problem is I can't have different distributions with the same component in the same pool.  So for bullseye, I changed to component to "contrib" instead of "main".  You'll need to replace "bookworm main" with "bullseye contrib" and apt update again.  I've tested this here and it seems to work.

looks like it worked for me see screenshot of my install. -- i never used gcc before, is there a sample little program i can run to compile to make sure it all working?

[+MarkB]

14 hours ago, Gary from OPA said:

looks like it worked for me see screenshot of my install. -- i never used gcc before, is there a sample little program i can run to compile to make sure it all working?

Cool, thanks for verifying those steps.  There isn't a cleanly packaged example that I know of, but a start might be to download and build libti99 (https://github.com/tursilion/libti99).  This library will be needed anyway if you want to output anything to the screen,  There is a file example.c there that prints a hello world message using.  I notice though that libti99 doesn't include utils such as elf2ea5 and ea5split.  I have included these in the GCC source repo in the common directory.  We should probably make a standalone test / example suite at some point.

 

EDIT: if you just want to do something really simple to verify it is compiling then you could just do:
 

mark@raspberrypi:/tmp $ cat>test.c
void func()
{
    int x=42;
}
mark@raspberrypi:/tmp $ /opt/tms9900-gcc/bin/tms9900-gcc -S test.c

mark@raspberrypi:/tmp $ cat test.s
	pseg
	even
LC0
	data	42
	even
	def	func
func
	dect r10
	mov  r9, *r10
	dect r10
	mov  r10, r9
	mov  @LC0, *r9
	inct r10
	mov  *r10+, r9
	b    *r11
	.size	func, .-func

 

Edited July 31 by MarkB
add simple example

[+MarkB]

14 hours ago, FarmerPotato said:

Attempting to build on MacOS  Ventura 13.6.   XCode 15.0 command line tools.

Thanks for trying it out on Mac.  Are you building the main branch or the 1.31 branch? It's odd that the "STDC_HEADERS=1" issue is only showing up now.

(edit: just noticed it's x86 so no advantage to using the 1.31 branch at this time)

 

14 hours ago, FarmerPotato said:

2. ./bfd/doc/elf.texi at line 11 @subsubsection causes makeinfo to error out.  Workaround: replace with @subsection

There seems to have been a change to texinfo recently that is causing errors when building the documentation.  I've made some updates on the 1.31 but I didn't see the error above.  @speccery has suggested "export MAKEINFO=missing" as a way to avoid building docs.

 

I've a feeling that continuing to maintain gcc 4.4.0 is going to be more and more work as systems around it are changing and that I should really focus on getting gcc-14.1.0 stable.

[speccery]

Having gcc for the TMS9900 is indeed great. As I have stated on various threads, I am a Mac user and all the Macs I use arm apple silicon based. I've tried a few times to compile gcc for that, and I know @MarkB has continued to work on it. It's possible that the latest changes might already work for the apple silicon Macs, but in the meantime I came up with another solution: I am now using a Raspberry pi Zero 2 in gadget mode as a build server. I am running that with 32 bit version of Raspberry Pi OS (the latest bookworm release), desktop turned off and I am using SSH to access the thing. I also installed Samba to be able to easily access files on it. I just confirmed that this works well, I once again built @TheMole's ghostbusters (what a fantastic project that is) on it and the resulting rpk works fine on js99er.net.

 

In case someone is not familiar with the gadget mode, it is explained here at Adafruit. I basically connect to the Pi over USB from my MacBook Air in this case. The Mac provides power, and the Pi appears as a network adapter. Using this setup there is only one USB cable between the two devices (well since it's a Mac I need to use USB-C to USB-A dongle and a micro usb cable). Portable and clean. The Pi runs headless, i.e. without a display. Compiling gcc on the Pi Zero 2 takes a long time, but the installation script works flawlessly.

 

As usual, to compile ghostbusters I needed to install @Tursi's libti99 and vgmcomp2 and fiddle around with makefiles, environment variables etc. but I've done it now so many times it goes fast. Compiling even a big project for the TI99 doesn't take long on the Pi. Of course in terms of compute power the Mac is a million miles ahead of the Pi Zero 2, but retrocomputer projects tend to be very small  

 

The side benefit of this is that since the Pi is running proper Linux, between it and macOS (with homebrew package manager) pretty much all Linux software can be run.

[TheMole]

On 8/9/2024 at 12:47 AM, speccery said:

As usual, to compile ghostbusters I needed to install @Tursi's libti99 and vgmcomp2 and fiddle around with makefiles, environment variables etc. but I've done it now so many times it goes fast.

Thanks for the kind words and useful feedback! I updated the Makefile a little bit, to at least detect missing dependencies and point you in the right direction. You also mention having had to fiddle around with environment variables? Not sure what you're referring to, would you mind elaborating?

 

[speccery]

19 hours ago, TheMole said:

Thanks for the kind words and useful feedback! I updated the Makefile a little bit, to at least detect missing dependencies and point you in the right direction. You also mention having had to fiddle around with environment variables? Not sure what you're referring to, would you mind elaborating?

 

The environment variables relate mostly if not all to @Tursi's projects, i.e. the dependencies. In his case there is no need to edit the his Makefile, since he uses the ?= notation when assigning values to variables, which skips the assignment if the variable is already there. It looks something like below in the Makefile, so IIRC there was no need to modify Makefile, just environment variables:

TMS9900_DIR?=~/gcc9900/bin

When setting up the compile environment, I do something like the following on the Linux shell before using make. This is partially from memory, partially from command history so perhaps not completely accurate nor complete.

export TMS9900_DIR=~/tms9900-gcc/bin
export ELF2EA5_DIR=~/Developer/ti-tools/
export EA5_SPLIT_DIR=~/Developer/ti-tools/
export LIBTI99=~/Developer/libti99/

# setup shared include files for ghostbusters, it looks for some include files at ../include
mkdir include
cd include/
ln -s ../vgmcomp2/Players/libtivgm2/*.h .
cd ../ghostbusters/
make

The include file stuff above is there since ghostbusters looks for some files in the include directory adjacent to the ghostbusters directory. I created symlinks to the vgmcomp2 stuff. This is perhaps not the right thing to do.

 

I didn't try out your new makefile, it seems to have a lot of checks in place which will be very helpful. It appeared that libti99 was not in the list of checks though. 

 

None of the above are showstoppers, thanks for making the code available, it really is great project and surely helpful for others creating TI games or other software!

Edited August 11 by speccery

[TheMole]

59 minutes ago, speccery said:

I didn't try out your new makefile, it seems to have a lot of checks in place which will be very helpful. It appeared that libti99 was not in the list of checks though. 

Thanks, I didn't know about the ?= trick, that's neat!

It's worth pointing out that I don't really use libti99 as distributed. I include the sound.h, TISNPlay.h and TISfxPlay.h headers and link against the libtivgm player. @Tursi does give permission to include the libti99 files directly in the project, so perhaps I should just do that so that everything can be built stand-alone without worrying about dependencies. I am a bit worried about the different compiler versions around though, I still use the insomnia patches (I'm on mac, so can't use @MarkB's version) and am not 100% sure the calling conventions haven't changed?

[+MarkB]

2 hours ago, TheMole said:

I am a bit worried about the different compiler versions around though, I still use the insomnia patches (I'm on mac, so can't use @MarkB's version) and am not 100% sure the calling conventions haven't changed?

Do you mean you can't use the pre-built debian packages?  You can still install the latest patches using the install script on MacOS.

In terms of compiler versions, the github main branch is still using gcc 4.4.0.  There are updated patch files (latest is 1.30) which are primarily bug fixes.  You're right that calling conventions can change and there is no guarantee that object or library files built using different versions will be compatible, but so long as you rebuild all your source code when you upgrade your compiler everything should work.  If not, let me know and I'll take a look or feel free to raise a bug on github https://github.com/mburkley/tms9900-gcc/issues

[TheMole]

21 minutes ago, MarkB said:

Do you mean you can't use the pre-built debian packages?  You can still install the latest patches using the install script on MacOS.

I always build from scratch using the install script, which works beautifully on my Ubuntu machine back home. But on my main dev machine (arm, macos), while it does compile and build just fine, I run into the issue described a while ago here:

 

I must admit that I haven't tried all patches released since then, but have tested a few and none seem to have resolved it. I'll try with the latest tomorrow and will let you know. Since @speccery seems to have issues on arm/macos as well, I figured it's unlikely to work and haven't actually tested in a while :).

 

[+MarkB]

Well 1.30 has been around for a while now and I haven't heard any new problem reports.  I just did a trial build of the head of your ghostbusters repo and didn't see any errors.

[TheMole]

On 8/12/2024 at 12:38 AM, MarkB said:

Well 1.30 has been around for a while now and I haven't heard any new problem reports.  I just did a trial build of the head of your ghostbusters repo and didn't see any errors.

Just to be clear on the issue I'm having: on my Ubunutu 24.04 machine back in Belgium, I am able to use 4.4.0-1.30 without any problems at all. It's only on my arm-based macbook pro which I use here in Hong Kong that I am not able to use your patches. I'm pretty sure this is just because the LLVM toolchain on arm macs is just too modern to compile older gcc versions properly... 

 

This weekend I finally got a moment to give building 4.4.0-1.30 on my arm mac another try, but couldn't get it to fully compile. I followed @Speccery's steps outlined in this post here, but the newly built compiler segfaults while trying to compile libgcc even before it's able to install the binaries in their final location:

/Users/themole/tms9900-4.4.0-1.30/build/gcc-4.4.0/build/./gcc/xgcc -B/Users/themole/tms9900-4.4.0-1.30/build/gcc-4.4.0/build/./gcc/ -B/Users/themole/tms9900-macos-arm/tms9900/bin/ -B/Users/themole/tms9900-macos-arm/tms9900/lib/ -isystem /Users/themole/tms9900-macos-arm/tms9900/include -isystem /Users/themole/tms9900-macos-arm/tms9900/sys-include -g -O2 -O2  -I../../gcc/config/tms9900 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition  -isystem ./include   -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc  -I. -I. -I../.././gcc -I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc -I../../../libgcc/../include  -DHAVE_CC_TLS -o __main.o -MT __main.o -MD -MP -MF __main.dep -DL__main -c ../../../libgcc/../gcc/libgcc2.c \
	  
../../../libgcc/../gcc/libgcc2.c: In function ‘__do_global_dtors’:
../../../libgcc/../gcc/libgcc2.c:2155: 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[1]: *** [__main.o] Error 1
make: *** [all-target-libgcc] Error 2
=== Failed to build libgcc ===

 

I think for modern macs, our best bet is to wait until you've managed to get the gcc13 port up and running. No pressure/rush, I still have an older (x86) build of Insomnia's patches that runs fine under Apple's rosetta emulation.

Edited August 17 by TheMole

[+MarkB]

6 hours ago, TheMole said:

 I'm pretty sure this is just because the LLVM toolchain on arm macs is just too modern to compile older gcc versions properly... 

Yes, quite probable.  I'm starting to see issues even with newer gcc versions having issues building gcc-4.4.0.

6 hours ago, TheMole said:

the newly built compiler segfaults while trying to compile libgcc

Coincidentally, I noticed this today as well.  @dhe was testing the 1.31 branch and noticed the same thing.  When I do a clean build I see it too.  I'm not sure why I haven't seen it before and I know this issue came up before but I can't remember how I fixed it in the past.  Anyway it's an assertion that incorrectly thinks 0xffff != 0xffffffff for signed 16-bit ints.  I'm going to just disable the assert on the 1.31 branch and retest everything.

6 hours ago, TheMole said:

our best bet is to wait until you've managed to get the gcc13 port up and running

Agreed.  It will hopefully clean up some of the current issues and bitrot that is starting to creep into gcc-4.4.0

[+dhe]

Your apt pupil is just waiting for instructions to try again! On ubuntu 24.04 on a PI5.

[+MarkB]

I've pushed a few fixes to the 1.31 branch and my tests are passing now.  There are one or two known broken tests but nothing new.  I'll merge this branch to main once it has been tested a bit more.

[+MarkB]

Hi all, I've merged version 1.31 to main and edit the first post in this thread to reflect the latest version.  Any issues please shout.

[+dhe]

I wanted to build a portable gcc build computer. To that end, I purchased a PI5, installed Ubuntu 24.04 (certified for the PI5) and installed TMS9900-GCC.

@MarkB helped me a lot, and it was a good test, because of 64-Bittyness and Architecture being ARM.

 

Here are my build notes, if anyone is interested.

 

It is my hope, that we can eventually get mltt going with xterm support, for a true put it in your coat pocket and take it with you experience.

 

gcc9900.rtf

[+jedimatt42]

I've been looking at ye-old-ti-tech-pages ( https://unige.ch/medecine/nouspikel/ti99/reals.htm ) regarding radix-100 encoding... and it seems this is not exactly TI's radix-100... 

 

Using the sample data on Theory's pages, I crafted these tests to observe:

 

  fc_tputs("1.020304050607: 4001020304050607 - "); // GOOD
  print_double_bytes(1.020304050607);
  fc_tputs("\n");

  fc_tputs("10.20304050611: 410102030405060B - "); // output was: 400A141E28323D0A
  print_double_bytes(10.20304050611);
  fc_tputs("\n");

  fc_tputs("0.5: 3F05000000000000 - "); // output was: 3F32000000000000
  print_double_bytes(0.5);
  fc_tputs("\n");

  fc_tputs("-10.20304050618: BFFF020305050612 - "); // output was: BFF6141E28323D50
  print_double_bytes(-10.20304050618);
  fc_tputs("\n");

  fc_tputs("0.0: 0000000000000000 - "); // GOOD
  print_double_bytes(0.0);
  fc_tputs("\n");

 

print_double_bytes iterates across the 4 words and prints them them in hex:

 

void print_double_bytes(double a) {
  int* bytes = (int*) &a;
  for (int i = 0; i < 4; i++) {
    fc_tputs(fc_uint2hex(bytes[i]));
  }
}

 

fc_tputs puts a string to the terminal.

fc_uint2hex converts an unsigned int to a 4 character hex string.

 

The encoding by the compiler seems to  be a little off. Is this known? It seems to be a valid format, but not the same as TI's format. 

 

Or, is Theory's data wrong? It seems to contradict the description:

 

Quote

Mantissa

The mantissa is seven bytes long. Each byte contains a number between 0 and 99 (>00 and >63), providing up to 14 significant digits. The decimal point is assumed to be after the first mantissa byte (i.e. after the second digit).

...

Examples

Exponent Mantissa                      Value              

>40      >01 >02 >03 >04 >05 >06 >07   1.020304050607

>41      >01 >02 >03 >04 >05 >06 >0B   10.20304050611

>3F      >05 >00 >00 >00 >00 >00 >00   0.5

>BF(-41) >FF >02 >03 >05 >05 >06 >12   -10.20304050618

>00      >00 >xx >xx >xx >xx >xx >xx   0 (any exponent!)