* 68hc11/12/s12x/xgate patch @ 2011-02-27 22:22 James Murray 2011-03-07 16:35 ` James Murray 0 siblings, 1 reply; 26+ messages in thread From: James Murray @ 2011-02-27 22:22 UTC (permalink / raw) To: binutils [-- 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 --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 68hc11/12/s12x/xgate patch 2011-02-27 22:22 68hc11/12/s12x/xgate patch James Murray @ 2011-03-07 16:35 ` James Murray 2011-03-15 8:33 ` Nick Clifton 0 siblings, 1 reply; 26+ messages in thread From: James Murray @ 2011-03-07 16:35 UTC (permalink / raw) To: binutils 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 68hc11/12/s12x/xgate patch 2011-03-07 16:35 ` James Murray @ 2011-03-15 8:33 ` Nick Clifton 2011-03-15 15:08 ` James Murray 0 siblings, 1 reply; 26+ messages in thread From: Nick Clifton @ 2011-03-15 8:33 UTC (permalink / raw) To: James Murray; +Cc: binutils [-- 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?] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 68hc11/12/s12x/xgate patch 2011-03-15 8:33 ` Nick Clifton @ 2011-03-15 15:08 ` James Murray 2011-12-20 22:20 ` James Murray 0 siblings, 1 reply; 26+ messages in thread From: James Murray @ 2011-03-15 15:08 UTC (permalink / raw) To: Nick Clifton; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 68hc11/12/s12x/xgate patch 2011-03-15 15:08 ` James Murray @ 2011-12-20 22:20 ` James Murray 2011-12-20 22:29 ` Fred Cooke 0 siblings, 1 reply; 26+ messages in thread From: James Murray @ 2011-12-20 22:20 UTC (permalink / raw) To: binutils [-- 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 --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 68hc11/12/s12x/xgate patch 2011-12-20 22:20 ` James Murray @ 2011-12-20 22:29 ` Fred Cooke 2011-12-20 23:23 ` James Murray 0 siblings, 1 reply; 26+ messages in thread From: Fred Cooke @ 2011-12-20 22:29 UTC (permalink / raw) To: binutils 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 > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 68hc11/12/s12x/xgate patch 2011-12-20 22:29 ` Fred Cooke @ 2011-12-20 23:23 ` James Murray 2011-12-21 22:29 ` Fred Cooke 0 siblings, 1 reply; 26+ messages in thread From: James Murray @ 2011-12-20 23:23 UTC (permalink / raw) To: binutils 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 68hc11/12/s12x/xgate patch 2011-12-20 23:23 ` James Murray @ 2011-12-21 22:29 ` Fred Cooke 2011-12-22 16:52 ` Sean Keys 2011-12-22 17:37 ` James Murray 0 siblings, 2 replies; 26+ messages in thread From: Fred Cooke @ 2011-12-21 22:29 UTC (permalink / raw) To: binutils > 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 > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 68hc11/12/s12x/xgate patch 2011-12-21 22:29 ` Fred Cooke @ 2011-12-22 16:52 ` Sean Keys 2011-12-22 17:37 ` James Murray 1 sibling, 0 replies; 26+ messages in thread From: Sean Keys @ 2011-12-22 16:52 UTC (permalink / raw) To: binutils 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 >> ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 68hc11/12/s12x/xgate patch 2011-12-21 22:29 ` Fred Cooke 2011-12-22 16:52 ` Sean Keys @ 2011-12-22 17:37 ` James Murray 2012-01-05 22:03 ` James Murray 1 sibling, 1 reply; 26+ messages in thread From: James Murray @ 2011-12-22 17:37 UTC (permalink / raw) To: binutils; +Cc: skeys 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 68hc11/12/s12x/xgate patch 2011-12-22 17:37 ` James Murray @ 2012-01-05 22:03 ` James Murray 2012-01-05 23:11 ` Fred Cooke 2012-01-10 14:42 ` nick clifton 0 siblings, 2 replies; 26+ messages in thread From: James Murray @ 2012-01-05 22:03 UTC (permalink / raw) To: binutils [-- 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 --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 68hc11/12/s12x/xgate patch 2012-01-05 22:03 ` James Murray @ 2012-01-05 23:11 ` Fred Cooke 2012-01-10 14:42 ` nick clifton 1 sibling, 0 replies; 26+ messages in thread From: Fred Cooke @ 2012-01-05 23:11 UTC (permalink / raw) To: binutils 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 68hc11/12/s12x/xgate patch 2012-01-05 22:03 ` James Murray 2012-01-05 23:11 ` Fred Cooke @ 2012-01-10 14:42 ` nick clifton 2012-01-10 15:45 ` James Murray 2012-02-26 23:54 ` 68hc11/12/s12x/xgate patch James Murray 1 sibling, 2 replies; 26+ messages in thread From: nick clifton @ 2012-01-10 14:42 UTC (permalink / raw) To: James Murray; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 68hc11/12/s12x/xgate patch 2012-01-10 14:42 ` nick clifton @ 2012-01-10 15:45 ` James Murray 2012-01-12 19:39 ` 68hc11/12/s12x/xgate patch - style question James Murray 2012-02-26 23:54 ` 68hc11/12/s12x/xgate patch James Murray 1 sibling, 1 reply; 26+ messages in thread From: James Murray @ 2012-01-10 15:45 UTC (permalink / raw) To: binutils; +Cc: nick clifton 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 68hc11/12/s12x/xgate patch - style question 2012-01-10 15:45 ` James Murray @ 2012-01-12 19:39 ` James Murray 2012-01-12 20:14 ` Fred Cooke 0 siblings, 1 reply; 26+ messages in thread From: James Murray @ 2012-01-12 19:39 UTC (permalink / raw) To: binutils 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 68hc11/12/s12x/xgate patch - style question 2012-01-12 19:39 ` 68hc11/12/s12x/xgate patch - style question James Murray @ 2012-01-12 20:14 ` Fred Cooke 0 siblings, 0 replies; 26+ messages in thread From: Fred Cooke @ 2012-01-12 20:14 UTC (permalink / raw) To: James Murray; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 68hc11/12/s12x/xgate patch 2012-01-10 14:42 ` nick clifton 2012-01-10 15:45 ` James Murray @ 2012-02-26 23:54 ` James Murray 2012-03-12 15:07 ` James Murray 1 sibling, 1 reply; 26+ messages in thread From: James Murray @ 2012-02-26 23:54 UTC (permalink / raw) To: binutils; +Cc: nick clifton 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 68hc11/12/s12x/xgate patch 2012-02-26 23:54 ` 68hc11/12/s12x/xgate patch James Murray @ 2012-03-12 15:07 ` James Murray 2012-03-12 15:26 ` Fred Cooke 2012-04-02 12:37 ` James Murray 0 siblings, 2 replies; 26+ messages in thread From: James Murray @ 2012-03-12 15:07 UTC (permalink / raw) To: binutils; +Cc: nick clifton [-- 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 --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 68hc11/12/s12x/xgate patch 2012-03-12 15:07 ` James Murray @ 2012-03-12 15:26 ` Fred Cooke 2012-03-13 20:28 ` James Murray 2012-04-02 12:37 ` James Murray 1 sibling, 1 reply; 26+ messages in thread From: Fred Cooke @ 2012-03-12 15:26 UTC (permalink / raw) To: James Murray; +Cc: binutils, nick clifton 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 68hc11/12/s12x/xgate patch 2012-03-12 15:26 ` Fred Cooke @ 2012-03-13 20:28 ` James Murray 2012-03-13 20:56 ` Fred Cooke 0 siblings, 1 reply; 26+ messages in thread From: James Murray @ 2012-03-13 20:28 UTC (permalink / raw) To: binutils 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 68hc11/12/s12x/xgate patch 2012-03-13 20:28 ` James Murray @ 2012-03-13 20:56 ` Fred Cooke 0 siblings, 0 replies; 26+ messages in thread From: Fred Cooke @ 2012-03-13 20:56 UTC (permalink / raw) To: James Murray; +Cc: binutils 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 68hc11/12/s12x/xgate patch 2012-03-12 15:07 ` James Murray 2012-03-12 15:26 ` Fred Cooke @ 2012-04-02 12:37 ` James Murray 2012-04-23 17:05 ` James Murray 1 sibling, 1 reply; 26+ messages in thread From: James Murray @ 2012-04-02 12:37 UTC (permalink / raw) To: binutils 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 68hc11/12/s12x/xgate patch 2012-04-02 12:37 ` James Murray @ 2012-04-23 17:05 ` James Murray [not found] ` <1337003987.27195.60.camel@jsm2> 0 siblings, 1 reply; 26+ messages in thread From: James Murray @ 2012-04-23 17:05 UTC (permalink / raw) To: binutils 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <1337003987.27195.60.camel@jsm2>]
* Re: 68hc11/12/s12x/xgate patch [not found] ` <1337003987.27195.60.camel@jsm2> @ 2012-05-15 12:59 ` nick clifton 2012-05-15 18:38 ` Fred Cooke 2012-05-15 20:26 ` James Murray 0 siblings, 2 replies; 26+ messages in thread From: nick clifton @ 2012-05-15 12:59 UTC (permalink / raw) To: James Murray; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 68hc11/12/s12x/xgate patch 2012-05-15 12:59 ` nick clifton @ 2012-05-15 18:38 ` Fred Cooke 2012-05-15 20:26 ` James Murray 1 sibling, 0 replies; 26+ messages in thread From: Fred Cooke @ 2012-05-15 18:38 UTC (permalink / raw) To: nick clifton; +Cc: binutils 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 > > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 68hc11/12/s12x/xgate patch 2012-05-15 12:59 ` nick clifton 2012-05-15 18:38 ` Fred Cooke @ 2012-05-15 20:26 ` James Murray 1 sibling, 0 replies; 26+ messages in thread From: James Murray @ 2012-05-15 20:26 UTC (permalink / raw) To: binutils; +Cc: nick clifton 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2012-05-15 20:26 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-02-27 22:22 68hc11/12/s12x/xgate patch James Murray 2011-03-07 16:35 ` James Murray 2011-03-15 8:33 ` Nick Clifton 2011-03-15 15:08 ` James Murray 2011-12-20 22:20 ` James Murray 2011-12-20 22:29 ` Fred Cooke 2011-12-20 23:23 ` James Murray 2011-12-21 22:29 ` Fred Cooke 2011-12-22 16:52 ` Sean Keys 2011-12-22 17:37 ` James Murray 2012-01-05 22:03 ` James Murray 2012-01-05 23:11 ` Fred Cooke 2012-01-10 14:42 ` nick clifton 2012-01-10 15:45 ` James Murray 2012-01-12 19:39 ` 68hc11/12/s12x/xgate patch - style question James Murray 2012-01-12 20:14 ` Fred Cooke 2012-02-26 23:54 ` 68hc11/12/s12x/xgate patch James Murray 2012-03-12 15:07 ` James Murray 2012-03-12 15:26 ` Fred Cooke 2012-03-13 20:28 ` James Murray 2012-03-13 20:56 ` Fred Cooke 2012-04-02 12:37 ` James Murray 2012-04-23 17:05 ` James Murray [not found] ` <1337003987.27195.60.camel@jsm2> 2012-05-15 12:59 ` nick clifton 2012-05-15 18:38 ` Fred Cooke 2012-05-15 20:26 ` James Murray
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).