Working/usual/recommended cross-development configurations

GFA, ASM, STOS, ...

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2533
Joined: Sun Jul 31, 2011 1:11 pm

Re: Working/usual/recommended cross-development configurations

Post by Eero Tamminen »

Few Hatari notes...

I guess this was known, but one does not need to use "symbols" command in debugger. If one runs the program from GEMDOS drive directory and enters debugger, Hatari automatically loads the program debug symbols.

If you want to run your program with Hatari so that you give its command line arguments from outside the emulation, there's a Linux/Unix helper script for that:
https://git.tuxfamily.org/hatari/hatari ... rg-args.sh
ThierryC2022
Atarian
Atarian
Posts: 6
Joined: Thu Mar 31, 2022 7:31 pm

Re: Working/usual/recommended cross-development configurations

Post by ThierryC2022 »

At last, I found a way to build a basic but convenient project template for mixing C and assembler. Of course, I'm aware I'll have to further fine-tune several build/debug options.
I used this tutorial : https://www.fxjavadevblog.fr/m68k-atari ... bly-and-c/
... in which I enhanced the makefile by replacing all the hard-coded dependencies by generic ones (taking into account included files on the GCC and VASM side)... after fighting a bit with the makefile syntax and its debugging.
Work in progress :

Code: Select all

#SOURCES_DIR=.
BUILD_DIR=./build
DIST_DIR=./dist

# VASM PARAMETERS
ASM=vasmm68k_mot
ASMFLAGS=-Faout -quiet -x -m68000 -spaces -showopt

# GCC PARAMETERS
LIBCMINI=/opt/ATARI/libcmini
CC=m68k-atari-mint-gcc
CFLAGS=-c -std=gnu99 -I$(LIBCMINI)/include -g

# LINKER PARAMETERS
LINKFLAGS=-nostdlib -s -L$(LIBCMINI)/lib -lcmini -lgcc -Wl,--traditional-format

# Listage des sources C et assembleur
src_c = $(wildcard *.c)
src_asm = $(wildcard *.S)


all: prepare dist

prepare:
	mkdir -p $(BUILD_DIR)

# Compilation C
$(BUILD_DIR)/%.o: %.c
	$(CC) $(CFLAGS) $< -o $@

# Génération des dépendances C
# (par défaut pour GCC, elles vont dans le même répertoire que les .o)
$(BUILD_DIR)/%.o: %.c
	$(CC) $(CFLAGS) -MMD -MP $< -o $@

# Compilation ASM
$(BUILD_DIR)/%.O: %.S
	$(ASM) $(ASMFLAGS) $< -o $@

# Génération des dépendances ASM
# (ici, il faut explicitement préciser le répertoire)
$(BUILD_DIR)/%.O: %.S
	$(ASM) $(ASMFLAGS) -depend=make -depfile $(patsubst %.S, $(BUILD_DIR)/%.d, $<) $< -o $@

# Inclusion des fichiers de dépendances générés
-include $(patsubst %.c, $(BUILD_DIR)/%.d, $(src_c))
-include $(patsubst %.S, %.d, $(src_asm))

$(BUILD_DIR)/main.tos: $(addprefix $(BUILD_DIR)/, $(patsubst %.c, %.o, $(src_c)) $(patsubst %.S, %.O, $(src_asm)))
	$(CC) $(LIBCMINI)/lib/crt0.o \
	      $^ \
		  -o $@ $(LINKFLAGS);

dist: $(BUILD_DIR)/main.tos
	mkdir -p $(DIST_DIR)
	cp $(BUILD_DIR)/main.tos $(DIST_DIR) 	

clean:
	rm -rf $(BUILD_DIR)
	rm -rf $(DIST_DIR)
Now, the serious development tasks will begin, at last...
Thierry C.
Paris suburbs, France
wietze
Captain Atari
Captain Atari
Posts: 409
Joined: Fri Mar 01, 2013 10:52 pm

Re: Working/usual/recommended cross-development configurations

Post by wietze »

For your emulation and debugging needs, I recommend using tats hrdb: https://github.com/tattlemuss/hatari
sandord
Atarian
Atarian
Posts: 9
Joined: Sun Dec 02, 2018 1:42 am

Re: Working/usual/recommended cross-development configurations

Post by sandord »

chicane wrote: Mon Apr 04, 2022 9:08 am I use GGN's bigbrownbuild scripts (https://github.com/ggnkua/bigbrownbuild-git) to create a cross compiler that runs on Ubuntu. It supports GCC6 upwards, and there are some worthwhile performance improvements to generated code as compared to GCC 4, especially from GCC 7 onwards. I also use VASM to compile assembly language files.

For graphics drawing/manipulation, I use GIMP, and these graphics are converted to planar format, preshifted and so on using a set of homegrown PHP scripts that leverage the GD library.

My build process is tied together using Make, and all editing of code is done in Vim.

I execute the generated PRG files by specifying them as a command line parameter to Hatari (it can execute PRG files directly on the command line, on Linux at least). There's also a zip2st utility included with Hatari that can generate ST files when I have a need to create a disk image rather than just a PRG file.
I'm very interested in this bigbrownbuild approach. I was wondering if you got the test project in barebones working. I can't seem to and I'm not sure if that test project is broken or that my bigbrownbuild installation is.
chicane
Captain Atari
Captain Atari
Posts: 216
Joined: Mon Jul 02, 2012 11:25 am
Location: Leeds, UK

Re: Working/usual/recommended cross-development configurations

Post by chicane »

sandord wrote: Sun Apr 24, 2022 3:56 pm I'm very interested in this bigbrownbuild approach. I was wondering if you got the test project in barebones working. I can't seem to and I'm not sure if that test project is broken or that my bigbrownbuild installation is.
I've just managed to successfully compile the lolworld.prg, ctest.prg and cpptest.prg examples on Ubuntu 21.10. Would you be able to share the specific error messages you're seeing? Not sure if I'll be able to help but there may well be others who can.
User avatar
saulot
Captain Atari
Captain Atari
Posts: 289
Joined: Sat Sep 18, 2004 9:09 pm
Location: Warszawa
Contact:

Re: Working/usual/recommended cross-development configurations

Post by saulot »

I set up my projects to be able quickly switch toolchains (slight deviation from my former day job). I've used Vincent's gcc 4.3.4, but sometime ago I've switched to brownelf and latest compilers from Thorsten Otto pages, so I can use them under Cygwin and can use c99> (in 4.3.4 c99 was in infant state). For assembly vasm, but built in gcc m68k asm is ok too with proper switches.
Brownelf needs extra postprocessing step, but it isn't problem at all.
I use makefiles for quick projects, I've used SCons in my midi project to target various Atari targets. In my latest project I use CMake, because I had to target Windows/Linux (amd64 and arm), Atari and Amiga(:P) targets. Toolchains are detected with proper toolchain files, which is great. CMake isn't great at all, people love it or hate it. Probably Premake or Genie (premake spinoff) would be ok too, but I didn't use it for Atari projects.
I mostly test software on real machines (specifics of projects), my build scripts upload automatically everything via tcp/ip with uiptool with curl. You can launch exec via commandline too. I debug mostly with native ADebug / MonST. For m68k code HRDB with Hatari is great too.
For editing code VSCode is ok, Sublime Text, 10x editor (check it against Visual Studio ;)) or even Notepad++ whatever opens text file ;).
And last advice, automate everything via scripts to make iterations faster. Make shortcuts to make builds, launch emulator, debugger etc.. So, everything depends on context.
sandord
Atarian
Atarian
Posts: 9
Joined: Sun Dec 02, 2018 1:42 am

Re: Working/usual/recommended cross-development configurations

Post by sandord »

chicane wrote: Sun Apr 24, 2022 5:22 pm
sandord wrote: Sun Apr 24, 2022 3:56 pm I'm very interested in this bigbrownbuild approach. I was wondering if you got the test project in barebones working. I can't seem to and I'm not sure if that test project is broken or that my bigbrownbuild installation is.
I've just managed to successfully compile the lolworld.prg, ctest.prg and cpptest.prg examples on Ubuntu 21.10. Would you be able to share the specific error messages you're seeing? Not sure if I'll be able to help but there may well be others who can.
Thanks! In the meanwhile I'm in a conversation with the the repo owner at https://github.com/ggnkua/bigbrownbuild-git/issues/1 so let's see where that's going.
sandord
Atarian
Atarian
Posts: 9
Joined: Sun Dec 02, 2018 1:42 am

Re: Working/usual/recommended cross-development configurations

Post by sandord »

sandord wrote: Sun Apr 24, 2022 7:55 pm
chicane wrote: Sun Apr 24, 2022 5:22 pm I've just managed to successfully compile the lolworld.prg, ctest.prg and cpptest.prg examples on Ubuntu 21.10. Would you be able to share the specific error messages you're seeing? Not sure if I'll be able to help but there may well be others who can.
Thanks! In the meanwhile I'm in a conversation with the the repo owner at https://github.com/ggnkua/bigbrownbuild-git/issues/1 so let's see where that's going.
With their help I managed to get it working! :cheers:
chicane
Captain Atari
Captain Atari
Posts: 216
Joined: Mon Jul 02, 2012 11:25 am
Location: Leeds, UK

Re: Working/usual/recommended cross-development configurations

Post by chicane »

sandord wrote: Mon Apr 25, 2022 6:45 am With their help I managed to get it working! :cheers:
That's great news! I've found that the later versions of GCC provide quite a considerable performance jump over 4.6 - it's well worth the upgrade for those considering it. GCC 7 in particular was quite striking in terms of the quality of the generated code. The improvements are less noticeable (and perhaps detrimental) in subsequent versions.
ThorstenOtto
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2082
Joined: Sun Aug 03, 2014 5:54 pm

Re: Working/usual/recommended cross-development configurations

Post by ThorstenOtto »

chicane wrote: Mon May 02, 2022 7:57 am 've found that the later versions of GCC provide quite a considerable performance jump over 4.6 - it's well worth the upgrade for those considering it. GCC 7 in particular was quite striking in terms of the quality of the generated code. The improvements are less noticeable (and perhaps detrimental) in subsequent versions.
Do you have any proof for that? Or examples that demonstrate such performance boots?

My experience is the other way around. Although in general newer gcc versions have better optimizers, the 68k backend was never adopted to this. As a result, newer gcc versions for 68k produce larger and in some cases even worse code than before.

The main reason to use newer gcc versions imho is when you have to compile packages that make use of newer features that older versions don't provide, most of the time in C++ code.
chicane
Captain Atari
Captain Atari
Posts: 216
Joined: Mon Jul 02, 2012 11:25 am
Location: Leeds, UK

Re: Working/usual/recommended cross-development configurations

Post by chicane »

ThorstenOtto wrote: Mon May 02, 2022 10:54 am Do you have any proof for that? Or examples that demonstrate such performance boots?

My experience is the other way around. Although in general newer gcc versions have better optimizers, the 68k backend was never adopted to this. As a result, newer gcc versions for 68k produce larger and in some cases even worse code than before.
Interesting - thanks for the feedback. I acknowledge that results may vary under differing workloads, but my personal experience is that of switching from GCC 4.6 to GCC 7 during the development of Pole Position, at which point I was rewarded with a noticeable jump in frames per second - quite possibly in the region of 5% (and this being a codebase that already uses a significant amount of hand-written assembly). I'm afraid I don't have any concrete figures because it's several years back.

Some of the observed performance gains may also have come from the new LTO feature present in later GCC versions.
User avatar
metalages
Captain Atari
Captain Atari
Posts: 203
Joined: Thu Jun 06, 2013 5:14 pm
Location: France
Contact:

Re: Working/usual/recommended cross-development configurations

Post by metalages »

On my side : some emulation stuff in my framework to prototype on pc cross platform code. Then i can move on st emulator. I invoke devpack 3 under emulator from visual studio to assemble then i compiler + link everything with pure c. I have stayed on pure c because i was not sure of memory footprint. Also i have rewritten startup code to be able to compile without any standard lib / being able to run from bootsector without the os
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2533
Joined: Sun Jul 31, 2011 1:11 pm

Re: Working/usual/recommended cross-development configurations

Post by Eero Tamminen »

chicane wrote: Mon May 02, 2022 12:26 pm Some of the observed performance gains may also have come from the new LTO feature present in later GCC versions.
That can definitely affect things, at least in larger projects...
Post Reply

Return to “Coding”