This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: Will register window mechanism slow down the execution of ecos program for SPARC?
- From: "Qiang Huang" <jameshq at liverpool dot ac dot uk>
- To: "Nick Garnett" <nickg at ecoscentric dot com>
- Cc: "Ecos-Discuss" <ecos-discuss at sources dot redhat dot com>
- Date: Fri, 11 Oct 2002 10:22:06 +0100
- Subject: RE: [ECOS] Will register window mechanism slow down the execution of ecos program for SPARC?
Dear Nick, all:
Thank you Nick for your help.
The following code fragment (original comment included) is retrieved from
context.S of sparc architecture
.global hal_thread_switch_context
hal_thread_switch_context:
.......
......
.global hal_thread_load_context
hal_thread_load_context:
...
...
! DISABLE INTERRUPTS *ONLY* NOT TRAPS
rd %psr, %g6
or %g6, 0xfe0, %g5 ! PIL up to 15(disable interrupt) leave traps enabled
wr %g5, %psr
! force out all our callers register sets onto the stack
! if necessary: the system will handily take care of this for
! us as follows:
save %sp, -16 * 4, %sp ! need all these to preserve
save %sp, -16 * 4, %sp ! the linked list property...
save %sp, -16 * 4, %sp
save %sp, -16 * 4, %sp
#if 6 < __WINSIZE
save %sp, -16 * 4, %sp
#if 7 < __WINSIZE
save %sp, -16 * 4, %sp
#endif
.....
Note: #define __WINSIZE 8
Q1: It seems the program depends on the register windows overflow to saved
the whole register windows includes the unused register windows, am I wrong?
Won't that cause any latency?
Q2: Also while returns from the call the register window underflow trap will
responsible for restoring the all register windows, won't that cause any
latency?
Q3: If we just save and restore the used register window during the context
switch, could that speed up the program? Certainly the code size will be a
little larger, Am I wrong?
BTW I am trying to make the linker script and I am confused by some
question.(It might be simple to others but not for me, so sorry about for
such minor question bothering you).
Q4: In the linker script we define each section. some names are already
recognised by default eg. .data; .text; .bss .rodata But seems some are
user defined: .fini .fixup , are those necessary even I am not using those
sections?
Q5: Also is gcc_exception_table section user defined or already recognised
by default? if recognised by default I can't even find it out in the gcc and
GNUPro manual, so where should look for such info?
Q6: Any relation between .rodata and .rodata1? iIs .rodata1 also recognised
by default? .
Q7: In vectors.S normally " .section ".vectors","ax" " .vectors is
defined, Is there any relation between .vectors and .rom_vector ? Also the
label name "rom_vectors" is defined in vectors.S and the same name
rom_vector section is defined in linker script, any relation between those
two?
Thank you very much and look forward to hearing from you.
I am sorry about bothering you with so many questions. Thank you.
-----Original Message-----
From: Nick Garnett [mailto:nickg@ecoscentric.com]
Sent: 10 October 2002 19:46
To: Qiang Huang
Cc: Ecos-Discuss
Subject: Re: [ECOS] Will register window mechanism slow down the execution
of ecos program for SPARC?
"Qiang Huang" <jameshq@liverpool.ac.uk> writes:
> Hi all:
> I just wonder about whether the register windows will slow down the
> execution of ecos program.
> In sparc each time for context switching the old thread context will be
> saved this includes all the regiter windows(because this is done by an
> register window overflow trap), even not all register windows have been
> already used, consider a situation that just 2 register windows are used
but
> 8 register windows are saved(6 of those are not used).
I am not a SPARC expert but I believe that only register windows that
have been used generate a trap and get saved. Unused windows are
skipped - the save instruction has no effect.
> also when restoring
> all register windows will be restored (done by register window underflow
> trap).
Only one window is restored in the context switch. Any others will be
restored as a result of the call returns.
> Also this happens when a seperate interrupt stack is used. The
> purpose of introducing register window is to speed up the calling to an
> subfunction, but now in ecos it seems to be an shortcoming compared to
other
> target without register window for subfunction calling in the context
> switching and restoring. maybe I got it wrong then sorry about this.
Thanks
> a lot.
>
SPARC was designed to increase single threaded throughput at the
expense of context switch latency. While it is just about acceptable
for bandwidth-oriented systems like Solaris, it is fatal for real time
performance.
The SPARC architecture, or anything else that implements a similar
windowing system, is a bad choice for embedded work.
--
Nick Garnett - eCos Kernel Architect
http://www.eCosCentric.com/
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss