GNU and Freescale MPC83xx / e300 core support?

GNU and Freescale MPC83xx / e300 core support?

[Russell McGuire]

I was recently involved in a meeting with a Freescale FAE, which informed us
that the current revisions of the GNU C/C++ compilers do not yet possess any
optimizations for the MPC83xx cores, more precisely no optimizations for the
e300 cores inside the MPC83xx line up.

They did say it was 100% backwards compatible with the existing 603e / 6xx
core support, so all the code should work just fine.

I was curious if anyone out there was aware of any efforts to produce /
patch any of the GNU compilers to have optimizations for these newer
MPC83xx's with the e300 cores? 


Thanks,

-Russ

Re: GNU and Freescale MPC83xx / e300 core support?

[David Hawkins]

Russell McGuire wrote:
> I was recently involved in a meeting with a Freescale FAE, which informed us
> that the current revisions of the GNU C/C++ compilers do not yet possess any
> optimizations for the MPC83xx cores, more precisely no optimizations for the
> e300 cores inside the MPC83xx line up.
> 
> They did say it was 100% backwards compatible with the existing 603e / 6xx
> core support, so all the code should work just fine.
> 
> I was curious if anyone out there was aware of any efforts to produce /
> patch any of the GNU compilers to have optimizations for these newer
> MPC83xx's with the e300 cores? 
> 

Hi Russ,

Out of interest, what are the main differences that optimization
would help with?

I'm going to take a look at the 8349E, but I'm waiting on the
Freescale MDS board.

I haven't read the user manual in great detail, other than to
check out the potential bus performance, but I thought
the main change in the G2 vs e300 core was the cache size.
Did they add new instructions, or change the number-of-cycles
required for existing instructions?

The Freescale document:

   Freescale PowerPC™ Architecture Primer, POWRPCARCPRMRM,
   Rev. 0.1, 6/2005

   Has the following on page 12 of the PDF:

   e300 Cores and Platform
   The ongoing presence of the e300 testifies to the longevity
   of both the PowerPC architecture and the microarchitecture.
   The e300 was introduced in 1994 as the MPC603, running at
   100 MHz, and continues to be proliferated more than a decade
   later reaching speeds exceeding 600 MHz. The e300 PowerPC
   core and platform address the low- to mid-range performance
   needs of the market. The e300 core is an enhanced version
   of the popular PowerPC 603e core used in previous-generation
   PowerQUICC II devices that scale from 266 to 667 MHz in
   130 nm process technology. Enhancements include twice as
   much L1 cache as the 603e (32-Kbyte data and instruction
   caches) with integrated parity checking and other
   performance-oriented features. The e300 core is fully
   software-compatible with existing 603e core-based products
   and provides the processing foundation for the company's new
   MPC8349E PowerQUICC II™ Pro communications processor family.

So I guess the question is what are the

  'other performance-oriented features'

this statement is referring to?

The e300 core reference manual comments:

     The e300c1core integrates five execution units: an integer
     unit (IU), a floating-point unit (FPU), a branch processing
     unit (BPU), a load/store unit (LSU), and a system register
     unit (SRU). The ability to execute five instructions in
     parallel and the use of simple instructions with rapid
     execution times yield high efficiency and throughput
     for e300-core-based systems. Most integer instructions
     execute in one clock cycle. On the e300c1 core, the FPU is
     pipelined so a single-precision multiply-add instruction
     can be issued and completed every clock cycle.

So I guess an important optimization would be to keep each
execution unit busy. I haven't looked at an older 603e manual,
do they have fewer units?

Cheers
Dave

RE: GNU and Freescale MPC83xx / e300 core support?

[Russell McGuire]

All, 

Our meetings with Freescale were aimed specifically at the differences
between the MPC8280 and the MPC8360E. The most obvious core difference is
the Floating Point unit; the MPC8280, 603e or G2LE core had no floating
point ability at all.

I am not sure if its core support or not, but I know the MPC83xx line up has
drastically altered the bus architecture inside the chips. There are more
DMA engines now, and things like the DDR SDRAM bus and 60x / local Bus are
separated to run in parallel. Previously, in the 8260/8280 they were
mutually exclusive for bus cycles. Internally the shared bus now operates at
the DDR frequency, shortly to be DDR2 frequency for later masks. We should
see a very large performance improvement for memory intensive applications.
Same applies to the PCI 2.2 bus; it was also given separate pins and DMA
engines. According to the Freescale FAE the chip can handle simultaneous bus
cycles on all three busses at once. I do not have enough internal knowledge
on the compilers to know if this is a specific optimization, but it would
definitely hinder performance if we couldn't take advantage of it.

Freescale claims their newest revision of Metrowerks is optimized for these
newer cores, I guess one could get compile with a version of that and
disassemble it.

Aside:
I know the CPM of the older 82xx lineup has been removed, and so has the
optimization for its access to the 32 bit local bus. The QUICC engines have
replaced it and now have equal priority to all busses, though this probably
has little to do with the compiler.

Of random, if anyone is using the 'E' revisions of the 83xx lineup,
Freescale is claiming that the encryption engine is almost 10x faster than
their previous lineup of sister encryption chips that would normally partner
with the MPC8260 and MPC8280 chips.

I have another meeting tomorrow with Freescale, I can get more specifics.

-Russ

-----Original Message-----
From: David Hawkins [mailto:dwh@ovro.caltech.edu] 
Sent: Monday, March 06, 2006 6:27 PM
To: Russell McGuire
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: GNU and Freescale MPC83xx / e300 core support?

Russell McGuire wrote:
> I was recently involved in a meeting with a Freescale FAE, which informed
us
> that the current revisions of the GNU C/C++ compilers do not yet possess
any
> optimizations for the MPC83xx cores, more precisely no optimizations for
the
> e300 cores inside the MPC83xx line up.
> 
> They did say it was 100% backwards compatible with the existing 603e / 6xx
> core support, so all the code should work just fine.
> 
> I was curious if anyone out there was aware of any efforts to produce /
> patch any of the GNU compilers to have optimizations for these newer
> MPC83xx's with the e300 cores? 
> 

Hi Russ,

Out of interest, what are the main differences that optimization
would help with?

I'm going to take a look at the 8349E, but I'm waiting on the
Freescale MDS board.

I haven't read the user manual in great detail, other than to
check out the potential bus performance, but I thought
the main change in the G2 vs e300 core was the cache size.
Did they add new instructions, or change the number-of-cycles
required for existing instructions?

The Freescale document:

   Freescale PowerPCT Architecture Primer, POWRPCARCPRMRM,
   Rev. 0.1, 6/2005

   Has the following on page 12 of the PDF:

   e300 Cores and Platform
   The ongoing presence of the e300 testifies to the longevity
   of both the PowerPC architecture and the microarchitecture.
   The e300 was introduced in 1994 as the MPC603, running at
   100 MHz, and continues to be proliferated more than a decade
   later reaching speeds exceeding 600 MHz. The e300 PowerPC
   core and platform address the low- to mid-range performance
   needs of the market. The e300 core is an enhanced version
   of the popular PowerPC 603e core used in previous-generation
   PowerQUICC II devices that scale from 266 to 667 MHz in
   130 nm process technology. Enhancements include twice as
   much L1 cache as the 603e (32-Kbyte data and instruction
   caches) with integrated parity checking and other
   performance-oriented features. The e300 core is fully
   software-compatible with existing 603e core-based products
   and provides the processing foundation for the company's new
   MPC8349E PowerQUICC IIT Pro communications processor family.

So I guess the question is what are the

  'other performance-oriented features'

this statement is referring to?

The e300 core reference manual comments:

     The e300c1core integrates five execution units: an integer
     unit (IU), a floating-point unit (FPU), a branch processing
     unit (BPU), a load/store unit (LSU), and a system register
     unit (SRU). The ability to execute five instructions in
     parallel and the use of simple instructions with rapid
     execution times yield high efficiency and throughput
     for e300-core-based systems. Most integer instructions
     execute in one clock cycle. On the e300c1 core, the FPU is
     pipelined so a single-precision multiply-add instruction
     can be issued and completed every clock cycle.

So I guess an important optimization would be to keep each
execution unit busy. I haven't looked at an older 603e manual,
do they have fewer units?

Cheers
Dave

Re: GNU and Freescale MPC83xx / e300 core support?

[Kumar Gala]

On Mar 6, 2006, at 11:52 PM, Russell McGuire wrote:

> All,
>
> Our meetings with Freescale were aimed specifically at the differences
> between the MPC8280 and the MPC8360E. The most obvious core  
> difference is
> the Floating Point unit; the MPC8280, 603e or G2LE core had no  
> floating
> point ability at all.

I'm not sure what the FAE is telling you but its wrong.  All current  
PQ2 processors have FP in the 603 core.

Will e300 had an instruction or two, they are very minor things with  
respect to the compiler.  Its possible that the scheduler could be  
tuned for e300 above and beyond what exists for the 603.

> I am not sure if its core support or not, but I know the MPC83xx  
> line up has
> drastically altered the bus architecture inside the chips. There  
> are more
> DMA engines now, and things like the DDR SDRAM bus and 60x / local  
> Bus are
> separated to run in parallel. Previously, in the 8260/8280 they were
> mutually exclusive for bus cycles. Internally the shared bus now  
> operates at
> the DDR frequency, shortly to be DDR2 frequency for later masks. We  
> should
> see a very large performance improvement for memory intensive  
> applications.
> Same applies to the PCI 2.2 bus; it was also given separate pins  
> and DMA
> engines. According to the Freescale FAE the chip can handle  
> simultaneous bus
> cycles on all three busses at once. I do not have enough internal  
> knowledge
> on the compilers to know if this is a specific optimization, but it  
> would
> definitely hinder performance if we couldn't take advantage of it.
>
> Freescale claims their newest revision of Metrowerks is optimized  
> for these
> newer cores, I guess one could get compile with a version of that and
> disassemble it.

I truly doubt the Metrowerks compiler takes into account anything  
beyond the core differences.  As I said earlier, the scheduler in GCC  
could probably be tuned for e300.  Beyond that there is little to be  
done that is specific for the e300.

- kumar

Re: GNU and Freescale MPC83xx / e300 core support?

[Dan Malek]

On Mar 7, 2006, at 12:52 AM, Russell McGuire wrote:

> .....  The most obvious core difference is
> the Floating Point unit; the MPC8280, 603e or G2LE core had no floating
> point ability at all.

I just want to state for archive purposes this simply isn't true.
All of those processors had hardware FPUs.  If you would take
a few seconds and read the product overviews for these parts,
you can make your own informed decision.  The person you
are talking to doesn't seem to have all of the facts in order.


	-- Dan

RE: GNU and Freescale MPC83xx / e300 core support?

[Russell McGuire]

Thanks all...

The author of that comment humbly apologizes for his ineptitude on the FPU.

It would appear both cores have the same number of execution units, i.e. 5
So David, I guess in all this the only real difference seems to be the bus
architecture, raw clock speed, and perhaps a few new instructions. I checked
both manuals this morning and they do differ in some small ways.

* 603e, up to 4 instructions in the pipeline, only 3 being complete per
clock
* e300, up to 5 instructions in the pipeline, still only 3 being completed
or start per clock.
* Add/compare instructions are now executed in the IU unit instead of the
load/store unit. May be the same, but wasn't specific in earlier 603e
manuals.
* One more HID0 bit than G2, ability to interrupt based on cache parity
error
* new icbt instruction, instruction cache initialization

So there is a section inside the 8360E manual that outlines the specific
enhancements. "Features specific to the e300 core not present on the G2
processors follow:" Page  1-5.

So I guess my question is back up, does anyone know if an optimized compiler
would offer any noticeable performance enhancements in regards to these
changes? Other than the obvious instruction being added?

Thanks

-Russ





-----Original Message-----
From: Dan Malek [mailto:dan@embeddedalley.com] 
Sent: Tuesday, March 07, 2006 4:33 AM
To: Russell McGuire
Cc: 'David Hawkins'; linuxppc-embedded@ozlabs.org
Subject: Re: GNU and Freescale MPC83xx / e300 core support?


On Mar 7, 2006, at 12:52 AM, Russell McGuire wrote:

> .....  The most obvious core difference is
> the Floating Point unit; the MPC8280, 603e or G2LE core had no floating
> point ability at all.

I just want to state for archive purposes this simply isn't true.
All of those processors had hardware FPUs.  If you would take
a few seconds and read the product overviews for these parts,
you can make your own informed decision.  The person you
are talking to doesn't seem to have all of the facts in order.


	-- Dan

Re: GNU and Freescale MPC83xx / e300 core support?

[Kumar Gala]

On Mar 7, 2006, at 9:54 AM, Russell McGuire wrote:

> Thanks all...
>
> The author of that comment humbly apologizes for his ineptitude on  
> the FPU.
>
> It would appear both cores have the same number of execution units,  
> i.e. 5
> So David, I guess in all this the only real difference seems to be  
> the bus
> architecture, raw clock speed, and perhaps a few new instructions.  
> I checked
> both manuals this morning and they do differ in some small ways.
>
> * 603e, up to 4 instructions in the pipeline, only 3 being complete  
> per
> clock
> * e300, up to 5 instructions in the pipeline, still only 3 being  
> completed
> or start per clock.
> * Add/compare instructions are now executed in the IU unit instead  
> of the
> load/store unit. May be the same, but wasn't specific in earlier 603e
> manuals.
> * One more HID0 bit than G2, ability to interrupt based on cache  
> parity
> error
> * new icbt instruction, instruction cache initialization
>
> So there is a section inside the 8360E manual that outlines the  
> specific
> enhancements. "Features specific to the e300 core not present on  
> the G2
> processors follow:" Page  1-5.
>
> So I guess my question is back up, does anyone know if an optimized  
> compiler
> would offer any noticeable performance enhancements in regards to  
> these
> changes? Other than the obvious instruction being added?

If you are asking about relative performance between the same  
compiler tuned for a 603 vs e300, the there would most likely be a  
small improvement.

However, a few things to note.  The new icbt instruction is really  
intended for hand written assemble code and its highly unlikely that  
a compiler will ever generate it.  Second, the other improvements  
from the base 603e/G2LE in 8280, like doubling of the L1 caches has a  
significant improvement in performance.

- kumar

Re: GNU and Freescale MPC83xx / e300 core support?

[Kim Phillips]

according to one of our architects, the 81xx, 82xx, 83xx, 52xx, and 51xx (all G2/e300 based parts) all share the same 603 pipeline:

o dispatch 2 instructions, plus 1 branch per cycle,
o up to 5 instructions in the pipeline at any given time, 
o a maximum of 2 instructions are completed per cycle.

the changes are:

o multiple HID0, HID1, HID3 bits for optimizing system,
o icbt
o PLL options

so, the answer is no, modifying the compiler's scheduler won't do anything for you.  

as Kumar says, the caches and adding icbt to your code does improve performance.

Kim

On Tue, 7 Mar 2006 10:03:53 -0600
Kumar Gala <galak@kernel.crashing.org> wrote:

> 
> On Mar 7, 2006, at 9:54 AM, Russell McGuire wrote:
> 
> > Thanks all...
> >
> > The author of that comment humbly apologizes for his ineptitude on  
> > the FPU.
> >
> > It would appear both cores have the same number of execution units,  
> > i.e. 5
> > So David, I guess in all this the only real difference seems to be  
> > the bus
> > architecture, raw clock speed, and perhaps a few new instructions.  
> > I checked
> > both manuals this morning and they do differ in some small ways.
> >
> > * 603e, up to 4 instructions in the pipeline, only 3 being complete  
> > per
> > clock
> > * e300, up to 5 instructions in the pipeline, still only 3 being  
> > completed
> > or start per clock.
> > * Add/compare instructions are now executed in the IU unit instead  
> > of the
> > load/store unit. May be the same, but wasn't specific in earlier 603e
> > manuals.
> > * One more HID0 bit than G2, ability to interrupt based on cache  
> > parity
> > error
> > * new icbt instruction, instruction cache initialization
> >
> > So there is a section inside the 8360E manual that outlines the  
> > specific
> > enhancements. "Features specific to the e300 core not present on  
> > the G2
> > processors follow:" Page  1-5.
> >
> > So I guess my question is back up, does anyone know if an optimized  
> > compiler
> > would offer any noticeable performance enhancements in regards to  
> > these
> > changes? Other than the obvious instruction being added?
> 
> If you are asking about relative performance between the same  
> compiler tuned for a 603 vs e300, the there would most likely be a  
> small improvement.
> 
> However, a few things to note.  The new icbt instruction is really  
> intended for hand written assemble code and its highly unlikely that  
> a compiler will ever generate it.  Second, the other improvements  
> from the base 603e/G2LE in 8280, like doubling of the L1 caches has a  
> significant improvement in performance.
> 
> - kumar
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded


--