This is the mail archive of the
mailing list for the newlib project.
Re: MMU Off / Strict Alignment
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: "Schwarz, Konrad" <konrad dot schwarz at siemens dot com>, "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Wed, 18 Dec 2013 09:04:48 -0600
- Subject: Re: MMU Off / Strict Alignment
- Authentication-results: sourceware.org; auth=none
- References: <528CF7F1 dot 5050001 at codeaurora dot org> <CADSXKXqJgD3cq594+NeRk9=QHA1DKh3o7aPjsVYOx5OqT1Y6pw at mail dot gmail dot com> <52AF3E5A dot 4050507 at codeaurora dot org> <52B00D46 dot 6050302 at arm dot com> <CAAP=3QN-NHH+bONrB3P6oCEQ8R-aaULxJcR2_T_EdH5_EkZyQg at mail dot gmail dot com> <20131218141016 dot GU30010 at calimero dot vinschen dot de> <8A6D8E6D161CD644B982513286072E8D0B6326D3 at DEFTHW99EJ1MSX dot ww902 dot siemens dot net>
On 12/18/2013 8:54 AM, Schwarz, Konrad wrote:
> k> -----Original Message-----
>> From: email@example.com [mailto:firstname.lastname@example.org]
>> On Behalf Of Corinna Vinschen
>> Sent: Mittwoch, 18. Dezember 2013 15:10
>> To: email@example.com
>> Subject: Re: MMU Off / Strict Alignment
>> 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
>>> 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.
>>> 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?
> http://sourceware.org/newlib/ states that
> Newlib is a C library intended for use on embedded systems. It is a
> conglomeration of several library parts, all under free software
> licenses that make them easily usable on embedded products.
> Newlib is only available in source form. It can be compiled
> for a wide array of processors, and will usually work on any architecture
> with the addition of a few low-level routines.
> Initializing an MMU oversteps the definition of "a few low-level routines" in
> my book, especially since this is intended to refer to callbacks to UARTs
> and so on.
I thought it was a fairly common assumption in newlib to avoid
unaligned accesses in mem/str methods. Unaligned accesses may
be less efficient or generate a trap which puts more requirements
on the underlying environment.
What's the penalty for simply always doing the bulk of the copy
with aligned accesses?
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985