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

devel-digest          Wednesday, June 9 1999          Volume 02 : Number 192

In this issue:

    Re: floatlib.c
    Re: floatlib.c
    Re: gcc bug ??
    Re: floatlib.c
    Re: gcc bug ??
    Re: floatlib.c
    nettrom and disk images
    Re: nettrom and disk images
    Re: nettrom and disk images
    Re: floatlib.c
    Re: Email anti virus checkers?
    Re: floatlib.c
    Re: nettrom and disk images
    Re: floatlib.c

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

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

Date: Tue, 08 Jun 1999 09:48:36 +0100
From: Philip Blundell <[email-masked]>
Subject: Re: floatlib.c

Andrew Coles wrote:

> I was going to look at the code and see if there are any bits of C code
> which could benefit from assembler code making full use of the ARM
> instruction set (like, combining shifts & adds etc.) as the gcc optimizer,
> although quite good, is still not as good as hand-written optimized
> assembler. I was going to focus on the core functions that were called a
> lot - stripping out the mantissa / exponent,
> addition/subtraction/multiplication/division.

Yes, this would be a good thing to look at.  It should be possible to do the
easy cases for the simple operations like add and subtract in far fewer
instructions than gcc currently emits.  If you compile softfloat.c with -S
the results aren't all that pretty.

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: Tue, 08 Jun 1999 13:06:27 +0200
From: Jan Rinze <[email-masked]>
Subject: Re: floatlib.c

Philip Blundell wrote:

>   If you compile softfloat.c with -S
> the results aren't all that pretty.
>
> p.

Tell Pat Beirne about that .. I cannot convince him that the C compiler could
give 60% speed increase if actually optimised for SA110.

ARM has developed a C compiler with such improvements and is gcc compatible.
Just if REBEL.com would get this compiler it could improve the software on the
Netwinder a lot ..
(it is not in my budget though.. )

I would like to contribute to the assembler sources.
So : Andrew Coles, get in contact with me.
janrinze at netwinder.org

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: Tue, 08 Jun 1999 13:21:18 +0200
From: Jan Rinze <[email-masked]>
Subject: Re: gcc bug ??

Philip Blundell wrote:

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

Just out of curiosity, i will look for examples in code.
I do recall something about ANSI / ISO being indeterminate about some
order of  parameter evaluation. This is somewhat besides the issue.
What I do wonder about is wheter the gcc on the ARM is essentially the
same compiler as for the x86 or is it a different version altogether.
I have been doing some programming that needs to be running on both
platforms. I noticed this failure in compatibility and decided to report it.
The main thought here was that gcc on x86 and gcc on ARM were derived
from the same source. Here I could be making my mistake.
Ofcourse two different compiler can have two different results if programs
make non-ISO / non-ANSI assumptions. Although the same compiler on
two different machine ought not to give different results..

My main concern here is I get two different results for the same piece of
code with the 'same' compiler.

I cannot imagine the problems when using C++ which has even more complicated
structures that can be out-of-order and hence out-of-sync.
Then again we already had the alignment problem.
I agree about sticking to conventions and fixed my problems in that matter.
It only gives me an uneasy feeling about the future of ARM platforms under
Linux.
Since not everyone keeps their source free from compiler dependant assumptions.

Jan Rinze.
advocate for unity and compatibility under Linux ( in his sparetime...).

- ---
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: Tue, 08 Jun 1999 14:42:27 +0100
From: Philip Blundell <[email-masked]>
Subject: Re: floatlib.c

Jan Rinze wrote:

> Philip Blundell wrote:
>
> >   If you compile softfloat.c with -S
> > the results aren't all that pretty.
>
> Tell Pat Beirne about that .. I cannot convince him that the C compiler could
> give 60% speed increase if actually optimised for SA110.

You would have a hard time convincing me of that as well.  I think I already
responded to one of our earlier posts about the ARM SDT along these lines.

It is true that the performance of GCC's generated code is not quite leading-edge
on most platforms, but in the vast majority of cases it's not that bad either.
The floating point emulator is not especially representative of normal code and
in fact you can persuade gcc to do at least a little better with that by tweaking
the C to give it more clues about which cases are likely to be common.

"Optimised for SA110" is a misleading term to use.  GCC already knows about the
StrongARM architecture well enough to perform instruction scheduling.  Where
GCC does lag behind other vendor compilers, possibly including the ARM SDT, is in
higher level optimisations.  And the situation here is improving slowly; the
soon-to-be-released gcc 2.95 will include several significant improvements over
earlier versions.

> ARM has developed a C compiler with such improvements and is gcc compatible.

> Just if REBEL.com would get this compiler it could improve the software on the
> Netwinder a lot ..

As I mentioned before, it is not a drop-in replacement for GCC.  You can compile
Linux applications with the ARM SDT with a little bit of hacking, but using it to
compile the kernel or C library would be very hard.   So I'm not especially
convinced it would give the kind of spectacular speed improvement you suggest,
except for specific applications.

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: Tue, 08 Jun 1999 14:47:36 +0100
From: Philip Blundell <[email-masked]>
Subject: Re: gcc bug ??

Jan Rinze wrote:

> What I do wonder about is wheter the gcc on the ARM is essentially the
> same compiler as for the x86 or is it a different version altogether.

It is the same compiler.  Obviously there is a different back-end to generate code
for the different processor, and this may well influence the compiler's choice of
code sequence for particular situations.

> Ofcourse two different compiler can have two different results if programs
> make non-ISO / non-ANSI assumptions. Although the same compiler on
> two different machine ought not to give different results..

As I said before, you should expect to get different results even from the same
compiler on the same machine.  If you invoke undefined behaviour absolutely
anything can happen.  What you are doing is pretty much equivalent to using the
value of an uninitialised variable.

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: Tue, 08 Jun 1999 10:36:29 -0400
From: "Andrew E. Mileski" <[email-masked]>
Subject: Re: floatlib.c

Philip Blundell wrote:
> "Optimised for SA110" is a misleading term to use.  GCC already knows about the
> StrongARM architecture well enough to perform instruction scheduling.

I was actually quite impressed with the -O3 code egcs spat out for the
little memory bandwidth test posted in this group recently.  It looked
gawd awful, but on closer inspection there was logic to the mess it was
creating (it was being pretty darn clever).  Of course I expect egcs to
outwit itself in some cases too (other test code wasn't as clever).

The -O2 code was down right boring [pretty well as written in C].

- --
Andrew E. Mileski - Software Engineer [Wizard of 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: Tue, 08 Jun 1999 11:28:28 -0500
From: "B. Darryl DeGraff" <[email-masked]>
Subject: nettrom and disk images

Does anyone have experience with the nettrom-2.0.8(e|g)?  What do they
bring to the party?

Any news on the new disk image (waiting anxiously!)?

darryl (li-cor)

- ---
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: Tue, 08 Jun 1999 13:53:47 -0400
From: "Andrew E. Mileski" <[email-masked]>
Subject: Re: nettrom and disk images

"B. Darryl DeGraff" wrote:
> Does anyone have experience with the nettrom-2.0.8(e|g)?  What do they
> bring to the party?

[Woody: "Tag! You're it!"]

> Any news on the new disk image (waiting anxiously!)?

The latest build is nearly complete, except for a bug in X.
It looks a lot like build 14 in content, except almost everything
has been updated to the current version (a *lot* of updates).

- --
Andrew E. Mileski - Software Engineer [OS Chef]
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: Tue, 08 Jun 1999 18:08:55 +0000
From: Mike Montour <[email-masked]>
Subject: Re: nettrom and disk images

B. Darryl DeGraff wrote:
> 
> Does anyone have experience with the nettrom-2.0.8(e|g)?  What do they
> bring to the party?

I'm running 2.0.8e, and it fixes a problem with serial-console
support. Older versions would freeze at the 'more' prompt
when you did a 'printenv'. I think there are also improvements
in the recognition of 2.2 ELF kernels. I haven't seen (g) yet,
but 2.0.8e doesn't seem to introduce any problems relative to
the older versions and should be a fairly safe upgrade (with
standard disclaimers).

- -- 
		      -Mike  [[email-masked]]

- ---
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: 8 Jun 1999 18:10:03 GMT
From: "Andrew Coles" <[email-masked]>
Subject: Re: floatlib.c

> >   If you compile softfloat.c with -S
> > the results aren't all that pretty.
> >

Possibly dumb question coming up -  where is softfloat.c? I've got a full
egcs 1.1.2 source tree here. floatlib.c, fp-bit.c are all there, but no
softfloat.c. Or is softfloat.c a part of the kernel/netwinder patches to
egcs?

> Tell Pat Beirne about that .. I cannot convince him that the C compiler
could
> give 60% speed increase if actually optimised for SA110.

Do you mean compile time with that or code produced? Looking at egcs
produced code - quite good if optimised well (-03 -fomit-frame-pointer ...)
but due to the '80% of time in 20% of code' rule (don't know who thought of
it) assembler can be put to good use if you can find the 20%....

On that note - anyone know some good free profiling software for the ARM?
  
> ARM has developed a C compiler with such improvements and is gcc
compatible.
> Just if REBEL.com would get this compiler it could improve the software
on the
> Netwinder a lot ..
> (it is not in my budget though.. )

A few thousand $ last time I checked (and I'm a student...). But the ARM
optimisations in egcs (soon to be gcc...) have improved in recent years.

<snip>

Does anyone know where's there a document describing how to inline ARM
assembler into C code? I had a look this weekend and couldn't find
anything. I did, however, find one inline instruction on the NetBSD/arm32
mailing list and hacked the syntax from that. If there isn't one then I'll
summarise it and stick it on my webpage in case anyone wants to know.

Another late night with copious mugs of hot lava java planned ;-) I know my
way round floatlib.c now, so fp-bit.c is next. Once that's done I'll start
noting down possible optimisations.

Regards

Andrew

- ---
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: Tue, 08 Jun 1999 14:53:35 -0400
From: Charles Stuart <[email-masked]>
Subject: Re: Email anti virus checkers?

VMware on the Intel platform - runs nicely on a PII-266.  It also works
pretty well displayed on a 'Winder via X.

Andrew E. Mileski wrote:
> 
> Andrew Coles wrote:
> > Come to think of it - a virtualised
> > PC would be the ideal virus-scanner zone if you were really paranoid -
> > spawn a virtual pc, run the software and see if it breaks anything. Just a
> > thought.
> 
> Sounds great!  When can we expect you to deliver it? :p
> 
> --
> Andrew E. Mileski - Software Engineer [OSmosis]
> 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: Tue, 8 Jun 1999 19:37:25 +0100
From: "Philip Blundell,,," <[email-masked]>
Subject: Re: floatlib.c

In article <01beb1d5$194a4240$LocalHost@a> you write:
>Possibly dumb question coming up -  where is softfloat.c? I've got a full
>egcs 1.1.2 source tree here. floatlib.c, fp-bit.c are all there, but no
>softfloat.c. Or is softfloat.c a part of the kernel/netwinder patches to
>egcs?

Sorry, I should have explained that better.  It's part of the kernel,
look in arch/arm/nwfpe.

>On that note - anyone know some good free profiling software for the
>ARM?

gprof :-)

>Does anyone know where's there a document describing how to inline ARM
>assembler into C code? I had a look this weekend and couldn't find

The GCC manual explains how to use asm() in general terms and I think
it has a section on the ARM specific constraints too.  Other than
that, there isn't much documentation.  If you ask here or on the
linux-arm mailing lists then someone can probably help you out.

p.
- --
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: Tue, 08 Jun 1999 16:16:17 -0400
From: Ralph Siemsen <[email-masked]>
Subject: Re: nettrom and disk images

I've just updated my page at
http://www.netwinder.org/~ralphs/compat.html with the details on 2.0.8
series firmware... this is basically extracted from the cvs sources.
- -- 
Ralph Siemsen -- [email-masked]

- ---
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: Tue, 08 Jun 1999 22:24:58 -0400
From: Scott Bambrough <[email-masked]>
Subject: Re: floatlib.c

Andrew Coles wrote:
> 
> Possibly dumb question coming up -  where is softfloat.c? I've got a full
> egcs 1.1.2 source tree here. floatlib.c, fp-bit.c are all there, but no
> softfloat.c. Or is softfloat.c a part of the kernel/netwinder patches to
> egcs?

softfloat.c is part of the SoftFloat package written by John Hauser.  A copy
of it is in my ftp area (users/s/scottb) on netwinder.org.  Look for the
libfloat tarball.

> On that note - anyone know some good free profiling software for the ARM?

The only profiling software I know of is gprof and sprof, both of which are
included with the NetWinder DM.

> 
> Does anyone know where's there a document describing how to inline ARM
> assembler into C code? I had a look this weekend and couldn't find
> anything. I did, however, find one inline instruction on the NetBSD/arm32
> mailing list and hacked the syntax from that. If there isn't one then I'll
> summarise it and stick it on my webpage in case anyone wants to know.

I believe the inline assembler documentation is in gcc.info.  You have to hunt
for it however.

Scott

- ---
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 #192
***************************

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