This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Question about the ARM vector.S?


On Thu, 2003-01-23 at 04:10, Andrew Lunn wrote:
> On Thu, Jan 23, 2003 at 11:06:31AM -0000, Qiang Huang wrote:
> > Hi all:
> >     while installing the vector table use the table to store the VSR address
> > as:
> > 
> >         ldr     pc,.reset_vector                // 0x00
> >         ldr     pc,.undefined_instruction       // 0x04
> >         ldr     pc,.software_interrupt          // 0x08 start && software
> > int
> >         ldr     pc,.abort_prefetch              // 0x0C
> >         ldr     pc,.abort_data                  // 0x10
> >         .word   0                               // unused
> >         ldr     pc,.IRQ                         // 0x18
> >         ldr     pc,.FIQ                         // 0x1C
> > vectors:
> > UNMAPPED_PTR(reset_vector)                      // 0x20
> > PTR(undefined_instruction)                      // 0x24
> > PTR(software_interrupt)                         // 0x28
> > PTR(abort_prefetch)                             // 0x2C
> > PTR(abort_data)                                 // 0x30
> >         .word   0                               // 0x34
> > PTR(IRQ)                                        // 0x38
> > PTR(FIQ)                                        // 0x3c
> > 
> > Can I use the "LDR pc,=reset_vector" ... etc. ARM pseudo-instruction to
> > replace the "ldr pc,.reset_vector" and eliminate the table for storing the
> > VSR address? Thanks a lot.
> 
> The resulting code has to be 1 instruction. The hardware dictates that
> word 0 is the reset vector, word 1 is the undefined_instruction vector
> etc. If the pseudo-instructions is two real instructions, the
> undefined_instruction vector is actually going to contain part of the
> reset vector instruction....

In fact, the proposed instruction "ldr pc,=reset_vector" 
will generate the same code (load the value 'reset_vector'
from a pc-relative location that stores it).  The way I've
done it is better in that we have control over the layout
of those pointers, thus allowing them to be updated as
necessary.

FYI: the pseudo instruction
	ldr	pc,=reset_vector
generates this sequence
	ldr	pc,_LAB_reset_vector(pc)

  ... some indeterminate location later in the same section
_LAB_reset_vector:
	.long	reset_vector

So, you see there is no space savings and indeed a loss of
flexibility in doing it this way.

-- 
.--------------------------------------------------------.
|       Mind: Embedded Linux and eCos Development        |
|--------------------------------------------------------|
| Gary Thomas              email:  gary.thomas@mind.be   |
| Mind ( http://mind.be )  tel:    +1 (970) 229-1963     |
| gpg: http://www.chez-thomas.org/gary/gpg_key.asc       |
'--------------------------------------------------------'


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]