S12Z update

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

S12Z update

John Darrington-4
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.


signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: S12Z update

John Darrington-4
On Sat, Jan 13, 2018 at 09:48:09AM +0100, John Darrington wrote:
     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'


I've heard no opinions for either case, so I'll do whatever I find easier to implement
and seems to make sense to me !

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.


signature.asc (188 bytes) Download Attachment