From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jonathan Larmour To: Chris Morrow Cc: ecos-discuss@sourceware.cygnus.com Subject: Re: [ECOS] hal_copy_data and hal_zero_bss Date: Mon, 26 Feb 2001 15:22:00 -0000 Message-id: <3A9AE517.255581C4@redhat.com> References: <3A6369EB.E071860B@YottaYotta.com> <3A63B257.4E238048@redhat.com> <3A99B9B6.444A2F22@YottaYotta.com> X-SW-Source: 2001-02/msg00402.html Chris Morrow wrote: > > An assembler version of hal_zero_bss is included > at the end of this message. I placed mine in > vectors.S. I'm not sure where you would like it. That's fine. Thanks! It'll be in the next anon CVS update. > Currently the start up code calls hal_copy_data before > hal_zero_bss. Since at this point the stack is in bss > when calling hal_zero_bss, I can understand why hal_zero_bss > needs to avoid memset(). If the order of calls to mem_copy_data > and hal_zero_bss were switched, what would prevent the use > of memcpy in hal_copy_data? I can't think of any initialized > data memcpy would depend on. We don't support it yet, but in future we may have profiling hooks for debug builds for example, or very detailed tracing/instrumentation. So for now I'd rather not introduce such a dependency. Jifl -- Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062 Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine