lkml.org 
[lkml]   [1998]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectThe Kommunity vs. Dick Johnson
Date



I did some poking at Dick Johnson's asm for a checksum routine vs.
what gcc produces. I compared his hand
coded routine to the checksum function in his codestream C program. I
assume it does essentially the same thing as his hand coded version.
I snipped out the checksum function, re-named it main(), and declared
size_t as an int so it would compile by itself. I don't know x86
assembly at all.

I didn't even run any of the examples. I don't doubt his attractive
performance claims. Linus says do what interests you. I'm curious
about how complex a machine is required to have a decent Linux
platform, and whether the simplest such machine model is at all
portable, so my comparison was done with gcc -S, ed, cut, sort and
uniq. On my bogus version of his chksum() gcc produced about the same
overall quantity of code as Dick did, but the chunks between branch
labels were smaller via gcc. Makes sense. -O6 was different than the
defaults, but not hugely so, at a glance anyway. Dick's C looked
pretty tight to my amateur eye, and performance is not under question
here anyway.

The plain gcc and gcc -O6 both produced code using 21 or so different
opcodes. Mnemonics, rather. Dick used 27 different instructions. Hmmm.
Here's who_used_what....


gcc Dick Johnson
no -O

1 adcl
2 adcw
3 addl addl
4 addw
5 andl andl
6 clc
7 cmpl cmpl
8 decl
9 esl
10 incl
11 jbe jbe
12 je
13 jmp jmp
14 jne
15 jnz
16 jz
17 leal
18 movb
19 movl movl
20 movw
21 movzbl
22 movzwl
23 negl
24 nol
25 notl
26 orl
27 popl popl
28 pushl pushl
29 ret ret
30 sarl
31 sbbl
32 shll
33 shrl shrl
34 subl subl
35 testl
36 xorl xorl

This seems like a notable difference, even if the algorithms compared
don't do *exactly* the same things. I think it's evident that Dick has
a distinctly different style than gcc. The part that interests me is,
For the checksum problem, both styles can be accomodated with 36
instructions, and Dick's, which is no doubt closer to the optimum in
this case, can be accommodated with only 27.

The hand-asm had about 5 occurences of identical complete
instructions, including what was addressed. The gcc stuff had 2. That
surprises me. I thought that might be a good optimizer heuristic, but
apparently not.

I recognize a few of these mnemonics. Some are obscure to me. How
obscure are they to a SPARC/PPC/Arm etc. ? Or is this question moot in
light of address mode differences?

Dick has a pleasant README along with the code in question in

boneserver.analogic.com/pub/downloads/linux/linux-asm.tar.gz .

I found the most interesting parts of the README to be some of his
comments on his optimization techniques. He, or others, might consider
that these techniques can be added to gcc optimization heuristics, or
even to gcc C's "C extensions", and that such an effort will give
greatest impact to his expertise.

Rick Hohensee http://cqi.com/~humbubba
colorg on EFnet IRC #linux chanop
cLIeNUX xart kandinski cycluphonics ratioles Md., USA
This is your brain on colorg --> (@#*%@#() <---~~~_()()(
Any questions?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.787 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site