On Thu, Mar 4, 2010 at 2:03 PM, Dan Horák <dan(a)danny.cz> wrote:
Dennis Gilmore píše v Čt 04. 03. 2010 v 13:49 -0600:
> On Thursday 04 March 2010 01:26:07 pm Chris Tyler wrote:
> > On Thu, 2010-03-04 at 12:04 -0600, Adam Miller wrote:
> > > RAM is a really good point, I think it will be in the ballpark of 256
> > > (plus or minus a bit). Also, I'd like to open up the conversation
> > > about version of ARM we as a SIG want to support as the efforts start
> > > to ramp up while targeting popular devices. I think ARMv9 might be a
> > > little too aggressive but are there any devices that are still
> > > prominent that are ARMv5? Would it be possible (or even feasible) to
> > > maintain ARMv5, ARMv7, and ARMv9 in parallel and treat them as
> > > separate architectures?
> >
> > The ARM "Family" vs. "Architecture" numbering is wonky (and
very
> > frustrating - larger numbers don't reliably mean newer, bigger, faster,
> > or better). The SheevaPlug uses an "ARM9E" family chip, which uses
the
> > "ARMv5TEJ" architecture. ARMv5 is a needed current target for that
> > device and others.
> >
> > However, the popular Cortex chips use ARMv6M and ARMx7* architecture. Is
> > there enough performance difference to warrant targeting both
> > independently? And just the kernel, or userspace as well?
>
> I suspect building different optimised glibc andl openssl might be enough.
> there could be some other packages that could benefit from different
> optimisations things like theora etc.
That's also my opinion.
Dan
_______________________________________________
arm mailing list
arm(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
This really might be my ignorance in the ARM world shining, but a big
point I would worry about would be power management support that I
assume would matter on the versions as they are SOC. But at the same
time I don't even know that has to do with the software. Anyone have
any insight into this?
-AdamM
--
http://maxamillion.googlepages.com
---------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\
www.asciiribbon.org - against proprietary attachments