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: 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


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