Re: 68hc11/12/s12x/xgate patch

[Fred Cooke <fred dot cooke at gmail dot com>]

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.