C compilers?

[+nanochess]

I would suggest using 'int ch' instead of 'char ch'.

[swapd0]

Did you check the assembly code?

Nope, but I'll have a look at it.

[swapd0]

Why the -S option doesn't work?

 

I get this, no 68000 opcodes at all.

#NO_APP
	.file	"game_over.c"
	.section	.gnu.lto_.profile.6dbf9b8b59d33dd,"",@progbits
	.string	"x\234cg```\004b\006"
	.string	""
	.string	"M"
	.ascii	"\t"
	.text
	.section	.gnu.lto_.icf.6dbf9b8b59d33dd,"",@progbits
	.string	"x\234cg``\220b@"
	.string	"\026\206\257\223\227\236ac\334\373\360];+\323\244\355\213\35723\203I\006"
	.ascii	"\245\307\013\333"
	.text
	.section	.gnu.lto_.jmpfuncs.6dbf9b8b59d33dd,"",@progbits
	.ascii	"x\234\205\223\333J\033Q\024\206\367\277'\325\224j\363\002\241"
	.ascii	"\027\022\202\210\025\237\314gH4\215\275\220\230\220bj5H\025T"
	.ascii	"\260\342\205\207\213jl5\306&\231\244V\355A+\321\240\026#T\rZ"
	.ascii	"ZQq\334\207e\220\266\023\007\366\f\263\366\277\376o\255=kj\031"
	.ascii	"cm\016V\271 o5\342\371\036`bY\006\0201\360\"\235\035\250\177"
	.ascii	"n\364\032\f\347\f\263p\213X\354\327t\311\245c\1778\346\340\276"
	.ascii	"\223\005\225\025\366\357\354\325i\005CB%\005g_\027\034:$D\363"
	.ascii	"pK\335\330ZW\201\334[\360N\030I\237\026\351\365\237R&f\266Oj"

[swapd0]

I think that one of the issues it's that strings constants are not aligned in memory, they are put together and some strings starts at an even address and others starts at even.

[LinkoVitch]

Maybe this is why gcc doesn't work and vbcc does? perhaps gcc is treating char as a unicode char? Instead of char perhaps use uint8_t instead? it's more explicit and *may* read single bytes rather than trying to optimise with a word?

 

Without knowing what the compiler is doing to your code it's all guesswork, sorry.

[LinkoVitch]

Perhaps this may be of some help? GCC Alignment in structs

Edited April 5, 2019 by LinkoVitch

[swapd0]

The strings are ascii/utf-8 (I've looked with a disk editor) but I don't know why some times it skips the first character or draw the first char wrong, but when I send it to the pc, the string it's ok.

 

I've used the alignment attribute in several parts, and it has fixed a lot of issues but still have some weird bugs, also some times I write some code and the game hangs in the intro, add a skunk_print to see if it's running the animation loop and it works.

 

I need to write some code to catch 68000 exceptions.

[42bs]

Anything is just fine with the C code. And gcc treats char as byte. And alignment is no problem for byte accesses.

So the root cause is something else.

 

If -S does not work, just try objdump -dS with the resulting object file to see the assembly.

 

BTW: Lauterbach (lauterbach.de) offers simulators for free. I use them often to inspect suspicious code.

[42bs]

Perhaps this may be of some help? GCC Alignment in structs

 

Completely different issue. It is a common error people make when coming from 8/16 bit to 32bit systems.

Anyway, here we have byte accesses. Therefore no alignment issue.

[42bs]

The strings are ascii/utf-8 (I've looked with a disk editor) but I don't know why some times it skips the first character or draw the first char wrong, but when I send it to the pc, the string it's ok.

 

I've used the alignment attribute in several parts, and it has fixed a lot of issues but still have some weird bugs, also some times I write some code and the game hangs in the intro, add a skunk_print to see if it's running the animation loop and it works.

 

I need to write some code to catch 68000 exceptions.

 

Can you post the object file?

[swapd0]

Anything is just fine with the C code. And gcc treats char as byte. And alignment is no problem for byte accesses.

So the root cause is something else.

 

If -S does not work, just try objdump -dS with the resulting object file to see the assembly.

 

BTW: Lauterbach (lauterbach.de) offers simulators for free. I use them often to inspect suspicious code.

 

I also tried the objdump but only got a text saying the file format, no disassembly.

[42bs]

 

I also tried the objdump but only got a text saying the file format, no disassembly.

 

This sounds weird.

[ggn]

Remove -flto and try again.

[swapd0]

Remove -flto and try again.

 

Ok, now it works, the source code it's ugly but as soon as I've a version that crashes I'll have a look at the sources.

 

I've tried to compile gdb with no luck, it looks that you only need a few functions to make read and write a memory address.

[swapd0]

I've compiled the game without -flto and the lives and the bonus it's printed ok. I still have some graphics glitches with Pauline when you finish a screen, also some times the "How high can you get" triggers an address error when I copy the raster colors.

 

Next thing to do it's to output registers values when an exception it's raised.

[42bs]

I've compiled the game without -flto and the lives and the bonus it's printed ok. I still have some graphics glitches with Pauline when you finish a screen, also some times the "How high can you get" triggers an address error when I copy the raster colors.

 

Next thing to do it's to output registers values when an exception it's raised.

 

I suggest an extra object for this (and other printf-debug info) which you can overlay where ever you want. And simply disable/enable it.

[Seedy1812]

LinkoVitch, on 08 Feb 2019 - 12:29 PM, said:

Take the address you get from end and make sure it is phrase aligned

move.l #end,d0
add.l #8, d0
and.l #$fffffff8, d0

Will leave you with a phrase aligned address in d0

if end is the first free byte then you could use

move.l #end,d0

addq.l #7,d0

and.b #$f8,d0

if end happens to be on a 8 byte boundary then you would incur an 8 byte gap

Edited April 8, 2019 by Seedy1812

[42bs]

Take the address you get from end and make sure it is phrase aligned

move.l #end,d0
add.l #8, d0
and.l #$fffffff8, d0

Will leave you with a phrase aligned address in d0

 

 

Rather:

moveq #-8,d0

and.l #end+7,d0

 

or better (if the assembler can handle it):

move.l #( end+7 ) & ~7,d0

 

Note: Don't waste cycles on-line you can invest off-line.

Edited April 8, 2019 by 42bs

[ggn]

Of course, if the label's address is static you can simply align it during build. For example (rmac):

 

.phrase

end:

[SCPCD]

Hi !

 

I'm currently working on an C app with multiple files and I'm using "m68k-atari-mint-gcc".

It works great, but after adding some more variables, I got an issue where a variable in BSS segment are not aligned with what I need :

 

When using gcc, all variable are aligned in word boundaries, but for specific ones, I need those to be longword aligned.

I tried to add " __attribute__((aligned(4)))" to have something as "u8_t toto[1024]  __attribute__((aligned(4)))" but at build time gcc give me the warning "warning: alignment of 'toto' is greater than maximum object file alignment.  Using 2 [enabled by default]" and finally the variable is not aligned to a longword.

 

Why gcc don't take account of the attribute and how to resolve the issue ?

 

Thanks

 

 

[swapd0]

What complier flags are you using? I had some similar issues and I fixed it (IIRC) changing the code generation flags, also my malloc routines align the data to a 16 bytes boundary and some data it's now created on the heap.

 

I'm using these flags

CODEOPTFLAGS = $(TARGETFLAGS) -Ofast -g -fomit-frame-pointer -fstrict-aliasing
CODEGENFLAGS = $(CODEOPTFLAGS) -fcaller-saves -ffunction-sections -fdata-sections
 

At first I had -flto option but it removed some alignment of some files.

 

[SCPCD]

All my C code are build with :

C2OBJ = m68k-atari-mint-gcc -Wall -I$(INCLUDE) -O3 -c -o obj/$*.o $?

[swapd0]

Sorry, I forgot to ask also about linker flags.

 

[42bs]

3 hours ago, SCPCD said:

Hi !

 

I'm currently working on an C app with multiple files and I'm using "m68k-atari-mint-gcc".

It works great, but after adding some more variables, I got an issue where a variable in BSS segment are not aligned with what I need :

 

When using gcc, all variable are aligned in word boundaries, but for specific ones, I need those to be longword aligned.

I tried to add " __attribute__((aligned(4)))" to have something as "u8_t toto[1024]  __attribute__((aligned(4)))" but at build time gcc give me the warning "warning: alignment of 'toto' is greater than maximum object file alignment.  Using 2 [enabled by default]" and finally the variable is not aligned to a longword.

 

Why gcc don't take account of the attribute and how to resolve the issue ?

 

Thanks

 

 

Try using the linker instead: Place toto in a section, than align this section with the linker script.

[ggn]

I'm not using Vincent's gcc build per se, but on my build of gcc 4.6.4 I don't see any errors about this: https://tinyurl.com/y6lu6u53. So the only options I see is Bastian's suggestion or building gcc on your own (script is always here: https://bitbucket.org/ggnkua/bigbrownbuild). Probably Bastian's solution will take less time :).