Fix spelling error in psim

  Hi

OK to commit as obvious?

2014-08-21  Joel Sherrill <joel.sherrill@oarcorp.com>

    * ppc-instructions: Fix spelling error.

            case spr_tbu:
  

On Wed, Aug 20, 2014 at 3:45 PM, Joel Sherrill
<joel.sherrill@oarcorp.com> wrote:
>
> Hi
>
> OK to commit as obvious?
>
> 2014-08-21  Joel Sherrill <joel.sherrill@oarcorp.com>
>
>     * ppc-instructions: Fix spelling error.
>
> diff --git a/sim/ppc/ppc-instructions b/sim/ppc/ppc-instructions
> index 1b8fd89..1a2e51a 100644
> --- a/sim/ppc/ppc-instructions
> +++ b/sim/ppc/ppc-instructions
> @@ -3355,7 +3355,7 @@ void::function::invalid_zero_divide_operation:cpu
> *proces
>           spreg new_val = (spr_length(n) == 64
>                            ? *rS
>                            : MASKED(*rS, 32, 63));
> -         /* HACK - time base registers need to be updated immediatly */
> +         /* HACK - time base registers need to be updated immediately */
>           if (WITH_TIME_BASE) {
>             switch (n) {
>             case spr_tbu:

Yep.
[If this were gdb one might want a "." followed by two spaces here,
but this isn't gdb.  Lucky you. :-)]
  

On Wed 20 Aug 2014 17:45:33 Joel Sherrill wrote:
> OK to commit as obvious?

certainly.  i'd point out that `git grep immediatly` shows a bunch more hits 
too :).
-mike
  

On Wed 20 Aug 2014 17:10:36 Doug Evans wrote:
> [If this were gdb one might want a "." followed by two spaces here,
> but this isn't gdb.  Lucky you. :-)]

that's enforced in new code (which psim is anything but).  i'd have no problem 
if someone felt like going through and cleaning that particular issue up in 
the whole code base.

sim should be following GNU style conventions.  i dislike them, but it's part 
of a larger GNU project, so deviating anyways would be bad form :).
-mike
  

> > [If this were gdb one might want a "." followed by two spaces here,
> > but this isn't gdb.  Lucky you. :-)]
> 
> that's enforced in new code (which psim is anything but).  i'd have no
> problem if someone felt like going through and cleaning that
> particular issue up in the whole code base.
> 
> sim should be following GNU style conventions.  i dislike them, but
> it's part of a larger GNU project, so deviating anyways would be bad
> form :).

Interestingly, I have always considered sim to be part of the GDB
project, and therefore under GDB coding style.
  

On Thu 21 Aug 2014 09:15:35 Joel Brobecker wrote:
> > > [If this were gdb one might want a "." followed by two spaces here,
> > > but this isn't gdb.  Lucky you. :-)]
> > 
> > that's enforced in new code (which psim is anything but).  i'd have no
> > problem if someone felt like going through and cleaning that
> > particular issue up in the whole code base.
> > 
> > sim should be following GNU style conventions.  i dislike them, but
> > it's part of a larger GNU project, so deviating anyways would be bad
> > form :).
> 
> Interestingly, I have always considered sim to be part of the GDB
> project, and therefore under GDB coding style.

aren't they the same thing ?  i guess let's see.

gdb/CONTRIBUTE says:
o   Coding Standards

    All contributions must conform to the GNU Coding Standard.
    Submissions which do not conform to the standards will be
    returned with a request to reformat the changes.

which is what i thought ... but then there's this follow up:
    GDB has certain additional coding requirements.  Those
    requirements are explained in the GDB internals documentation
    in the gdb/doc directory.

except there's no gdbint.texinfo anymore.  let's check the website:
https://www.gnu.org/software/gdb/documentation/
GDB Internals Manual (wiki only)
https://sourceware.org/gdb/wiki/InternalsManual
https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards

ok, i guess there's a few more rules here.  having the sim follow those is 
fine.
-mike
  

On 8/21/2014 2:15 AM, Joel Brobecker wrote:
>>> [If this were gdb one might want a "." followed by two spaces here,
>>> but this isn't gdb.  Lucky you. :-)]
>> that's enforced in new code (which psim is anything but).  i'd have no
>> problem if someone felt like going through and cleaning that
>> particular issue up in the whole code base.
>>
>> sim should be following GNU style conventions.  i dislike them, but
>> it's part of a larger GNU project, so deviating anyways would be bad
>> form :).
> Interestingly, I have always considered sim to be part of the GDB
> project, and therefore under GDB coding style.
>
Let me fix the spelling issues first.  Is that OK?

I am not opposed to fixing the style issues but really don't have to get
sucked into them right now.

Can uncrustify or some other tool help?
  

> Let me fix the spelling issues first.  Is that OK?
> 
> I am not opposed to fixing the style issues but really don't have to get
> sucked into them right now.

That would be absolutely fine. The fact that you are improving
one area does not mean that you are then responsible for making
that particular area perfect.