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

devel-digest          Thursday, June 3 1999          Volume 02 : Number 187

In this issue:

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

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

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

Date: Wed, 02 Jun 1999 13:56:13 +0200
From: Jan Rinze <[email-masked]>
Subject: gcc bug ??

Hi there,

I noticed a strange bug :

dosomething( readfromfile(),readfromfile(),readfromfile());

is differently interpreted in x86 gcc than SA110 gcc.

the SA110 processes the readfromfile() from left to right.
The x86 does it from right to left !!!!!

any fix , or does my x86 gcc get it wrong ??

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: Wed, 02 Jun 1999 14:05:15 +0200
From: Jan Rinze <[email-masked]>
Subject: Re: Interesting drhystone test

Pat Beirne wrote:

> I noticed that AndrewM has built a drhystone
> RPM. I installed and ran it, and I got
>     370,370 loops per second.
>
> Then I did a little surfing, and compared this number
> against other machines.
> 75,000 drhystones (II) - same speed as a P90.
>     (from a usenet posting)
> Pentium II 400 MHz MMX w/ 128 MB SDRAM
>     179,193 Drhystones
>     (from http://www.completecomputers.com/cpus.htm)
> SPARCstation SLC
>         drhystones [-O7] 35,714
>         (from
> http://www.centerline.com/productline/center_c/center_c_datasheet.html)
>
> Do these numbers make sense?
>
> Pat

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 !)

Jan Rinze.
( looks like a good investment for rebel / HCC ... )

- ---
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: Wed, 02 Jun 1999 19:01:10 +0100
From: Philip Blundell <[email-masked]>
Subject: Re: memory bandwidth problems

In article <[email-masked]>,
Andrew E. Mileski <[email-masked]> wrote:
>Tim Rowledge wrote:
>> Sadly, recompiling vidcap.o with
>> -funroll-loops makes no improvements :-( I can still only get 10fps of
>> fullframe video. Poo.
>
>Try -O3 too.  I did notice different code in one case, though the
>performace was marginally better in one case, and marginally worse
>in another *shrug*

- -O3 will probably do worse in most real-life situations.  Remember
that cache effects can also make a big difference to this sort of
timing.  The StrongARM cache only allocates on reads so if you
allocate a block of memory and write to it straight away you will be
going out to main memory.  If you read from it first subsequent writes
will hit in the cache and run a lot faster.  And then if you want to
get really serious you can get into cache colouring effects too.

>copy_to_user() does a lot more work than that.  Take a look at all the
>uaccess.* files.

Do bear in mind that the uaccess files look a lot worse than they
really are.  For example, although the macro expansions for get_user()
are something horrific, you will find that a routine like

int f(int *a)
{
  int b;
  __get_user(b, a);
  return b;
}

actually compiles to just this:

        mov     r3, #0
        ldrt    r2,[r0],#0
        mov     r0, r2
        mov     pc, lr

plus some out-of-line code that is only called when there's a fault.
The value in r3 is the return from __get_user which I've illicitly
ignored. :-)

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: Wed, 02 Jun 1999 19:02:41 +0100
From: Philip Blundell <[email-masked]>
Subject: Re: gcc bug ??

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.

- ---
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: Wed, 02 Jun 1999 19:03:38 +0100
From: Philip Blundell <[email-masked]>
Subject: Re: memory bandwidth problems

BTW, lmbench includes measurements of memory bandwidth in a variety of exciting
ways.  I think there are some numbers on my web page.

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: Wed, 02 Jun 1999 17:31:53 -0400
From: "Andrew E. Mileski" <[email-masked]>
Subject: Re: memory bandwidth problems

Philip Blundell 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.
> 
> Do bear in mind that the uaccess files look a lot worse than they
> really are.

I was trying make the point that copy_to_user() is more than just a
memcpy(), i.e. they are not equivalent or interchangeable, and a
copy_to_user() will be (slightly) slower.

I'm not by any means criticizing the source, which looks about as
lean as it can get (though using C++ comments in C or with the C pre-
processor is bad coding style, and one of my personal pet peeves).

- --
Andrew E. Mileski - Software Engineer [Guardian of the sacred OS]
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: Wed, 02 Jun 1999 22:40:17 +0100
From: Philip Blundell <[email-masked]>
Subject: Re: Interesting drhystone test

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.

- ---
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: Wed, 02 Jun 1999 22:41:27 +0100
From: Philip Blundell <[email-masked]>
Subject: Re: memory bandwidth problems

Tim Rowledge wrote:

> "Andrew E. Mileski" <[email-masked]> wrote:
> video memory and write it into user memory at the same time? Are there any
> 'odd' things going on in copy_to_user() that would prevent this from being
> feasible? It looks like it should simply be amemcpy() loop.

You aren't allowed to call copy_to_user from interrupts (not only
might it sleep, but the target page probably won't be there at the
time) but other than that, no.  On the other hand I think Pat or
someone posted a fairly convincing explanation for the slowness being
in the actual copy from VGA space to main memory, so this optimization
may not buy you a whole lot.

The idea of mapping the appropriate bit of PCI space cacheable is
possibly a better one to pursue.  (I have a feeling the Footbridge
book may technically forbid this, but...).  Adding an ioremap_cache
routine is probably the way to go.

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: Wed, 02 Jun 1999 20:29:43 -0700
From: Steven Ng <[email-masked]>
Subject: Re: ncurses hangs

Thanks.  I'll take a look as you suggest, unfortunately not for a couple of
weeks.  I'll probably be reviving this thread then.

Steven

"Andrew E. Mileski" wrote:

> Steven Ng wrote:
> > I built and installed ncurses from the GNU site ncurses-4.2.tar.gz.
> > Non-blocking calls to getch work fine.  Besides the problem I
> > encountered, what are the differences between the ncurses-4.2 and the
> > ncurses-devel-4.2-6.armv4?  What significant changes need to be made to
> > ncurses-4.2 for the NW?
>
> This is a new one :(
>
> If the version doesn't have a "nw" in it, then it is very likely it was
> built from a standard Red Hat SRPM.  Find the SRPM and check the spec
> file to see what patches were applied to the GNU code by Red Hat.
>
> --
> Andrew E. Mileski - Software Engineer [OS Team Leader]
> 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 #187
***************************

--
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.