This is the mail archive of the ecos-discuss@sourceware.cygnus.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]

Re: eCos FP support suggestions.


Nick Garnett <nickg@cygnus.co.uk> writes:
>
> Sergei,
>
> Sorry that it's taken me a bit of time to get back to this.

Please don't mention it. I was busy as well :-)

Thank you so much for your explanations. You almost convinced me the
approach you are going to use is better, so I snip most of our discussion
below. While many of implementation details are still not clear to me,
I think I better don't bother you with questions about them to leave
more time for real work.

The only comment below.

> > 2. Anyway it'd be fine to have a way to define non-FP task
> > explicitly (and get "FP not available" exception if FP operation is
> > used). It will also allow to don't have "static" FP area at the base
> > of the stack for such light-weight task.
>
> This would be a reasonable optional enhancement to the basic
> mechanism. However, see my comments about the impact on the kernel
> interfaces later.
>
[...]
> We would also have to extend or change the kernel interface, since it
> would be necessary to either specifiy that a thread was FP using on
> creation, or notify the kernel of that fact later. This would either
> require the constructor for the Cyg_Thread class to be changed, or
> some new member functions to be added. These changes would then have
> to be reflected in the C API. All of this would have major effects
> on existing code and documentation. In general I want to avoid having
> to make such far-reaching changes if an alternative solution exists.

Well, I agree that C interface and documentation changes seem to be
unavoidable. However, it seems there is a way to do it without 
impact on existing user code (e.g. add another routine for task
creation that will create such a task or make task creation routine to 
take additional optional argument). On the other hand without it I must
pay extra, say, maximum of 256 bytes of stack (for full PowerPC  
FPU context) for every task in the system that I know will never use 
FP. Doesn't it overweight extra work of adding this support to the 
system and changing the documentation? 

It is also possible that other cases will occur later when it's
necessary to send some optional arguments to the task creation
routine. Don't you think it's better to have some mechanism in C
interface that will allow to make such additions in future?

Another solution would be to put FP related static data on top of
stack, not at the bottom. This will allow to just allocate less stack
space for non-FP task in hope that this task will never execute FP
operation. It has obvious drawback of loosing ability to get "FP
unavailable" exception if the task actually executes FP instruction
though.

BTW, if you have a guess when lazy FP switch support might be
implemented in the MIPS HAL, please let me know.

Best Regards,
Sergei.


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