Want: Linux build of Atari's GCC 2.6.3 that targets JRISC: gcc263.tar.gz or gcc263_tar.gz

[+cubanismo]

It was recently pointed out to me that this file has been in the public before. I'm trying to find someone who stashed away a copy of it. References to it still exist:

 

https://www.yaronet.com/topics/72-54823-sdl-pour-jaguar-utilite-ou-pas

Which points to the dead link http://the.protos.free.fr/jaguar/gcc263.tar.gz near the bottom of the page. No hits on internet archive wayback machine for that URL. Further up in that thread, you find a working link to the equivalent DOS build http://fadest.free.fr/gcc263pc.zip which does still work, and I believe is the same DOS build of the gcc-for-GPU compiler already included in my jaguar SDK package.

 

http://jagware.org/jag_uploads/dev/cts_jagdev/index.html

Which points to http://jagware.org/jag_uploads/dev/cts_jagdev/gcc263_tar.gz, which is also a broken link, and again no hits on the wayback machine.

 

Anyone have this lying around and cares to share?

[ggn]

Pinging @Zerosquare

[Zerosquare]

Here you go:

GCC263_TAR.GZ

[+cubanismo]

Awesome. I'll get these integrated with my SDK. They are a.out binaries, but they run fine with the a.out userspace loader my SDK uses to load MADMAC and ALN. This will of course make it much easier for SDK users to experiment with the GCC-for-GPU compiler 😁

 

Perhaps of more practical application, since this gcc seems to support both 68k and GPU targets, users of my SDK should now be able to switch back and forth between building their projects entirely with Atari's original GCC, ALN, and MADMAC tool chain, or my newer 68k GCC 3.x build and RMAC/RLN, all on modern Linux kernels/distros thanks to the a.out loader wrappers, and all just by changing a few variables in their Makefiles if they're set up to use the usual $(CC) and similar variables in their rules. The Makefiles for all the sample code in the SDK can all be toggled at once, for example, just by editing jagdefs.mk. This will make it really easy to perform comparisons and characterize bugs or behavior differences between the tool chains!

[+cubanismo]

I was a little overly optimistic here. The gcc front-end "driver" and the "agpu" JRISC compiler backend (cc1) and preprocessor (cpp) work fine with the a.out loader, but the m68k backend stuff (cc1, cpp) do not. They want at least some minimal dynamic linking support unfortunately. Still, I'll get this integrated with my SDK shortly for the GPU C compiler support. Getting the m68k binaries to play nice would probably take  considerably more work, so I don't have any plans to try to adapt that. It can still be run on old kernels in VMs and whatnot of course, so it's still nice to have around.

[Zerosquare]

18 minutes ago, cubanismo said:

Getting the m68k binaries to play nice would probably take  considerably more work, so I don't have any plans to try to adapt that.

The standard GCC 2.63 did support the 68000, so unless there were Jaguar-specific stuff added, maybe you could just rebuild it from source using a modern compiler?

Edited September 1, 2023 by Zerosquare

[+cubanismo]

I think significant modifications were made (E.g., it appears to have output MADMAC-syntax assembly rather than GNU format, as the "as" included is a symlink to mac), and I don't know exactly how it was configured.

[ggn]

6 hours ago, cubanismo said:

and I don't know exactly how it was configured.

At least with version 4 onwards you can type "gcc --verbose" and it'll give you the exact command line the compiler was configured.

[dilinger]

18 hours ago, Zerosquare said:

The standard GCC 2.63 did support the 68000, so unless there were Jaguar-specific stuff added, maybe you could just rebuild it from source using a modern compiler?

Some years ago, I have tried to generate the GCC 2.63 and 2.95.3 (both with M68K) for windows and unfortunately got various errors during the compilation, on cygwin, MinGW and Msys2. All in 32 bits.

In theory, it should compile on Linux.

Edited September 1, 2023 by dilinger