Matt Thomas | 2 Feb 22:03 2003

Another PPC cleanup.

If you track source-changes, you'll notice I just submitted a
large change to the powerpc code.

The major effect of this is that on MPC6XX (G3, G4, 60x) systems
the vector pages are no longer used for temporary storage.   So
they can now be checked to make sure nothing is writing in them
(as would be done on a null pointer dereference).

Note that global variable references take two instructions (to
load the two 16-bit halves of the address) and loading from the
cpu_info structure also takes two instructions (since the address
to that structure is always in SPRG0).  But multiple references
will be cheaper since the value of SPRG0 will be cached in a
register.

A lot of the uniprocessor/multiprocessor differences are now gone
and things operate the same for either mode.  Also, much more code
is now common than before.

--

-- 
Matt Thomas               Internet:   matt <at> 3am-software.com
3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt/
Cupertino, CA             Disclaimer: I avow all knowledge of this message

Yoriaki FUJIMORI | 2 Feb 23:14 2003
Picon

Teron CX motherboard

Dear listers,
Some time ago, I read about the Subject matter.
I wonder if somebody has tried this motherboard.

Thanks for your attention.
Yoriaki Fujimori

matthew green | 3 Feb 04:20 2003
Picon

re: Another PPC cleanup.


   The major effect of this is that on MPC6XX (G3, G4, 60x) systems
   the vector pages are no longer used for temporary storage.   So
   they can now be checked to make sure nothing is writing in them
   (as would be done on a null pointer dereference).

thanks matt!

Matt Thomas | 3 Feb 06:21 2003

RFC: Rename PPC_MPC6XX to PPC_OEA

Very soon, I'd to rename to PPC_MPC6XX to PPC_OEA(*) (and anything
mpc6xx* to oea*).  While this may seem pendantic to some, there's
a real reason to do this.

The IBM Power3/Power4 are OEA implementations, but OEA 64bit
implementations.  With a few macros, much of the 6xx assembly
can be reused for the OEA64 processors.

While we could keep the PPC_MPC6XX name, it seems wrong to use
it for the IBM OEA 64bit processors as well.

(*) OEA is acronym for "Operating Environment Architecture" which is
the privileged environment defined in PowerPC "green book".

--

-- 
Matt Thomas               Internet:   matt <at> 3am-software.com
3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt/
Cupertino, CA             Disclaimer: I avow all knowledge of this message

Jason R Thorpe | 3 Feb 07:47 2003

Re: RFC: Rename PPC_MPC6XX to PPC_OEA

On Sun, Feb 02, 2003 at 09:21:18PM -0800, Matt Thomas wrote:

 > Very soon, I'd to rename to PPC_MPC6XX to PPC_OEA(*) (and anything
 > mpc6xx* to oea*).  While this may seem pendantic to some, there's
 > a real reason to do this.

That seems like a fine idea to me.

--

-- 
        -- Jason R. Thorpe <thorpej <at> wasabisystems.com>

webmaster@datazap.net | 4 Feb 03:23 2003
Picon

Re: AmigaOne

On Fri, 31 Jan 2003, Matt Thomas wrote:

> At 09:46 AM 1/31/2003, Perry Metzger wrote:
>
> >"webmaster <at> datazap.net" <webmaster <at> datazap.net> writes:
> > > Does any one know if there are any plains to port NetBSD to
> > > AmigaOne?
> >
> >Get a NetBSD PPC hacker one of the machines and perhaps it will
> >happen. :)
>
> Amen.  I've looked at them and they would be easy to support
> but I concluded I just didn't need another "near normal" PPC
> machine.

I wish that I had one of these to send you, but I haven't even bought one
for myself yet. I was just trying to see if anyone had any plans to port
NetBSD to it.

Thanks,
Al

Matt Thomas | 4 Feb 03:35 2003

Re: AmigaOne

At 06:23 PM 2/3/2003, webmaster <at> datazap.net wrote:
>On Fri, 31 Jan 2003, Matt Thomas wrote:
>
> > At 09:46 AM 1/31/2003, Perry Metzger wrote:
> >
> > >"webmaster <at> datazap.net" <webmaster <at> datazap.net> writes:
> > > > Does any one know if there are any plains to port NetBSD to
> > > > AmigaOne?
> > >
> > >Get a NetBSD PPC hacker one of the machines and perhaps it will
> > >happen. :)
> >
> > Amen.  I've looked at them and they would be easy to support
> > but I concluded I just didn't need another "near normal" PPC
> > machine.
>
>I wish that I had one of these to send you, but I haven't even bought one
>for myself yet. I was just trying to see if anyone had any plans to port
>NetBSD to it.

I'd probably do a port if I had the hardware.  But I have lots of other
stuff I'm porting NetBSD to so ...

--

-- 
Matt Thomas               Internet:   matt <at> 3am-software.com
3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt/
Cupertino, CA             Disclaimer: I avow all knowledge of this message

Dheeraj Pandey | 7 Feb 01:44 2003

Performance Monitoring Capabilities in PowerPC (PMC counters and MMCR ctrl registers)

I intend to get some iCache/dCache stats using the PMC capabilities of
MPC750 (MMCR0/1 and PMCn registers, using mfspr and mtspr instructions).

I went on to add some helper functions to set and get PMC[2,3] counters on
MPC750, until I realized that there are pmc_control() and pmc_get_info()
system calls for the same. There were no man pages for this, and I realized
that these system calls will only function if the kernel is built with
PERFCTRS. In fact, the pmc_xxx() helper functions for powerpc don't seem to
be defined at all-- or at least I can't find it in the source. Allen Briggs
seems to have done this work for Intel XScale, but I am not sure if this
work was ever completed for PowerPC platforms.

Are these system calls (pmc_control and pmc_get_info) baked at all? If they
are, are there any useful examples/docs to refer to? If not, do I just go
ahead on the path of custom code to get/set PMC[2,3]? I am specifically
interested in iCache/dCache misses etc., which seem to be captured in PMC2
and PMC3 respectively.

Dheeraj

Matt Thomas | 7 Feb 01:58 2003

Re: Performance Monitoring Capabilities in PowerPC (PMC counters and MMCR ctrl registers)

At 04:44 PM 2/6/2003, Dheeraj Pandey wrote:
>I intend to get some iCache/dCache stats using the PMC capabilities of
>MPC750 (MMCR0/1 and PMCn registers, using mfspr and mtspr instructions).
>
>I went on to add some helper functions to set and get PMC[2,3] counters on
>MPC750, until I realized that there are pmc_control() and pmc_get_info()
>system calls for the same. There were no man pages for this, and I realized
>that these system calls will only function if the kernel is built with
>PERFCTRS. In fact, the pmc_xxx() helper functions for powerpc don't seem to
>be defined at all-- or at least I can't find it in the source. Allen Briggs
>seems to have done this work for Intel XScale, but I am not sure if this
>work was ever completed for PowerPC platforms.
>
>Are these system calls (pmc_control and pmc_get_info) baked at all? If they
>are, are there any useful examples/docs to refer to? If not, do I just go
>ahead on the path of custom code to get/set PMC[2,3]? I am specifically
>interested in iCache/dCache misses etc., which seem to be captured in PMC2
>and PMC3 respectively.

pmc is used on arm (xscale) and i386.  the pmc stuff has not yet been
defined for powerpc yet.  We really do need it for powerpc and we should
figure which of the PMC counter we should support.

--

-- 
Matt Thomas               Internet:   matt <at> 3am-software.com
3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt/
Cupertino, CA             Disclaimer: I avow all knowledge of this message

Dheeraj Pandey | 7 Feb 02:58 2003

RE: Performance Monitoring Capabilities in PowerPC (PMC counters and MMCR ctrl registers)


> pmc is used on arm (xscale) and i386.  the pmc stuff has not yet been
> defined for powerpc yet.  We really do need it for powerpc 
> and we should figure which of the PMC counter we should support.

I really like Linux's implementation of using /proc filesystem to get/set
PMC. Anyhow, the set of PMC counters to support can always be refined with
time. If we start supporting some of the basic ones, e.g. 

for MPC750:

PMC1:
   6 - # of cycles spent in table search for ITLB accesses
   7 - # of L2 hits

PMC2:
   5 - # of L1 instruction cache misses
   6 - # of ITLB misses
   7 - # of L2 instruction misses

PMC3:
   5 - # of L1 data cache misses
   6 - # of DTLB misses
   7 - # of L2 data misses

PMC4:
   5 - # of L2 castouts
   6 - # of cycles spent in table search for DTLB accesses
   8 - # of mispredicted branches

(Continue reading)


Gmane