Re: MMU Off / Strict Alignment

[Joel Sherrill <joel dot sherrill at oarcorp dot com>]

On 12/18/2013 8:54 AM, Schwarz, Konrad wrote:
> k> -----Original Message-----
>> From: newlib-owner@sourceware.org [mailto:newlib-owner@sourceware.org]
>> On Behalf Of Corinna Vinschen
>> Sent: Mittwoch, 18. Dezember 2013 15:10
>> To: newlib@sourceware.org
>> 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
>> 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?
> 
> 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