This is the mail archive of the crossgcc@cygnus.com mailing list for the crossgcc project.


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

Re: gas 2.8.1 CPU32 bug (Was: as: unrecognized option `-c68020')


First a quick apology/correct - In my previous email I stated that my
patch allowed bd,An,Xn mode, that was a typo! I should have referred to
mode An.

After reading Robin's email, in particular about the tests he
performed on the patched gas I am now confused!

I would be grateful if someone could point out what I missed in the
following piece of logic:-

The comment in include/opcode/m68k.h:-
   *  all					(modes 0-6,7.*)
lead me to believe that

{"tstl",    one(0045200),   one(0177700), "*l", m68020up|cpu32|mcf5200 },

would enable all the 7.* modes for tstl instructions, if the cpu was
one of those listed, not to selectively enable some modes depending on
the cpu32 command line switch.

How does it really work?


Cheers
Mark


Mark S. Phillips        ESN 742 2461
msp@nortel.co.uk        Tel. +44 1279 402461

On Thu, 23 Oct 1997, Robin Kirkham wrote:

> 
> On Wed, 22 Oct 1997, Mark Phillips wrote:
> > Are you sure your patch is completely correct? 
> > 
> > My reading of the Motorola manuals is that, of the 020/030/040
> > addressing modes only (bd,An,Xn) and (bd,PC,Xn) are supported by the CPU32
> > and then only for word and long accesses. Your patch appears to allow all
> > the 020/030/040 modes and any width?!
> 
> I believe it is correct, although it might be right for the wrong reason 8-)
> --I don't fully understand the operand mode hieroglyphics in the opcode table.
> 
> I did try some experiments, however.
> 
> The address mode must subsequently checked against processor type by gas,
> because (with my patch) it correctly rejects the four 020/030/040 modes that
> the CPU32 doesn't handle: ([bd,An,Xn],od), ([bd,An],Xn,od), ([bd,PC,Xn],od)
> and ([bd,PC],Xn,od). It accepts all the modes I think it should.
> 
> The byte restriction you mention applies only to the An mode, i.e. "tst.b %a0"
> is illegal (for all 68k's I think). Again, gas seems to have it right.
> 
> The only wrinkle might be "tst.b #<data>". My 020 manual says this is illegal,
> but gas accepts it for 020 and CPU32. It also executes on the 040 and CPU32
> (I don't have an 020 that still works). So, gas may be right here: I can't
> tell. (Not a very useful instruction, anyway).
> 
> 	Addr Mode		Mode/Register	Processors
> 	Dn			000 n		020 cpu32
> 	An			001 n		020 cpu32 (not tst.b)
> 	(An)			010 n		020 cpu32
> 	(An)+			011 n		020 cpu32
> 	-(An)			100 n		020 cpu32
> 	(d16,An)		101 n		020 cpu32
> 	(d8,An,Xn)		110 n		020 cpu32
> 	(bd,An,Xn)		110 n		020 cpu32
> 	([bd,An,Xn],od)		110 n		020
> 	([bd,An],Xn,od)		110 n		020
> 
> 	(xxx).W			111 000		020 cpu32
> 	(xxx).L			111 001		020 cpu32
> 	#<data>			111 100		020 cpu32 (not tst.b ???)
> 	(d16,PC)		111 010		020 cpu32
> 	(d8,PC,Xn)		111 011		020 cpu32
> 	(bd,PC,Xn)		111 011		020 cpu32
> 	([bd,PC,Xn],od)		111 011		020
> 	([bd,PC],Xn,od)		111 011		020
> 
> 
> > Does anyone know what the offical patch is that made it into the beta
> > binutils?
> 
> It seems to be the same as mine...
> 
> > I used a much more paranoid patch to solve the problem, I JUST allowing
> > the (bd,An,Xn) mode - the (bd,PC,Xn) mode was not causing me a problem.
> 
> Don't you mean An mode? Correct me if I am wrong, but this seems to be what
> you patch adds (and which was the start of all this anyway).

Yep, sorry I made a real bad typo!!!

> 
> 
> Robin Kirkham			CSIRO Manufacturing Science and Technology
> Project Engineer		Locked Bag 9, Preston 3072, Australia
> robin.kirkham@mlb.dmt.csiro.au	Phone: +61 3 9662-7756  Fax: +61 3 9662-7851
> 


Mark S. Phillips        ESN 742 2461
msp@nortel.co.uk        Tel. +44 1279 402461