MPC555 : wrong assembly instruction with GCC
SMIALEK Yan
Yan.SMIALEK at criltechnology.com
Tue Apr 30 13:50:38 UTC 2002
I work on a 603 and MPC555.
That's true, differences between CPUs are not clear.
In the MPC555's product brief from MOTOROLA, we can read : MPC555 core with
floating-point unit
We can see too : The MPC555's 32-bit Core - compliant with the PowerPC
instruction set architecture
It's not very clear, and I can understand that it may be difficult to make a
standard code for POWERPC processors.
Yan
-----Message d'origine-----
De: Joel Sherrill [mailto:joel.sherrill at OARcorp.com]
Date: mardi 30 avril 2002 15:18
À: Sergei Organov
Cc: Yan.SMIALEK at criltechnology.com; 'rtems-users at OARcorp.com'
Objet: Re: MPC555 : wrong assembly instruction with GCC
Sergei Organov wrote:
>
> Joel Sherrill <joel.sherrill at OARcorp.com> writes:
> > Sergei Organov wrote:
> > >
> > > It's not gcc. I believe gcc knows nothing about cache.
> > >
> > > Take a look at macro call
> > >
> > > _CPU_Data_Cache_Block_Flush( slot );
> > >
> > > at the end of the routine -- it's definition contains explicit asm
statement
> > > containing 'dcbf' instruction.
> >
> > In which case, RTEMS needs to wrap this with a conditional on CPU type
> > (or better yet move it to libcpu).
>
> Yes, it seems that there are still quite a few issues to be resolved in
the
> "new exception processing" code...
I think it is more likely that the sheer number of variations
in the PowerPC family is too blame. No single person has a
complete grasp on what changes or stays the same between
different PowerPC CPU models.
With help from a former Motorola Semiconductor person, I have
been trying to get a clearer picture of the CPUs. It turns
out there are only a handful of CPU cores which are used
again and again. There is a pattern to the part number which
indicates the core. The cache varies widely in spite of that.
Just to doublecheck my info, does the MPC555 have an FPU?
Is it essentially a 601 class CPU? From your perspective
it may look like a 603 with peripherals.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the users
mailing list