68hc11/12/s12x/xgate patch

68hc11/12/s12x/xgate patch

[James Murray]

[-- Attachment #1: Type: text/plain, Size: 639 bytes --]

Attached is a patch for the 68hc11 target of binutils.
(This is my first contribution, so please go easy..)

Included is some old work from Stephane Carrez that never made the
mainstream. The bulk of the patch is my addition of S12X support and
XGATE co-processor support. I've been using and refining this work over
the last ~3 years. Some cleanup may still be required and please point
me in the right direction if needed.

I've ported my work to a CVS checkout from a few hours ago and rebuilt
my application with the same output as I've been seeing recently and
works on my car. (Engine management application.)

regards

James Murray

[-- Attachment #2: s12x.diff.gz --]
[-- Type: application/x-gzip, Size: 45023 bytes --]

Re: 68hc11/12/s12x/xgate patch

[James Murray]

On Sun, 2011-02-27 at 22:24 +0000, James Murray wrote:
> Attached is a patch for the 68hc11 target of binutils.
> (This is my first contribution, so please go easy..)

As per suggestion, I'm posting a 1 week reminder.

Have any moderators had chance to review my patch submission?

regards

James Murray

Re: 68hc11/12/s12x/xgate patch

[Nick Clifton]

[-- Attachment #1: Type: text/plain, Size: 1692 bytes --]

Hi James,

>> Attached is a patch for the 68hc11 target of binutils.
>> (This is my first contribution, so please go easy..)

Thank you for the patch submission, and my apologese for taking so long 
to review it.

First of all, I must point out that we do not appear to have a FSF 
Copyright Assignment on file from you.  This is essential in order for 
us to be able to accept the patch.  I have attached a form you can fill 
out and email to the FSF should you wish to pursue this.

As for the patch itself, it is fine apart from one problem - it 
introduces some new gas testsuite failures to the m68hc11-elf target. 
Specifically:

   GAS REGRESSION: movb 200,x,3,y : Offset out
   GAS REGRESSION: movb 2,x,300,y : Offset out
   GAS REGRESSION: movb 2,x,bar,y bar=300 : Offset
   GAS REGRESSION: movb bar,y,2,x bar=300 : Offset
   GAS REGRESSION: movb 200,pc,3,y : Offset out
   GAS REGRESSION: movb 2,x,300,pc : Offset out
   GAS REGRESSION: insns
   GAS REGRESSION: lbranch
   GAS REGRESSION: all_insns
   GAS REGRESSION: Dwarf2 test on insns.s
   GAS REGRESSION: Dwarf2 test on lbranch.s
   GAS REGRESSION: Motorola Assembly Language Input Standard
   GAS REGRESSION: 68HC12 specific addressing modes (opers12)
   GAS REGRESSION: Dwarf2 test on opers12.s
   GAS REGRESSION: 68HC12 branchs
   GAS REGRESSION: 68HC12 specific instructions (insns12)
   GAS REGRESSION: 68HC12 indexed addressing mode with
   GAS REGRESSION: 68HC12 PC-relative addressing modes (bug-1825)
   GAS REGRESSION: 68HC12 movb movw instructions

Please could you look into these and, once you have a Copyright 
Assignment in place, submit a revised patch that does not introduce any 
regressions.

Cheers
   Nick

[-- Attachment #2: request-assign.future --]
[-- Type: text/plain, Size: 971 bytes --]

Please email the following information to assign@gnu.org, and we
will send you the assignment form for your past and future changes.

Please use your full legal name (in ASCII characters) as the subject
line of the message.
----------------------------------------------------------------------
REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES

[What is the name of the program or package you're contributing to?]


[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]


[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]


[For the copyright registration, what country are you a citizen of?]


[What year were you born?]


[Please write your email address here.]


[Please write your postal address here.]





[Which files have you changed so far, and which new files have you written
so far?]

Re: 68hc11/12/s12x/xgate patch

[James Murray]

On Tue, 2011-03-15 at 08:34 +0000, Nick Clifton wrote:
> Hi James,
> >> Attached is a patch for the 68hc11 target of binutils.

> Thank you for the patch submission, 

Thanks for your comments.

> First of all, I must point out that we do not appear to have a FSF 
> Copyright Assignment on file from you.  This is essential in order for 
> us to be able to accept the patch.  I have attached a form you can fill 
> out and email to the FSF should you wish to pursue this.

I have sent one off, but I will re-send and check I completed my details
correctly.


> As for the patch itself, it is fine apart from one problem - it 
> introduces some new gas testsuite failures to the m68hc11-elf target. 
> Specifically:
> 
>    GAS REGRESSION: movb 200,x,3,y : Offset out

I'll need to check the testsuite is operating correctly as these are
areas I intentionally extended. The S12X CPU supports many more modes of
movb/movw than the more basic 68hc11 and intermediate s12

I'll need to confirm that the testsuite is checking the correct target
i.e. it might now need a 68hc11 flag.

James

Re: 68hc11/12/s12x/xgate patch

[James Murray]

[-- Attachment #1: Type: text/plain, Size: 626 bytes --]

Back in March, James Murray wrote:
> On Tue, 2011-03-15 at 08:34 +0000, Nick Clifton wrote:
> > First of all, I must point out that we do not appear to have a FSF
> > Copyright Assignment on file from you.

Now completed and returned to me.

> > As for the patch itself, it is fine apart from one problem - it
> > introduces some new gas testsuite failures to the m68hc11-elf target.

I believe I resolved those problems and as per recent posts now have
the testsuite "make check" running cleanly on my system.

Find attached updated patch against CVS as of 21:35 GMT 20th Dec 2011.

regards

James Murray


[-- Attachment #2: binutils-20111220-s12x.diff.gz --]
[-- Type: application/x-gzip, Size: 72872 bytes --]

Re: 68hc11/12/s12x/xgate patch

[Fred Cooke]

To the maintainers: I would recommend holding off a little longer on
accepting this into the upstream repository. I head a project that
uses these tools and I believe there are some issues with this patch
that are yet to be shown. There should be more information available
inside the next 24 hours. Hopefully that is not too long to wait.

Thank you in advance for your patience.

Regards,

Fred.

On Tue, Dec 20, 2011 at 11:20 PM, James Murray <jsm@jsm-net.demon.co.uk> wrote:
>
> Back in March, James Murray wrote:
> > On Tue, 2011-03-15 at 08:34 +0000, Nick Clifton wrote:
> > > First of all, I must point out that we do not appear to have a FSF
> > > Copyright Assignment on file from you.
>
> Now completed and returned to me.
>
> > > As for the patch itself, it is fine apart from one problem - it
> > > introduces some new gas testsuite failures to the m68hc11-elf target.
>
> I believe I resolved those problems and as per recent posts now have
> the testsuite "make check" running cleanly on my system.
>
> Find attached updated patch against CVS as of 21:35 GMT 20th Dec 2011.
>
> regards
>
> James Murray
>

Re: 68hc11/12/s12x/xgate patch

[James Murray]

On Tue, 20 Dec 2011 23:29:37 +0100 Fred Cooke wrote:
> To the maintainers: I would recommend holding off a little longer on
> accepting this into the upstream repository. I head a project that
> uses these tools and I believe there are some issues with this patch
> that are yet to be shown.

Could you be more specific? What leads you to believe there are issues
with this patch?

It is a cleanup of the patch posted here in March and the same as the
tools on http://www.msextra.com/tools that have been in use for a few
years now.

regards

James

Re: 68hc11/12/s12x/xgate patch

[Fred Cooke]

> On Tue, 20 Dec 2011 23:29:37 +0100 Fred Cooke wrote:
> > To the maintainers: I would recommend holding off a little longer on
> > accepting this into the upstream repository. I head a project that
> > uses these tools and I believe there are some issues with this patch
> > that are yet to be shown.
>
> Could you be more specific? What leads you to believe there are issues
> with this patch?

You missed a bit, James!

> There should be more information available inside the next 24 hours. Hopefully that is not too long to wait.
>
> Thank you in advance for your patience.

I take it you're not feeling particularly patient, nevertheless, good
things take time, and rushed things are rarely good enough, as you'll
soon see. Feel free to skip the two paragraphs which amount to a
political history lesson and go right for the comparison link.

Way back in 2008 James released his initial work on an XGATE Binutils
patch and published it on the internet. At the time I was hard at work
on my project which also uses an XGATE core and, naturally, I was
quite interested in this work. I grabbed a copy of that work at the
time, however I can't find it right now. Shortly afterward I noticed
that all of the files had been pulled from circulation and requested
that James email me his work so that we could collaborate in testing
and development with him. I was not the only one to request these
files during that period, however nobody had their request fulfilled.
Although he was perfectly within his rights to do what he did, it
never struck me as a particularly moral thing to do with a
foundational GNU package. Late in 2010 James re-released his work, and
because of his earlier behaviour I decided to cache it here:

http://tools.diyefi.org/james/s12x-tools-source-20101029.zip

In the mean time, and in the absence of James sharing his changes with
other members of the community, Sean Keys started work on a parallel
effort to produce a working tool-chain for the S12X platform including
an XGATE assembler and linker. Sean assures me that he did extensive
manual checking and comparative checking to ensure that his work was
of the best possible quality. He says that he used CodeWarrior as a
bench mark as that is the suite that the manufacturer of the chipset
provides - they should know! When we saw that James was trying to
upstream his work, we decided, for the benefit of all future users,
and because it was the right thing to do, to give it a once over and
make sure that it functioned as advertised. Sean has assembled some
results in a spreadsheet which I've published on our tools page, which
has been up, since October 16, 2010, for more than a year.

http://tools.diyefi.org/XGATE-AssemblerComparison.html

I'll have to leave it to Sean to explain what he found in his testing
as I have some other tasks to complete today, however I hope that the
maintainers of Binutils will observe the missing instructions which
render James' tools unable to build other existing code bases for this
chipset. From cross examining Sean and from looking into some of this
behaviour myself, I believe that this patch is not ready for prime
time. Sean should be available to follow up on this email in an hour
or two or three. Again, I hope your patience extends that far, James
excluded, his clearly does not.

Regards,

Fred.

On Wed, Dec 21, 2011 at 12:22 AM, James Murray <jsm@jsm-net.demon.co.uk> wrote:
>
> On Tue, 20 Dec 2011 23:29:37 +0100 Fred Cooke wrote:
> > To the maintainers: I would recommend holding off a little longer on
> > accepting this into the upstream repository. I head a project that
> > uses these tools and I believe there are some issues with this patch
> > that are yet to be shown.
>
> Could you be more specific? What leads you to believe there are issues
> with this patch?
>
> It is a cleanup of the patch posted here in March and the same as the
> tools on http://www.msextra.com/tools that have been in use for a few
> years now.
>
> regards
>
> James
>

Re: 68hc11/12/s12x/xgate patch

[Sean Keys]

To follow up on Fred's email, some of the results in the spreadsheet 
linked were not accurate. The reason is that when I tried to assemble my 
test code I got "Relocation 14 is not supported by object file format". 
  This error was caused by having a typo in the label identifier. The 
error message is non-intuitive and made it difficult to notice the 
mistake, especially considering the volume of other errors. I apologize 
for the mistake, and misleading information given, however these errors 
still seem to stand:

xgate.s: Assembler messages:
xgate.s:329: Error: Opcode `bhs' is not recognized.
xgate.s:333: Error: Opcode `blo' is not recognized.
xgate.s:346: Error: Opcode `com' is not recognized.
xgate.s:347: Error: Opcode `cpc' is not recognized.
xgate.s:348: Error: Opcode `cpc' is not recognized.
xgate.s:362: Error: Garbage at end of instruction: `ErrorHandler'.   In 
my opinion, 'ldw' should be added as an alias to 'ld' as per the CPU 
reference manual.
xgate.s:370: Error: Opcode `mov' is not recognized.
xgate.s:371: Error: Opcode `neg' is not recognized.
xgate.s:400: Error: Opcode `tst' is not recognized.

I have some technical questions to ask on this subject too, and will 
send those at a later date.

Regards,
Sean

On 12/21/2011 03:29 PM, Fred Cooke wrote:
>> On Tue, 20 Dec 2011 23:29:37 +0100 Fred Cooke wrote:
>>> To the maintainers: I would recommend holding off a little longer on
>>> accepting this into the upstream repository. I head a project that
>>> uses these tools and I believe there are some issues with this patch
>>> that are yet to be shown.
>> Could you be more specific? What leads you to believe there are issues
>> with this patch?
> You missed a bit, James!
>
>> There should be more information available inside the next 24 hours. Hopefully that is not too long to wait.
>>
>> Thank you in advance for your patience.
> I take it you're not feeling particularly patient, nevertheless, good
> things take time, and rushed things are rarely good enough, as you'll
> soon see. Feel free to skip the two paragraphs which amount to a
> political history lesson and go right for the comparison link.
>
> Way back in 2008 James released his initial work on an XGATE Binutils
> patch and published it on the internet. At the time I was hard at work
> on my project which also uses an XGATE core and, naturally, I was
> quite interested in this work. I grabbed a copy of that work at the
> time, however I can't find it right now. Shortly afterward I noticed
> that all of the files had been pulled from circulation and requested
> that James email me his work so that we could collaborate in testing
> and development with him. I was not the only one to request these
> files during that period, however nobody had their request fulfilled.
> Although he was perfectly within his rights to do what he did, it
> never struck me as a particularly moral thing to do with a
> foundational GNU package. Late in 2010 James re-released his work, and
> because of his earlier behaviour I decided to cache it here:
>
> http://tools.diyefi.org/james/s12x-tools-source-20101029.zip
>
> In the mean time, and in the absence of James sharing his changes with
> other members of the community, Sean Keys started work on a parallel
> effort to produce a working tool-chain for the S12X platform including
> an XGATE assembler and linker. Sean assures me that he did extensive
> manual checking and comparative checking to ensure that his work was
> of the best possible quality. He says that he used CodeWarrior as a
> bench mark as that is the suite that the manufacturer of the chipset
> provides - they should know! When we saw that James was trying to
> upstream his work, we decided, for the benefit of all future users,
> and because it was the right thing to do, to give it a once over and
> make sure that it functioned as advertised. Sean has assembled some
> results in a spreadsheet which I've published on our tools page, which
> has been up, since October 16, 2010, for more than a year.
>
> http://tools.diyefi.org/XGATE-AssemblerComparison.html
>
> I'll have to leave it to Sean to explain what he found in his testing
> as I have some other tasks to complete today, however I hope that the
> maintainers of Binutils will observe the missing instructions which
> render James' tools unable to build other existing code bases for this
> chipset. From cross examining Sean and from looking into some of this
> behaviour myself, I believe that this patch is not ready for prime
> time. Sean should be available to follow up on this email in an hour
> or two or three. Again, I hope your patience extends that far, James
> excluded, his clearly does not.
>
> Regards,
>
> Fred.
>
> On Wed, Dec 21, 2011 at 12:22 AM, James Murray<jsm@jsm-net.demon.co.uk>  wrote:
>> On Tue, 20 Dec 2011 23:29:37 +0100 Fred Cooke wrote:
>>> To the maintainers: I would recommend holding off a little longer on
>>> accepting this into the upstream repository. I head a project that
>>> uses these tools and I believe there are some issues with this patch
>>> that are yet to be shown.
>> Could you be more specific? What leads you to believe there are issues
>> with this patch?
>>
>> It is a cleanup of the patch posted here in March and the same as the
>> tools on http://www.msextra.com/tools that have been in use for a few
>> years now.
>>
>> regards
>>
>> James
>>

Re: 68hc11/12/s12x/xgate patch

[James Murray]

Sean,
Thanks for reviewing my submission. Good to have someone else who
is familar with the XGATE reviewing it. It does indeed appear that I
have omitted some of the alias instructions (com, cpc, ldw, mov, neg,
tst) and will add them. (In my application code I've used the base
opcodes these alias to.)

I could do with seeing your source code for bhs and blo as they work for
me. I'll contact you offlist to continue the discussion.

label1:
.....

    bhs label1
    blo label1

003fc028 <label1>:
  3fc034:	21 f9       	bcc 0x3fc028 <label1>
  3fc036:	23 f8       	bcs 0x3fc028 <label1>

The datasheet says:
BHS (Same as BCC)
BLO (Same as BCS)

regards

James

Re: 68hc11/12/s12x/xgate patch

[James Murray]

[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]

Find attached my latest revision of a patch to the m68hc11 port 

-include somes work from Stephane Carrez that never made it

-Adds support for the S12X derivative of the HC12/S12 family
(new opcodes added, extended modes, testsuites)

-Adds support for the built-in XGATE co-processor (only exists paired
with S12X, not in isolation.)
(gas, bfd, ld, opcodes, testsuite)

-Fix up hc11/12 far call trampoline generation (broken in 2006)

-Change objdump output to use hex numbering with 0x prefixes in a more
common manner. (Was a confusing mix of hex and decimal with and without
base prefixes before.)

-Adjust hc11/12 testsuites to reflect that changed format and other
binutils changes since 2005.

-Enable testsuites for main m68hc11 target. (Many were enabled for m6811
instead for unknown reasons.)

The core of this work has been in production use (against 2.18) for a
number of years. Thanks to Sean Keys for giving me feedback on the XGATE
assembler over the last few weeks. 

regards

James Murray

[-- Attachment #2: binutils-s12x-20120105.diff.bz2 --]
[-- Type: application/x-bzip, Size: 65384 bytes --]

Re: 68hc11/12/s12x/xgate patch

[Fred Cooke]

Given that a review of the patch passes code quality measures I would
support most of it making it in, however I absolutely do not support
the XGATE assembler hack making it in. There are multiple technical
reasons for this, as being discussed in the other email thread,
however there is an additional reason, principals. Sean Keys, as
mentioned by James in his submission email, has written a clean sheet
gas implementation for the XGATE that does not compromise the existing
HCS12 assembler by stretching it in directions that don't make sense.
You might wonder why two such gas implementations exist when both
parties are clearly aware of each others existence, a fair question.
The answer is simple: At a time when Sean and I were looking to write
XGATE code in our project, and James had begun work on his patches,
he, in a failed attempt to stifle competition with his competing
commercial project, refused to share this work, as contributed to by
hundreds of other members of the public. Although it is legal to do so
under the GPL, it, in my opinion, certainly isn't moral to do so. Sean
spent a lot of time working on these tools due to James not sharing
his free software in a free way, and it would break my heart, if not
his, to see that work go to waste and James' inferior work go in when
James could have collaborated in an open way from the start. What this
boils down to is that one of these two assemblers is going to be
rendered unused and for the above reasons, along with a slew of
technical reasons, I believe that James' XGATE assembler should not
make it upstream. I've written this as Sean is a very nice guy and at
times too gentle and I'll be damned if I'm going to see his work go to
waste while James' stuff gets used. I apologise for the political
content in this email, however if I'd not sent it, I'd be a poor
friend to Sean and would regret it forever. Someone needs to stick
their neck out and stand up for what's right, it looks like it's my
turn today. In closing, I'd like to thank James for his fixes to other
aspects of the tools, as I, at the least, appreciate that work,
despite his questionable behaviour in the past. Thank you for reading.

Regards,

Fred.

On Thu, Jan 5, 2012 at 11:02 PM, James Murray <jsm@jsm-net.demon.co.uk> wrote:
>
> Find attached my latest revision of a patch to the m68hc11 port
>
> -include somes work from Stephane Carrez that never made it
>
> -Adds support for the S12X derivative of the HC12/S12 family
> (new opcodes added, extended modes, testsuites)
>
> -Adds support for the built-in XGATE co-processor (only exists paired
> with S12X, not in isolation.)
> (gas, bfd, ld, opcodes, testsuite)
>
> -Fix up hc11/12 far call trampoline generation (broken in 2006)
>
> -Change objdump output to use hex numbering with 0x prefixes in a more
> common manner. (Was a confusing mix of hex and decimal with and without
> base prefixes before.)
>
> -Adjust hc11/12 testsuites to reflect that changed format and other
> binutils changes since 2005.
>
> -Enable testsuites for main m68hc11 target. (Many were enabled for m6811
> instead for unknown reasons.)
>
> The core of this work has been in production use (against 2.18) for a
> number of years. Thanks to Sean Keys for giving me feedback on the XGATE
> assembler over the last few weeks.
>
> regards
>
> James Murray

Re: 68hc11/12/s12x/xgate patch

[nick clifton]

Hi James,

> Find attached my latest revision of a patch to the m68hc11 port

Thank you for submitting this.  Here are some observations and requests 
for improvements on the patch:

*) Are you offering to act as a maintainer for the S12X target ?

*) You have included a patch to the top level configure file, but not 
the top level configure.ac file (from which the configure file is 
generated).

*) You have included a patch to the top level config.sub file.  Are you 
aware that this patch needs to be submitted to a different project ? 
(config-patches@gnu.org)

*) You have included patches to various ChangeLogs.  Common practice is 
just to include changelog entries as plain text, since they almost never 
apply cleanly as patches.

*) You have added new options to the m68hc11 GAS port, but not added 
documentation for these new options to the gas/doc/c-m68hc11.texi file.

*) You have added support for a new processor, but not mentioned it in 
either gas/NEWS or ld/NEWS.

*) There are some formatting problems.  Ideally we like code that 
follows the GNU Coding Standard: http://www.gnu.org/prep/standards/

Problems such as lines that end with opening curly braces:

    if (r_type != R_M68HC11_NONE) {

Comments that are not treated as sentences:

  /* the -2 here is due to the way XGATE PCREL9, PCREL10 work */

Lines that are excessively long and could be broken up:

   if (move_insn && !(val >= -16 && val <= 15) && ((!(mode & 
M6812_OP_IDX) && !(mode & M6812_OP_D_IDX_2)) || !(current_architecture & 
cpu9s12x)))

Function calls without a space between the function name and the opening 
parentheses.

   as_bad("Invalid register\n");

*) There appears to be some kind of problem with assembling or 
disassembling NOP insns for the xgate target.  I tried this:

   % cat fred.s
         .text
   fred:
         nop

   % as -mm9s12xg fred.s -o fred.o

   % objdump -d fred.o

   fred.o:     file format elf32-m68hc12

   Disassembly of section .text:

   00000000 <fred>:
      0:   01              mem
           ...

Assembling with -mm9s12x gives a disassembly of "nop" as expected...


Other than that though, this patch looks fine.  If you could address the 
issues raised above and resubmit the patch I will be happy to review it 
again.

Cheers
   Nick

Re: 68hc11/12/s12x/xgate patch

[James Murray]

On Tue, 2012-01-10 at 14:41 +0000, nick clifton wrote:
Hi James,
> 
> > Find attached my latest revision of a patch to the m68hc11 port
> 
> Thank you for submitting this.  Here are some observations and
requests 
> for improvements on the patch:
> 
> 
*) Are you offering to act as a maintainer for the S12X target ?
> 

I presume this means performing regular builds of the m68hc11 target as
CVS code progresses and ensuring it builds cleanly before each release?

I would be prepared to do that to the best of my ability.

I have some binutils knowledge, as demonstrated by the ability to add
this new code, but I am far from "expert" level.


*) You have included a patch to the top level configure file, but not 
> the top level configure.ac file (from which the configure file is 
> generated).
> 
> *) You have included a patch to the top level config.sub file.  Are
you 
> aware that this patch needs to be submitted to a different project ? 
> (config-patches@gnu.org)

I'll double check both of these to see if I really need to change them.
I posted a related question a week or so back - the m68hc11 port allows
itself to be built under a number of names, but I' unsure why it needs
to. The name does change the default runtime build target, but that can
be overridden on the command line in any case.

The port can be built as:
m6811
m68hc11
m6812
m68hc12
m9s12x  (I added this)

The many options here has caused a problem because most of the testcases
were set to only run when built as m6811. Prior to the last release,
Tristan built the port and ran the tests as m68hc11 - the tests passed
because most/all of the them were in fact ignored. Had the tests run, it
would have exposed a number of long standing bugs. 

A week or so back I sent a mail to the previous maintainer, Stephane
Carrez to see if he recalled why, but no reply as of yet. I also posted
on the yahoo group for gnu hc11/12 but no replies there either.


*) You have included patches to various ChangeLogs.  Common practice is 
> just to include changelog entries as plain text, since they almost
never 
> apply cleanly as patches.
> *) You have added new options to the m68hc11 GAS port, but not added 
> documentation for these new options to the gas/doc/c-m68hc11.texi
file.
> 
> *) You have added support for a new processor, but not mentioned it
in 
> either gas/NEWS or ld/NEWS.

OK, will do. I'll take a look at other submissions as examples.

*) There are some formatting problems.  Ideally we like code that 
> follows the GNU Coding Standard:
 
OK, will do.

*) There appears to be some kind of problem with assembling or 
> disassembling NOP insns for the xgate target.  I tried this:
> 
>    % cat fred.s
>          .text
>    fred:
>          nop
> 
>    % as -mm9s12xg fred.s -o fred.o
> 
>    % objdump -d fred.o
> 
>    fred.o:     file format elf32-m68hc12
> 
>    Disassembly of section .text:
> 
>    00000000 <fred>:
>       0:   01              mem
>            ...
> 
> Assembling with -mm9s12x gives a disassembly of "nop" as expected...
> 

Objdump requires a target option because the ASM is slightly different
between hc11,hc12,9s12x and totally different for 9s12xg (XGATE)

[jsm@jsm2 tmp]$ m9s12x-elf-objdump -mm9s12xg -d fred.o

fred.o:     file format elf32-m9s12xg

Disassembly of section .text:

00000000 <fred>:
   0:	01 00       	nop
[jsm@jsm2 tmp]$ 

Hopefully the new testcases I added demonstrate this too.

I'll see if I can get a revised patch back later this week.

regards

James Murray

Re: 68hc11/12/s12x/xgate patch - style question

[James Murray]

On Tue, 2012-01-10 at 15:45 +0000, James Murray wrote:
> On Tue, 2012-01-10 at 14:41 +0000, nick clifton wrote:
> *) There are some formatting problems.  Ideally we like code that 
> > follows the GNU Coding Standard:
>  

I've read through the document and the main issues as-is are the ones
Nick already highlighted (brace style and space after function name.)

The document mentions that "indent" can apply the desired formatting.
It would be straightforward enough for me to do that, but then the patch
would also include any formatting changes to the existing code which
could obscure that functional changes.

So what do the maintainers prefer? Should the patch be just what I've
changed or should I use indent and reformat the whole of hc11 files I've
touched.

regards

James Murray

Re: 68hc11/12/s12x/xgate patch - style question

[Fred Cooke]

How about doing a diff and cleaning up the parts that you wrote and
leaving the rest alone such that your patch is clean? It's more work,
but certainly the right thing to do.

Another question, one mammoth patch is very similar to one mammoth
commit which is, at least amongst developers who I've worked with and
know, frowned upon. Would it be possible to split up your single patch
into appropriate sub patches that do specific things at the same time
that you're fixing the formatting? Even though my opinion doesn't
matter, I'd feel more comfortable with more manageable change sets and
more comprehensible and coherent single-purpose diffs.

Regards,

Fred.

On Thu, Jan 12, 2012 at 8:39 PM, James Murray <jsm@jsm-net.demon.co.uk> wrote:
>
> On Tue, 2012-01-10 at 15:45 +0000, James Murray wrote:
> > On Tue, 2012-01-10 at 14:41 +0000, nick clifton wrote:
> > *) There are some formatting problems.  Ideally we like code that
> > > follows the GNU Coding Standard:
> >
>
> I've read through the document and the main issues as-is are the ones
> Nick already highlighted (brace style and space after function name.)
>
> The document mentions that "indent" can apply the desired formatting.
> It would be straightforward enough for me to do that, but then the patch
> would also include any formatting changes to the existing code which
> could obscure that functional changes.
>
> So what do the maintainers prefer? Should the patch be just what I've
> changed or should I use indent and reformat the whole of hc11 files I've
> touched.
>
> regards
>
> James Murray

Re: 68hc11/12/s12x/xgate patch

[James Murray]

Status update.

On Tue, 2012-01-10 at 14:41 +0000, nick clifton wrote:
> Hi James,

> *) You have included a patch to the top level configure file, but not 
> the top level configure.ac file (from which the configure file is 
> generated).

I've removed my changes and used the existing build targets.

> *) You have included a patch to the top level config.sub file.  Are you 
> aware that this patch needs to be submitted to a different project ? 
> (config-patches@gnu.org)

I've removed my changes and used the existing build targets.

> *) You have included patches to various ChangeLogs.  Common practice is 
> just to include changelog entries as plain text, since they almost never 
> apply cleanly as patches.

Ready to submit as plain text.

> *) You have added new options to the m68hc11 GAS port, but not added 
> documentation for these new options to the gas/doc/c-m68hc11.texi file.

OK, added.

> *) You have added support for a new processor, but not mentioned it in 
> either gas/NEWS or ld/NEWS.

OK, added.

> *) There are some formatting problems.  Ideally we like code that 
> follows the GNU Coding Standard: http://www.gnu.org/prep/standards/

Understood and hopefully now addressed.

I intend to spend some more time reviewing my patch and will re-submit
once I have completed that.

regards

James Murray

Re: 68hc11/12/s12x/xgate patch

[James Murray]

[-- Attachment #1: Type: text/plain, Size: 2679 bytes --]

I believe the attached patch remedies the concerns that Nick raised on
my previous submission.

Plain text NEWS and ChangeLog entries:

bfd/ChangeLog:
2012-03-12  James Murray <jsm@jsm-net.demon.co.uk>

    * Add S12X and XGATE co-processor support to m68hc11 target
    (during period 2008-01 -> 2012-03)
    Allows S12X and XGATE code to be linked together.
    * Option to offset S12 addresses into XGATE memory space.
    * Fix carry bug in IMM16 (IMM8 low/high) relocate.

gas/ChangeLog:
2012-03-12  James Murray <jsm@jsm-net.demon.co.uk>

    * Add S12X and XGATE co-processor support to m68hc11 target
    (during period 2008-01 -> 2012-03)
    Most S12X extensions supported (new opcodes, extended movb/movw
    modes) except EXG,SEX,TFR shaded areas.
    * Option to offset S12 addresses into XGATE memory space.
    * Tweak target flags to match other tools. (i.e. -m m68hc11)
    * Other historical m68hc11/12 changes from Stephane Carrez.

gas/testsuite/ChangeLog
2012-03-12  James Murray <jsm@jsm-net.demon.co.uk>

    * gas/m68hc11/insns9s12x.s: New
    * gas/m68hc11/insns9s12x.d: New
    * gas/m68hc11/hexprefix.s: New
    * gas/m68hc11/hexprefix.d: New
    * gas/m68hc11/9s12x-exg-sex-tfr.s: New
    * gas/m68hc11/9s12x-exg-sex-tfr.d: New
    * gas/m68hc11/insns9s12xg.s: New
    * gas/m68hc11/insns9s12xg.d: New
    * gas/m68hc11/9s12x-mov.s: New
    * gas/m68hc11/9s12x-mov.d: New
    * gas/m68hc11/m68hc11.exp: Updated
    * gas/m68hc11/*.d: Brought in line with changed objdump output.
    * gas/all/gas.exp: XFAIL all hc11/12 targets for redef2,3
    * gas/elf/elf.exp: XFAIL all hc11/12 targets for redef

gas/NEWS
* Update m68hc11 port. Add support for S12X and XGATE processors

ld/testsuite/ChangeLog
2012-03-12  James Murray <jsm@jsm-net.demon.co.uk>

    * ld-m68hc11/xgate-link.s: New
    * ld-m68hc11/xgate-link.d: New
    * ld-m68hc11/xgate-offset.s: New
    * ld-m68hc11/xgate-offset.d: New
    * ld-m68hc11/xgate1.s: New
    * ld-m68hc11/xgate1.d: New
    * ld-m68hc11/xgate2.s: New
    * ld-m68hc11/m68hc11.exp: Updated
    * ld-m68hc11/*.d: Brought in line with changed objdump output
    * ld-gc/gc.exp: Update CFLAGS for m68hc11

ld/NEWS
* Update m68hc11 port. Add support for S12X and XGATE processors.

opcodes/ChangeLog
2012-03-12  James Murray <jsm@jsm-net.demon.co.uk>

    * Add S12X and XGATE co-processor support to m68hc11 target
     (during period 2008-01 -> 2012-03)
    * Make objdump output more consistent, use hex instead of decimal
    and use 0x prefix for hex
    * Other historical m68hc11/12 changes from Stephane Carrez.

regards

James Murray 

[-- Attachment #2: m68hc11-s12x-xgate-20120312.diff.gz --]
[-- Type: application/x-gzip, Size: 72430 bytes --]

Re: 68hc11/12/s12x/xgate patch

[Fred Cooke]

James,

Two things, for now:

1) Am I correct in saying that this is still one monolithic patch that
makes multiple changes to the port?

2) Am I correct in saying that this is still comprised mostly of a
two-architectures-in-one-port code change?

Regards,

Fred.

On Mon, Mar 12, 2012 at 4:06 PM, James Murray <jsm@jsm-net.demon.co.uk> wrote:
>
> I believe the attached patch remedies the concerns that Nick raised on
> my previous submission.
>
> Plain text NEWS and ChangeLog entries:
>
> bfd/ChangeLog:
> 2012-03-12  James Murray <jsm@jsm-net.demon.co.uk>
>
>    * Add S12X and XGATE co-processor support to m68hc11 target
>    (during period 2008-01 -> 2012-03)
>    Allows S12X and XGATE code to be linked together.
>    * Option to offset S12 addresses into XGATE memory space.
>    * Fix carry bug in IMM16 (IMM8 low/high) relocate.
>
> gas/ChangeLog:
> 2012-03-12  James Murray <jsm@jsm-net.demon.co.uk>
>
>    * Add S12X and XGATE co-processor support to m68hc11 target
>    (during period 2008-01 -> 2012-03)
>    Most S12X extensions supported (new opcodes, extended movb/movw
>    modes) except EXG,SEX,TFR shaded areas.
>    * Option to offset S12 addresses into XGATE memory space.
>    * Tweak target flags to match other tools. (i.e. -m m68hc11)
>    * Other historical m68hc11/12 changes from Stephane Carrez.
>
> gas/testsuite/ChangeLog
> 2012-03-12  James Murray <jsm@jsm-net.demon.co.uk>
>
>    * gas/m68hc11/insns9s12x.s: New
>    * gas/m68hc11/insns9s12x.d: New
>    * gas/m68hc11/hexprefix.s: New
>    * gas/m68hc11/hexprefix.d: New
>    * gas/m68hc11/9s12x-exg-sex-tfr.s: New
>    * gas/m68hc11/9s12x-exg-sex-tfr.d: New
>    * gas/m68hc11/insns9s12xg.s: New
>    * gas/m68hc11/insns9s12xg.d: New
>    * gas/m68hc11/9s12x-mov.s: New
>    * gas/m68hc11/9s12x-mov.d: New
>    * gas/m68hc11/m68hc11.exp: Updated
>    * gas/m68hc11/*.d: Brought in line with changed objdump output.
>    * gas/all/gas.exp: XFAIL all hc11/12 targets for redef2,3
>    * gas/elf/elf.exp: XFAIL all hc11/12 targets for redef
>
> gas/NEWS
> * Update m68hc11 port. Add support for S12X and XGATE processors
>
> ld/testsuite/ChangeLog
> 2012-03-12  James Murray <jsm@jsm-net.demon.co.uk>
>
>    * ld-m68hc11/xgate-link.s: New
>    * ld-m68hc11/xgate-link.d: New
>    * ld-m68hc11/xgate-offset.s: New
>    * ld-m68hc11/xgate-offset.d: New
>    * ld-m68hc11/xgate1.s: New
>    * ld-m68hc11/xgate1.d: New
>    * ld-m68hc11/xgate2.s: New
>    * ld-m68hc11/m68hc11.exp: Updated
>    * ld-m68hc11/*.d: Brought in line with changed objdump output
>    * ld-gc/gc.exp: Update CFLAGS for m68hc11
>
> ld/NEWS
> * Update m68hc11 port. Add support for S12X and XGATE processors.
>
> opcodes/ChangeLog
> 2012-03-12  James Murray <jsm@jsm-net.demon.co.uk>
>
>    * Add S12X and XGATE co-processor support to m68hc11 target
>     (during period 2008-01 -> 2012-03)
>    * Make objdump output more consistent, use hex instead of decimal
>    and use 0x prefix for hex
>    * Other historical m68hc11/12 changes from Stephane Carrez.
>
> regards
>
> James Murray

Re: 68hc11/12/s12x/xgate patch

[James Murray]

On Mon, 2012-03-12 at 16:26 +0100, Fred Cooke wrote:
> Two things, for now:
> 
> 1) Am I correct in saying that this is still one monolithic patch that
> makes multiple changes to the port?

Yes it is. Go ahead and take a look.

> 2) Am I correct in saying that this is still comprised mostly of a
> two-architectures-in-one-port code change?
> 

Most of the patch is actually testsuite changes, due in part to revised
objdump output but also bringing m68hc11 up to date so that "make check"
works correctly. There are additional testcases for the newly added S12X
and XGATE functions.

Between the lines, it looks like you are referring to your earlier
binutils question "Supporting more than one CPU with the same gas
port." 

There are surely pros and cons to either method.

With the approach I took, only a single toolchain is required and there
is one linker. There are no devices currently that contain XGATE and any
other architecture other than hcs12 in production, nor are there any
currently mooted developments that the public are aware of.  

With the approach that you appear to be advocating, two sets of tools
need to be built and installed. However, the XGATE target (as presented
by Sean) is not self-sufficient and relies on changes to the linker in
the m68hc11 target to support linking symbols within XGATE. Overall that
seems to complicate matters without offering any real advantage.

regards

James Murray

Re: 68hc11/12/s12x/xgate patch

[Fred Cooke]

Hi James,

> Yes it is. Go ahead and take a look.

If it's anything like your MS2E work, I'd rather not as I value my eyesight.

    if((flash4.EgoOption == 2) || (flash4.EgoOption == 4))  {
        if (flash4.ego2port < 0x7) {
            if ( ((adctest & 0x80) & (flash4.ego2port == 7))
                    || ((adctest & 0x40) & (flash4.ego2port == 6)) ){
                conf_err = 2;
            } else {
                if (flash4.ego2port == 6) {
                    adctest |= 0x40;
                } else if (flash4.ego2port == 7) {
                    adctest |= 0x80;
                }

Nevertheless, my objection to the monolithic patch is that it is
multipurpose. Even if your XGATE approach was satisfactory, I'd much
prefer to see it as a separate piece of work with a clear lineage and
history. If I had my way, which I may, or may not, I'd see your XGATE
stuff as a single patch, and each of your S12 units of work as a
separate patch, each. Time will tell if that happens or not, however
you'll likely need to split the XGATE and S12 stuff apart anyway.

> Between the lines, it looks like you are referring to your earlier
> binutils question "Supporting more than one CPU with the same gas
> port."

I don' t believe that I have ever asked such a question; the answer
is, and always has been, clear to me.

> With the approach that you appear to be advocating, two sets of tools
> need to be built and installed. However, the XGATE target (as presented
> by Sean) is not self-sufficient and relies on changes to the linker in
> the m68hc11 target to support linking symbols within XGATE. Overall that

The XGATE itself is not self sufficient, James. As someone who codes
in XGATE ASM I would expect you to know that. It's necessary to set up
the operating parameters, copy the XGATE code to RAM for optimum
performance, and enable the, then standalone, XGATE processor. Due to
this fact it only makes sense to have a single linker code base to
combine object code for each core into one loadable image. They are
two separate cores, though, in spite of them residing in the same MCUs
together.

> seems to complicate matters without offering any real advantage.

The advantage certainly is real, James, I assure you. Binutils is a
tool that underpins basically everything in computing and has done for
years. I imagine that the core binutils developers have a significant
amount of pride in their baby, rightfully so. What you've done is, at
least in part, dirty and an ugly approach. When confronted with this,
not even you seem to defend it. What defies my belief is that you
continue to push it despite at least three, or was it four, prominent
list members and direct committers advising that it was a poor
approach. The clear and readily obvious advantage, therefore, is one
of a higher quality code base. This is advantage that will last
throughout the entire life of the port, easing maintenance, and
reducing the likelihood of bugs in a foundational tool.

There was nothing between the lines; I hope that it's more clear now,
if there was any doubt before.

Regards,

Fred.

Re: 68hc11/12/s12x/xgate patch

[James Murray]

Ping.

Just wondered if anyone had the time to review this submission.

On Mon, 2012-03-12 at 15:06 +0000, James Murray wrote:
> I believe the attached patch remedies the concerns that Nick raised on
> my previous submission.
> 
> Plain text NEWS and ChangeLog entries:
> 
> bfd/ChangeLog:
> 2012-03-12  James Murray <jsm@jsm-net.demon.co.uk>
> 
>     * Add S12X and XGATE co-processor support to m68hc11 target
>     (during period 2008-01 -> 2012-03)
>     Allows S12X and XGATE code to be linked together.
>     * Option to offset S12 addresses into XGATE memory space.
>     * Fix carry bug in IMM16 (IMM8 low/high) relocate.
> 
> gas/ChangeLog:
> 2012-03-12  James Murray <jsm@jsm-net.demon.co.uk>
> 
>     * Add S12X and XGATE co-processor support to m68hc11 target
>     (during period 2008-01 -> 2012-03)
>     Most S12X extensions supported (new opcodes, extended movb/movw
>     modes) except EXG,SEX,TFR shaded areas.
>     * Option to offset S12 addresses into XGATE memory space.
>     * Tweak target flags to match other tools. (i.e. -m m68hc11)
>     * Other historical m68hc11/12 changes from Stephane Carrez.
> 
> gas/testsuite/ChangeLog
> 2012-03-12  James Murray <jsm@jsm-net.demon.co.uk>
> 
>     * gas/m68hc11/insns9s12x.s: New
>     * gas/m68hc11/insns9s12x.d: New
>     * gas/m68hc11/hexprefix.s: New
>     * gas/m68hc11/hexprefix.d: New
>     * gas/m68hc11/9s12x-exg-sex-tfr.s: New
>     * gas/m68hc11/9s12x-exg-sex-tfr.d: New
>     * gas/m68hc11/insns9s12xg.s: New
>     * gas/m68hc11/insns9s12xg.d: New
>     * gas/m68hc11/9s12x-mov.s: New
>     * gas/m68hc11/9s12x-mov.d: New
>     * gas/m68hc11/m68hc11.exp: Updated
>     * gas/m68hc11/*.d: Brought in line with changed objdump output.
>     * gas/all/gas.exp: XFAIL all hc11/12 targets for redef2,3
>     * gas/elf/elf.exp: XFAIL all hc11/12 targets for redef
> 
> gas/NEWS
> * Update m68hc11 port. Add support for S12X and XGATE processors
> 
> ld/testsuite/ChangeLog
> 2012-03-12  James Murray <jsm@jsm-net.demon.co.uk>
> 
>     * ld-m68hc11/xgate-link.s: New
>     * ld-m68hc11/xgate-link.d: New
>     * ld-m68hc11/xgate-offset.s: New
>     * ld-m68hc11/xgate-offset.d: New
>     * ld-m68hc11/xgate1.s: New
>     * ld-m68hc11/xgate1.d: New
>     * ld-m68hc11/xgate2.s: New
>     * ld-m68hc11/m68hc11.exp: Updated
>     * ld-m68hc11/*.d: Brought in line with changed objdump output
>     * ld-gc/gc.exp: Update CFLAGS for m68hc11
> 
> ld/NEWS
> * Update m68hc11 port. Add support for S12X and XGATE processors.
> 
> opcodes/ChangeLog
> 2012-03-12  James Murray <jsm@jsm-net.demon.co.uk>
> 
>     * Add S12X and XGATE co-processor support to m68hc11 target
>      (during period 2008-01 -> 2012-03)
>     * Make objdump output more consistent, use hex instead of decimal
>     and use 0x prefix for hex
>     * Other historical m68hc11/12 changes from Stephane Carrez.
> 
> regards
> 
> James Murray 

Patch is in http://sourceware.org/ml/binutils/2012-03/msg00123.html

Re: 68hc11/12/s12x/xgate patch

[James Murray]

Ping.

On Mon, 2012-04-02 at 13:37 +0100, James Murray wrote:
> Ping.
> 
> Just wondered if anyone had the time to review this submission.
> 
> On Mon, 2012-03-12 at 15:06 +0000, James Murray wrote:
> > I believe the attached patch remedies the concerns that Nick raised on
> > my previous submission.
> > 
> > Plain text NEWS and ChangeLog entries:
> > 
> > bfd/ChangeLog:
> > 2012-03-12  James Murray <jsm@jsm-net.demon.co.uk>
> > 
> >     * Add S12X and XGATE co-processor support to m68hc11 target
> >     (during period 2008-01 -> 2012-03)
> >     Allows S12X and XGATE code to be linked together.
> >     * Option to offset S12 addresses into XGATE memory space.
> >     * Fix carry bug in IMM16 (IMM8 low/high) relocate.
> > 
> > gas/ChangeLog:
> > 2012-03-12  James Murray <jsm@jsm-net.demon.co.uk>
> > 
> >     * Add S12X and XGATE co-processor support to m68hc11 target
> >     (during period 2008-01 -> 2012-03)
> >     Most S12X extensions supported (new opcodes, extended movb/movw
> >     modes) except EXG,SEX,TFR shaded areas.
> >     * Option to offset S12 addresses into XGATE memory space.
> >     * Tweak target flags to match other tools. (i.e. -m m68hc11)
> >     * Other historical m68hc11/12 changes from Stephane Carrez.
> > 
> > gas/testsuite/ChangeLog
> > 2012-03-12  James Murray <jsm@jsm-net.demon.co.uk>
> > 
> >     * gas/m68hc11/insns9s12x.s: New
> >     * gas/m68hc11/insns9s12x.d: New
> >     * gas/m68hc11/hexprefix.s: New
> >     * gas/m68hc11/hexprefix.d: New
> >     * gas/m68hc11/9s12x-exg-sex-tfr.s: New
> >     * gas/m68hc11/9s12x-exg-sex-tfr.d: New
> >     * gas/m68hc11/insns9s12xg.s: New
> >     * gas/m68hc11/insns9s12xg.d: New
> >     * gas/m68hc11/9s12x-mov.s: New
> >     * gas/m68hc11/9s12x-mov.d: New
> >     * gas/m68hc11/m68hc11.exp: Updated
> >     * gas/m68hc11/*.d: Brought in line with changed objdump output.
> >     * gas/all/gas.exp: XFAIL all hc11/12 targets for redef2,3
> >     * gas/elf/elf.exp: XFAIL all hc11/12 targets for redef
> > 
> > gas/NEWS
> > * Update m68hc11 port. Add support for S12X and XGATE processors
> > 
> > ld/testsuite/ChangeLog
> > 2012-03-12  James Murray <jsm@jsm-net.demon.co.uk>
> > 
> >     * ld-m68hc11/xgate-link.s: New
> >     * ld-m68hc11/xgate-link.d: New
> >     * ld-m68hc11/xgate-offset.s: New
> >     * ld-m68hc11/xgate-offset.d: New
> >     * ld-m68hc11/xgate1.s: New
> >     * ld-m68hc11/xgate1.d: New
> >     * ld-m68hc11/xgate2.s: New
> >     * ld-m68hc11/m68hc11.exp: Updated
> >     * ld-m68hc11/*.d: Brought in line with changed objdump output
> >     * ld-gc/gc.exp: Update CFLAGS for m68hc11
> > 
> > ld/NEWS
> > * Update m68hc11 port. Add support for S12X and XGATE processors.
> > 
> > opcodes/ChangeLog
> > 2012-03-12  James Murray <jsm@jsm-net.demon.co.uk>
> > 
> >     * Add S12X and XGATE co-processor support to m68hc11 target
> >      (during period 2008-01 -> 2012-03)
> >     * Make objdump output more consistent, use hex instead of decimal
> >     and use 0x prefix for hex
> >     * Other historical m68hc11/12 changes from Stephane Carrez.
> > 
> > regards
> > 
> > James Murray 
> 
> Patch is in http://sourceware.org/ml/binutils/2012-03/msg00123.html

Re: 68hc11/12/s12x/xgate patch

[nick clifton]

Hi James,

> just wondered if you had found time to review the patch I submitted.
> (Patch is in http://sourceware.org/ml/binutils/2012-03/msg00123.html )

Sorry it has taken me so long to review this patch, and thanks for the ping.

I have now gone over the patch.  There were a few formatting issues, but 
these were minor.  The main thing (to me) is that it works and it does 
not break any other ports.  So I have checked it in.

This does mean that we now have two different ways of supporting the 
XGATE processor.  I feel that the best way to resolve this is to see how 
these two ports fare in the long term.  If one of them turns out to be 
too buggy or unmaintained then it will be dropped.

Cheers
   Nick

Re: 68hc11/12/s12x/xgate patch

[Fred Cooke]

Hi Nick,

It's really exciting to see James' general fixes and additions to some
of the S12 architecture code make it into the source. Thank you for
finally getting around to doing that, I know quite a few people will
appreciate it.

What's less exciting, or perhaps, somewhat disturbing, is that you
included the XGATE portion of James' work, which you have previously
described as "A magnet for bugs". I agree with your initial prognosis
and, quite frankly, I'm not comfortable using the official sources to
build binaries for my users. Our application isn't a typical software
system, in fact, quite the opposite. Thousands of dollars of hardware
are at stake with each installation, and a failure from a new S12
binutils bug could potentially lead to loss of life. Currently our
system has a clean reputation that I'm unenthusiastic about
compromising, especially in a life threatening way.

References:

http://cygwin.com/ml/binutils/2012-01/msg00057.html
http://cygwin.com/ml/binutils/2012-01/msg00087.html
http://cygwin.com/ml/binutils/2012-01/msg00089.html

Due to the current state of the S12 code, as of today, I'll now have
to build and distribute binaries based on a fork or older version.
It's unfortunate that this extra work load has not subsided as it
appeared it was soon going to. I look forward to a time when I can
have faith in the vanilla S12 binutils again and shall be personally
taking measures to make that happen as soon as possible.

Regards,

Fred.

On Tue, May 15, 2012 at 2:55 PM, nick clifton <nickc@redhat.com> wrote:
>
> Hi James,
>
>> just wondered if you had found time to review the patch I submitted.
>> (Patch is in http://sourceware.org/ml/binutils/2012-03/msg00123.html )
>
>
> Sorry it has taken me so long to review this patch, and thanks for the ping.
>
> I have now gone over the patch.  There were a few formatting issues, but these were minor.  The main thing (to me) is that it works and it does not break any other ports.  So I have checked it in.
>
> This does mean that we now have two different ways of supporting the XGATE processor.  I feel that the best way to resolve this is to see how these two ports fare in the long term.  If one of them turns out to be too buggy or unmaintained then it will be dropped.
>
> Cheers
>  Nick
>
>

Re: 68hc11/12/s12x/xgate patch

[James Murray]

On Tue, 2012-05-15 at 13:55 +0100, nick clifton wrote:
> I have now gone over the patch.  There were a few formatting issues, but 
> these were minor.  The main thing (to me) is that it works and it does 
> not break any other ports.  So I have checked it in.

Thanks for taking the time, I appreciate that there was a fair bit to
review.

> This does mean that we now have two different ways of supporting the 
> XGATE processor.  I feel that the best way to resolve this is to see how 
> these two ports fare in the long term.  If one of them turns out to be 
> too buggy or unmaintained then it will be dropped.

OK, understood.

As noted before, this code (earlier version of it) is in active use and
has been used to generate firmware that is powering thousands of
vehicles.

regards

James