GNU assembler (ARM code)

[Mark Pulver]

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: <v11zdlqrjj.fsf@hodges.research.canon.com.au> <7o7ai3$q7l$1@kings-cross.london.uk.eu.org> <v1d7x37q1n.fsf@hodges.research.canon.com.au>
> --text follows this line--
> Mark Pulver <mpulver@research.canon.com.au> 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
to:
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)?

Thanks,
	Mark
_______________________________________________
New CrossGCC FAQ: http://www.objsw.com/CrossGCC
_______________________________________________
To remove yourself from the crossgcc list, send
mail to crossgcc-request@cygnus.com with the
text 'unsubscribe' (without the quotes) in the
body of the message.