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?


Thanks Nick for your clear explanation. One thing I still confused about:

Does all the following section are necessary to be defined in using ecos:
.fixed_vectors  ;  .rom_vectors;  .text;  .fini;  rodata;  rodata1; (can I
just only define .rodata not both?);  .fixup(Is this necessary?);
.gcc_except_table;  .data;  .bss;  .heap1(can I define .heap not heap1??)

Thanks a lot
best regards!
qiang

-----Original Message-----
From: Nick Garnett [mailto:nickg@ecoscentric.com]
Sent: 11 October 2002 16:19
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:

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

The save instruction will do nothing for the unused register
windows. It is exactly like making a call into an unused window.

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

No more latency than any other return to an unused register
window. The context switch code does not restore all 7 windows.

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

We do only save the used windows, and restore only one. That is the
least amount of work we can do unless we allow register windows
belonging to different threads to be resident simultaneously. I would
not like to try debugging that.

Most of your questions would be easily answered if you were to read
the SPARC architecture manuals.

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

These are defined by the compiler or linker. They must be present.

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

gcc_exception_table is part of the C++ exception handling
mechanism. We don't use this at present but may do in the
future. Hence this section should be present.

You really don't need to know anything about this section, but if you
do then the GCC sources are probably your best bet.

>
> Q6: Any relation between .rodata and .rodata1? iIs .rodata1 also
recognised
> by default? .

Again, these are compiler defined sections. They must be present.

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

rom_vector is the output section into which the .vectors input sections
are linked.

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