This is the mail archive of the
mailing list for the crossgcc project.
GNU assembler (ARM code)
- To: firstname.lastname@example.org
- Subject: GNU assembler (ARM code)
- From: Mark Pulver <email@example.com>
- Date: Thu, 5 Aug 1999 11:42:30 +1000 (EST)
- Reply-To: firstname.lastname@example.org
I'm having trouble translating ARM STD assembler into GNU assember.
I just posted this to comp.sys.arm: any comments:
> Newsgroups: comp.sys.arm
> Subject: Re: Brutus salib port to GNUS tools
> References: <email@example.com> <firstname.lastname@example.org> <email@example.com>
> --text follows this line--
> Mark Pulver <firstname.lastname@example.org> writes:
> > Now the problems I have left!
> > The only compile errors I have look like:
> > external.s:59: Error: Literal referenced across section boundry (Implicit dump?)
> > They all seem to be of the form:
> > .extern SAr_printf
> > ...
> > LDR lr, =SAr_printf @ error
> I found the following "info" page:
> > File: as.info, Node: ARM Opcodes, Prev: ARM Directives, Up: ARM-Dependent
> > Opcodes
> > -------
> > `as' implements all the standard ARM opcodes.
> > *TODO* Document the pseudo-ops (adr, nop)
> > GAS for the ARM supports a synthetic register load instruction whoes
> > syntax is:
> > ldr <register> , = <expression>
> > If expression evaluates to a numeric constant then a MOV or MVN
> > instruction will be used in place of the LDR instruction, if the
> > constant can be generated by either of these instructions. Otherwise
> > the constant will be placed into the nearest literal pool (if it not
> > already there) and a PC relative LDR instruction will be generated.
> > For information on the ARM or Thumb instruction sets, see `ARM
> > Software Development Toolkit Reference Manual', Advanced RISC Machines
> > Ltd.
> This seems to say that gas should handle this instruction (?). I suppose
> I could manul put the instruction in the pool, and ldr it from there.
> Maybe I've built gas wrong and this code it now turned on?
You maybe also able to help me with my other concerns with this
translation (I'm generating ELF objects):
My translating the AREA directives to .sections.
My script translated the following:
boot.s: AREA SelfBoot, CODE, READONLY
boot.s: AREA SA_BootRam, DATA
cmplxirq.s: AREA uHal_Traps, CODE, READONLY
control.s: AREA uHAL_Control, CODE, READONLY
divide.s: AREA |C$$code|, CODE, READONLY ; This module's code area. ;
driver.s: AREA |C$$code$$__ebsa110|, CODE, READONLY
driver.s: AREA uHAL_TTentries, DATA, NOINIT, ALIGN=14
driver.s: AREA uHAL_LCDFrame, DATA, NOINIT, ALIGN=16
external.s: AREA uHAL_external, CODE, READONLY
irqlib.s: AREA uHAL_IRQs, CODE, READONLY
irqlib.s: AREA SA_Irq, DATA
irqtrap.s: AREA uHal_Traps, CODE, READONLY
mmu.s: AREA uHAL_MMU, CODE, READONLY
boot.s: .section SelfBoot,"x"
boot.s: .section SA_BootRam,"w",@progbits
cmplxirq.s: .section uHal_Traps,"x"
control.s: .section uHAL_Control,"x"
divide.s: .section C$$code,"x" @ This module's code area. ;
driver.s: .section C$$code$$__ebsa110,"x"
driver.s: .section uHAL_TTentries,"w",@progbits, NOINIT, ALIGN=14
driver.s: .section uHAL_LCDFrame,"w",@progbits, NOINIT, ALIGN=16
external.s: .section uHAL_external,"x"
irqlib.s: .section uHAL_IRQs,"x"
irqlib.s: .section SA_Irq,"w",@progbits
irqtrap.s: .section uHal_Traps,"x"
mmu.s: .section uHAL_MMU,"x"
They all compiled, but are they correct?
My other concern is alignment. Does the .word directive force a 4 byte
alignment (like the DCD)?
New CrossGCC FAQ: http://www.objsw.com/CrossGCC
To remove yourself from the crossgcc list, send
mail to email@example.com with the
text 'unsubscribe' (without the quotes) in the
body of the message.