This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


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

Re: RFC: PowerPC GAS changes



> > That is correct, however if you specify -m603, -m604, -m750, -m403,
> > -m405, -m860 you get exactly the same assembly info.  The biggest
> > problem is we only have 32 bits of space in "flags".  I can fill all 32
> > bits quickly with what is already there and add in CPU types of 603,
> > 604, 620, 750, 7400, 8xx, 4xx, 403, 405, etc..  (you get the point)
> 
> We presently have only 10 bits of 'flags' used.  That leaves 22 bits
> free.
> 
> For instructions that only work on one CPU, you could allocate say 6
> bits and make them a CPU number and require that the CPU number must
> match the specified CPU or be zero.  For shared instructions (like
> dcba or fres), use a flag bit.  There aren't that many categories of
> shared instruction.  If two processors just coincidentally share an
> instruction, you could just duplicate the entry in the opcode table.
> 

Ok.  6-bits (for right now I'm assuming the top 6 bits in flags can be
masked out easily) would allow a max of 63 CPUs before we break. 
Is that enough?  Right now I know of: 401, 403, 405, 5xx??, 601, 603,
604, 620, 630?, 750, 823, 850, 860, 7400, 8240, 8260.  Lets assume 20
current CPUs.  Some of which can be defaulted back down, so that leaves
us
around 15 CPU types.  48 CPUs to go, is that enough room to grow?  What
will the implications be in 5 years if all 48 spots are filled?

Other then that, the 6 bit value is definatly do-able for a single CPU's
instructions.  But what about instructions (again the dcba, fres).  If
we start assigning flag bits that could get messy.  I'm trying to remove
that and make it much easier for someone to add instructions and pick
the
CPU(s) it applies to.

(long examples follow, if you are interested in how messy I think it can
get please read on...)

The PPC 401 defines: dcci, dcread, icci, icbt, icread, mfdcr, mtdcr,
rfci,
wrtee, wrteei.  These can be flagged as "PPCEE" (PPC Embeded
Environment)
instructions.  Now the 403 comes along and adds: tlbre, tlbsx, tlbsx.,
tlbwe
those (and the 401 instructions) can be labeled as "PPCEC" (PPC Embedded
Controller) instructions.  405 Comes along and has a Multiply Accumulate
Unit those can be labeled as 405 specific.  (Thats all "easy"..)

However, we have PPC Extended Mnemonics for the mfspr and mtspr.  We
have
a situation on the 401 that defines some SPRs, the 403 Adds to that list
but ignores a couple, then the 405 comes out and uses most of the 401
and 403 SPRS (including the couple ignored by the 403.)  This is where
the
nasty parts begin.  How many macros are needed just for those cases?
PPC401ONLY, PPC403ONLY, PPC405ONLY, PPC401403, PPC401405, PPC401403405,
etc...

Now start adding in the Extended instructions for the SPRs on the 601,
603,
604, 750, 7400, 8xx.  As you can see it starts to grow exponentially. 
Even
the PowerPC manual specifies 11 "optional" instructions that any PPC can
choose to implement or not.

--Mark

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