This is the mail archive of the newlib@sourceware.org mailing list for the newlib 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] |
On Dec 17 21:06, Jonathan S. Shapiro wrote: > At the risk of sticking my nose in, this isn't a startup code issue. > It's a contract issue. > > First, I don't buy Richard's argument about memcpy() startup costs and > hard-to-predict branches. We do those tests on essentially every > *other* RISC platform without complaint, and it's very easy to order > those branches so that the currently efficient cases run well. Perhaps > more to the point, I haven't seen anybody put forward quantitative > data that using the MMU for unaligned references is any better than > executing those branches. Speaking as a recovering processor > architect, that assumption needs to be validated quantitatively. My > guess is that the branches are faster if properly arranged. > > Second, this is a contract issue. If newlib intends to support > embedded platforms, then it needs to implement algorithms that are > functionally correct without relying on an MMU. By all means use > simpler or smarter algorithms when an MMU can be assumed to be > available in a given configuration, but provide an algorithm that is > functionally correct when no MMU is available. "Good overall > performance in memcpy" is a fine thing, but it is subject to the > requirement of meeting functional specifications. As Jochen Liedtke > famously put it (read this in a heavy German accent): "Fast, ya. But > correct? (shrug) Eh!" > > So: we need a normative statement saying what the contract is. The > rest of the answer will fall out from that. > > I do agree with Richard that startup code is special. I've built > deeply embedded runtimes of one form or another for 25 years now, and > I have yet to see a system where optimizing a simplistic byte-wise > memcpy during bootstrap would have made any difference in anything > overall. That said, if the specification of memcpy requires it to > handle incompatibly aligned pointers (and it does), and the contract > for newlib requires it to operate in MMU-less scenarios in a given > configuration (which, at least in some cases, it does), it's > completely legitimate to expect that bootstrap code can call memcpy() > and expect behavior that meets specifications. > > So what's the contract? I don't know anything about this contract, but what keeps people from extending memcpy for aarch to contain two sets of instructions, one with MMU-less instructions and one with MMU? Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat
Attachment:
pgpN0enDYa55n.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |