Macro expansion errors

Hi, John,

I'd like to look into it if there is a case to reproduce.

Joey
On Nov 1, 2013 8:31 AM, "John Bradley" <email address hidden>
wrote:

> Question #238475 on GCC ARM Embedded changed:
> https://answers.launchpad.net/gcc-arm-embedded/+question/238475
>
> Description changed to:
> I was in the process of developing some code using the Sourcery Code
> Branch Tools when I got a little sick of put .aligns in all over the
> place this was what it was producing. So I switch tool chain to GNU
> Tools for ARM Embedded Processors which gave me a totally different set
> of errors, to do with MACRO expansion which I cannot fathom at all I
> copy the 2 different logs out here. The complete project is available if
> needed. It not a very clever hack of some Z80 to ARM.
>
> GNU assembler (Sourcery CodeBench Lite 2013.05-23) 2.23.52.20130219
> Copyright 2013 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License version 3 or later.
> This program has absolutely no warranty.
> This assembler was configured for a target of `arm-none-eabi'.
> arm-none-eabi-as -I source source/ace.asm -o build/ace.o
> source/ace.asm: Assembler messages:
> source/ace.asm:841: Error: misaligned branch destination
> source/ace.asm:3565: Error: misaligned branch destination
> source/ace.asm:3791: Error: misaligned branch destination
> source/ace.asm:3795: Error: misaligned branch destination
> source/ace.asm:3965: Error: misaligned branch destination
> source/ace.asm:4247: Error: misaligned branch destination
> source/ace.asm:4288: Error: misaligned branch destination
>
>
> GNU assembler (GNU Tools for ARM Embedded Processors) 2.22.0.20130913
> Copyright 2011 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License version 3 or later.
> This program has absolutely no warranty.
> This assembler was configured for a target of `arm-none-eabi'.
> arm-none-eabi-as -I source source/ace.asm -o build/ace.o
> source/ace.asm: Assembler messages:
> source/ace.asm:6082: Error: immediate expression requires a # prefix --
> `subs R3,R'
> source/ace.asm:6086: Error: immediate expression requires a # prefix --
> `subs R3,R'
> source/ace.asm:6090: Error: immediate expression requires a # prefix --
> `subs R3,R'
> source/ace.asm:6094: Error: immediate expression requires a # prefix --
> `adds R3,R'
> source/ace.asm:6095: Error: immediate expression requires a # prefix --
> `adds R3,R'
> source/ace.asm:6109: Error: end of macro inside conditional
> source/ace.asm:6109: Error: here is the start of the unterminated
> conditional
> source/ace.asm:6109: Error: here is the "else" of the unterminated
> conditional
> source/ace.asm: Error: end of file inside conditional
> source/ace.asm:6109: Error: here is the start of the unterminated
> conditional
> source/ace.asm:6109: Error: here is the "else" of the unterminated
> conditional
> make: *** [build/ace.o] Error 1
>
> --
> You received this question notification because you are an answer
> contact for GCC ARM Embedded.
>

Be my guest. The source is here https://drive.google.com/file/d/0BzqZlKsgcriVVHpiMElEQWVGYVk/edit?usp=sharing .It is just me trying to hack something a cross to refresh my assembler. So it not tidy. It started life as a disassembly of the jupiter ACE (Z*0)rom and I'm trying to take it to the Raspberry PI.

https://drive.google.com/file/d/0BzqZlKsgcriVVHpiMElEQWVGYVk/edit?usp=sharing

John,

If I understand correctly you are porting Z80 assembler to ARM. I'm not sure it is an applicable idea, as there are fundamental differences between these two arches and syntax of assembler languages.

It is not surprising that GNU assembler response strange error message as the behaviour is undefined.

If you have to do so, please do a through compare between these two arches and ASM, then decide how to port.

Thanks,
Joey

The main task is for me to get to know the differences and after I've done the hack to do a proper rewrite. My main concern is the difference in the errors between the two tool chains. I've worked around it now but have found several other situations where the chains be have differently. One example being when max debugging info is switched on.