This is the mail archive of the binutils@sourceware.org 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]
Other format: [Raw text]

S12Z update


I'm progressing with this task ...  however,  my original idea was that
the S12Z should be an optional target under the general configuration of
m68hc11.   That is to say, binutils would need to be built using 

 ./configure --target=mc68hc11

and then at run time use a command like:

 as -mm9s12z foo.s

I suppose the reasons for deciding that was that this is how the S12X
has been done.

However, I'm having more and more misgivings about this.  The S12X and S12Z
have quite different instruction sets.  So far as I'm aware, code for one of 
those processors cannot be run on the other.   Having the two (actually five - 
that target already includes m68hc11, m68hc12, m9s12x and m9s12xg) instruction
sets generated by the same binary means that extra run time conditions must
be included, which of course will slow the assembler.  It also introduces the
risk of introducing bugs which might break the other existing targets.

So I'm now thinking that a better option will be to target this as a completely
new configuration option, eg:

 ./configure --target=s12z

Is there any existing policy or precident in binutils for such decisions?

J'



-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.

Attachment: signature.asc
Description: Digital signature


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