Working/usual/recommended cross-development configurations

[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]

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

[wietze]

For your emulation and debugging needs, I recommend using tats hrdb: https://github.com/tattlemuss/hatari

[sandord]

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]

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.

[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]

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]

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!

[chicane]

With their help I managed to get it working!

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]

'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]

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.

[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

[Eero Tamminen]

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