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]

RE: MMU Off / Strict Alignment


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]