Subject: devel-digest V2 #188
From: [email-masked] (devel-digest)
To: [email-masked]

devel-digest           Friday, June 4 1999           Volume 02 : Number 188

In this issue:

    Re: gcc bug ??
    Re: Interesting drhystone test
    Re: Interesting drhystone test
    Re: gcc bug ??
    Re: memory bandwidth problems
    Re: memory bandwidth problems
    Re: memory bandwidth problems
    Re: memory bandwidth problems

See the end of this digest for information about devel-digest.

----------------------------------------------------------------------

Date: Thu, 03 Jun 1999 17:15:41 +0200
From: Jan Rinze <[email-masked]>
Subject: Re: gcc bug ??

Philip Blundell wrote:

> Jan Rinze wrote:
>
> > dosomething( readfromfile(),readfromfile(),readfromfile());
> >
> > is differently interpreted in x86 gcc than SA110 gcc.
>
> I think your code is broken.  If I recall correctly C makes no guarantee
> about the order in which these expressions will be evaluated.
>
> p.

Urf ???

You mean that gcc on the ARM does something totally different than on the
x86 and
that is my fault ??

If any program compiled with such assumptions ( gcc afterall is gcc .. )
then it just wont run on an ARM platform , right ??

What about compatibilities ???

I recon many programs may suffer from these problems. I might just be a
major reason for not being able to port some programs.

Just doing a call like:

setvars ( computevar(i),i++);

would cause a 1 offset when computed right to left.
On a x86 it will result , if i=10 for example, in:

setvars ( computevar(11),10);

On the ARM it will do :

setvars ( computevar(10),10);

Just let me know if  nobody uses code like this and that it is illegal to
use code like this.

IMHO, all versions of gcc should do the same if given the same code.

IF NOT, gcc has a big compatibility problem. This would mean that it is no
longer
portable.

Jan Rinze.

- ---
This message processed by the Netwinder.Org news2mail gateway.

- --
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel" as the body of your message.

------------------------------

Date: Thu, 03 Jun 1999 17:30:18 +0200
From: Jan Rinze <[email-masked]>
Subject: Re: Interesting drhystone test

Philip Blundell wrote:

> Jan Rinze wrote:
>
> > Pat Beirne wrote:
> > Well, I heard a little bird that said that the ARM Ltd compiler does 500000
> > + dhrystones on a netwinder....
> > tests showed that the compiler creates upto 60% faster code...
> > (and its gcc compatible !)
>
> [Grr.  Just discovered that my news installation can't talk to servers
> that need authentication, so I'm reduced to reposting articles directly
> using Netscape.]
>
> Kind of.  Last I heard it was still not totally trivial to use code
> built with ARM CC on a GNU system.
>
> I'd a bit startled (though pleased) if you got anything approaching a
> 60% speedup for much real code.
>
> p.

Just think about things like:

varadress          .word  0x12345678  ; = a
adress:              .word  varadress

# c code:
#  a=a+1;

        ldr R1,adress;
        ldr R0,[R1];
        add R0,R0,#1
        str R0,[R1];

faster would be :

        ldr R0,varadress;
        add R0,R0,#1;
        str R0,varadress;

This is not used in gcc as far as I know.
 the first uses at minimum 6 cycles
whereas the latter uses 4 cycles.

6/4= 1.5  or just a 50% speed increase.

Just a thought though ... I don't really know what ARM's compiler does exactly.
the upper code only is needed for out-of-range varadresses.

Jan Rinze.

- ---
This message processed by the Netwinder.Org news2mail gateway.

- --
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel" as the body of your message.

------------------------------

Date: Thu, 03 Jun 1999 16:47:18 +0100
From: Philip Blundell <[email-masked]>
Subject: Re: Interesting drhystone test

Jan Rinze wrote:

> varadress          .word  0x12345678  ; = a
> adress:              .word  varadress
>
> # c code:
> #  a=a+1;
>
>         ldr R1,adress;
>         ldr R0,[R1];
>         add R0,R0,#1
>         str R0,[R1];
>
> faster would be :
>
>         ldr R0,varadress;
>         add R0,R0,#1;
>         str R0,varadress;

You would need help from the linker to make this work.  The compiler can't
guarantee that the code and the data will end up close enough together to pull
this trick.  But if you take a routine like

    int a;

    f()
    {
      while (g())
        a++;
    }

you will see that GCC only loads the address of "a" once and holds it in a
register through the loop.  The impact of the extra load ought not to be that
great.

p.

- ---
This message processed by the Netwinder.Org news2mail gateway.

- --
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel" as the body of your message.

------------------------------

Date: Thu, 03 Jun 1999 17:00:44 +0100
From: Philip Blundell <[email-masked]>
Subject: Re: gcc bug ??

Jan Rinze wrote:

> Philip Blundell wrote:
>
> > Jan Rinze wrote:
> >
> > > dosomething( readfromfile(),readfromfile(),readfromfile());
> > >
> > > is differently interpreted in x86 gcc than SA110 gcc.
> >
> > I think your code is broken.  If I recall correctly C makes no guarantee
> > about the order in which these expressions will be evaluated.
>
> Urf ???
>
> You mean that gcc on the ARM does something totally different than on the
> x86 and that is my fault ??

No.  What is your fault is that your program depends on behaviour that the C
language simply does not provide. The ANSI standard explicitly states that
the order of evaluation of the parameters to a function call is unspecified;
the only guarantee is that that all side effects from evaluating the
parameters must have occurred before the actual call takes place.  I don't
have a copy of ISO here but I imagine it contains similar wording.

> If any program compiled with such assumptions ( gcc afterall is gcc .. )
> then it just wont run on an ARM platform , right ??

No legal C program should contain such assumptions.  The results are
undefined.  I imagine this is covered in the comp.lang.c FAQ, by the way.

> On a x86 it will result , if i=10 for example, in:
>
> setvars ( computevar(11),10);
>
> On the ARM it will do :
>
> setvars ( computevar(10),10);

This is not an issue of x86 versus ARM.  The same compiler may evaluate
expressions in a different order under differing circumstances.

p.

- ---
This message processed by the Netwinder.Org news2mail gateway.

- --
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel" as the body of your message.

------------------------------

Date: Thu, 3 Jun 1999 10:48:40 -0700
From: Tim Rowledge <[email-masked]>
Subject: Re: memory bandwidth problems

"Andrew E. Mileski" <[email-masked]> wrote:

>copy_to_user() does a lot more work than that.  Take a look at all the
>uaccess.* files.
Excuse the dumb question (bad cold today, preventing adequate oxygen reacgin
brain) but where shuould I find these files? 'find' says I don't have them on
my local drive, and they're not in my (admittedly a little old) copy of the
Itsy source tree.

- ---
This message processed by the Netwinder.Org news2mail gateway.

- --
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel" as the body of your message.

------------------------------

Date: Thu, 03 Jun 1999 16:19:23 -0400
From: "Andrew E. Mileski" <[email-masked]>
Subject: Re: memory bandwidth problems

Tim Rowledge wrote:
> "Andrew E. Mileski" <[email-masked]> wrote:
> >copy_to_user() does a lot more work than that.  Take a look at all the
> >uaccess.* files.
> Excuse the dumb question (bad cold today, preventing adequate oxygen reacgin
> brain) but where shuould I find these files? 'find' says I don't have them on
> my local drive, and they're not in my (admittedly a little old) copy of the
> Itsy source tree.

Download the full kernel tree from netwinder.org.  It's called nwkernsrc
I think [weird name - blame Ralph for that].

- --
Andrew E. Mileski - Software Engineer [OS Tamer]
Rebel.com  http://www.rebel.com/

- ---
This message processed by the Netwinder.Org news2mail gateway.

- --
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel" as the body of your message.

------------------------------

Date: Thu, 3 Jun 1999 15:35:00 -0700
From: Tim Rowledge <[email-masked]>
Subject: Re: memory bandwidth problems

"Andrew E. Mileski" <[email-masked]> wrote:

>Download the full kernel tree from netwinder.org.  It's called nwkernsrc
>I think [weird name - blame Ralph for that].
OK, grabbed that with no problems, but there appear to be no files named
uaccess*. I _did_ find a definition of memcpy_tofs in ..../arm/lib/segment.S
which filled me with nostalgic memories of when I wrote a self compiling bitBLT
years ago for Smalltalk on Acorns and Active Books. Ah, memories....

Anyway, it answers my question: there's no point in replacing the function
because it does it's job quite effectively and is used all over the place.
Surprise, surprise....

tim

- ---
This message processed by the Netwinder.Org news2mail gateway.

- --
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel" as the body of your message.

------------------------------

Date: Thu, 03 Jun 1999 20:01:27 -0400
From: "Andrew E. Mileski" <[email-masked]>
Subject: Re: memory bandwidth problems

Tim Rowledge wrote:
> "Andrew E. Mileski" <[email-masked]> wrote:
> >Download the full kernel tree from netwinder.org.  It's called nwkernsrc
> >I think [weird name - blame Ralph for that].
> OK, grabbed that with no problems, but there appear to be no files named
> uaccess*. I _did_ find a definition of memcpy_tofs in ..../arm/lib/segment.S
> which filled me with nostalgic memories of when I wrote a self compiling bitBLT
> years ago for Smalltalk on Acorns and Active Books. Ah, memories....

Oh, c'est mon faux pas...I was looking at the 2.2 kernel (been renamed).

- --
Andrew E. Mileski - Software Engineer [OS Tamer]
Rebel.com  http://www.rebel.com/

- ---
This message processed by the Netwinder.Org news2mail gateway.

- --
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel" as the body of your message.

------------------------------

End of devel-digest V2 #188
***************************

--
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel-digest" as the body of your message.