MMU Off / Strict Alignment

Jonathan S. Shapiro shap@eros-os.org
Wed Dec 18 09:14:00 GMT 2013


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?


Regards,


Jonathan S. Shapiro



More information about the Newlib mailing list