lkml.org 
[lkml]   [1999]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Structure vs purism ?
On Thu, 21 Jan 1999, Arvind Sankar wrote:

> On Thu, Jan 21, 1999 at 10:48:45AM -0500, Richard B. Johnson wrote:
> > Maybe, one function at a time --one carefully checked function at a time.
> > For instance, the way we were 'taught` to write code (by instuctors and
> > professors who never built actual products, BTW) goes something like
> > this...
[SNIPPED bad code]
[SNIPPED better code]
>
> Ah, but this is now equivalent instead to
> if (func1()&&func2()&&func3()&&func4())
> do_something();
> else
> complain();
>
> But of course, you're right, in the structured way it is too difficult
> to code different cleanup depending on where I failed, while in the goto
> case all the dirty stuff goes out of the normal flow.
>
Correct.

> >
> > Even the usual loop-counters often produce bad, bad, bad code.
> >
> > for(i=0; i< MAX; i++)
> > do_something();

>
> mm.. not with me. using egcs-1.1.1
>

If the other bugs get fixed it will probably be a winner.

> > Like:
> >
> > void foo()
> > {
> > puts("Do not optimize this away!");
> > }
> > main()
> > {
> > register int i;
> > i = 10;
> > while(i--)
> > foo();
> > }
>
> > main:
> > pushl %ebp
> > movl %esp,%ebp
> > pushl %ebx
> > movl $10,%ebx
> > .L3:
> > decl %ebx # This changes the sign flag.
> > cmpl $-1,%ebx # This is NOT necessary
> > jne .L5 # Should be js .L4 (terminating condition)
> > jmp .L4 # Should fall through to `call foo`
> > .align 4 # Should not exist
> > .L5:
> > call foo
> > jmp .L3
> > .align 4
> > .L4:
> > .L2:
> > movl -4(%ebp),%ebx
> > movl %ebp,%esp
> > popl %ebp
> > ret
>
> Here's what I got:
>
> main:
> pushl %ebp
> movl %esp,%ebp
> pushl %ebx
> movl $9,%ebx
> .p2align 4,,7
> .L5:
> pushl $.LC0 # this was the string
> call puts # even inlines foo() for you :-)
> addl $4,%esp
> subl $1,%ebx # mm.. ah! decl doesn't affect the flags
Err... decl doesn't affect the carry flag. It affects
OF, SF, ZF, AF, and PF.
They could `jns` for numbers less than MAX_INT.


> jnc .L5
> movl -4(%ebp),%ebx
> movl %ebp,%esp
> popl %ebp
> ret


> I think writing code cleanly has the advantage that you don't carry around
> stuff that was optimized for the 386 because gcc 2.6 or whatever had a poor
> optimizer even when current compilers can do a good job.

Well `cleanly` doesn't necessarily mean using {{{{{...}}}}} nesting when
none is required. It also doesn't mean that `goto` can't be used. After
all, the actual op-codes do `gotos` all the while (jumps/jumps on
condition).

> Besides, if the code was written by someone with x86 experience, it is
> possible
> that a different version would actually be faster on a RISC architecture like
> the sparc. Leaving decisions up to the compiler might be better, and should
> get
> less costly as compilers get better.
>
> -- arvind
>

Good machine-code was most always faster on a slow machine than poor
machine-code on a fast machine. However, with the advent on the 400+
MHz processors, where everything is now I/O bound with main memory,
it seems to become less important to minimize instructions. The way
memory access is done becomes a controlling factor now (read/write
whole aligned longwords when you only want to access a byte). This
RISC-ness will go away when we get main memory that can keep up with
the CPU clocks.

It won't be too long now. The 100MHz memory will be running at 330MHz
in a year or two. Unfortunately it's another motherboard change. So,
the fact that good code may not run any faster than bad code presently,
should not be an end unto itself. In a few years, the good code
will outperform the bad code again.

Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.1.131 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
Wisdom : It's not a Y2K problem. It's a Y2Day problem.



-
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:49    [W:0.629 / U:0.900 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site