Re: shitty programming [WAS: Chucks address]

[Greg Alexander <galexand@xxxxxxx>]

>>>What is the alternative?
>>
>>FORTH.
>>
>>Preferably running on a MISC chip. But the MISC chip is not an absolute
>>requirement.
>>
>>>Procedures/functions will need local
>>>memory so they will need some sort of stack mechanisme.
>>>It's also very inexpensive, just decrement the stack pointer
>>>and push the instruction pointer.
>>
>>Sucks for passing data on the stack.
>>
>>And of course the programmer is no longer  in charge. The compiler writer is.
>>
>>I have spent many an hour when designing in C discussing what the compiler
>>might or might not be doing to our code.
>
>I hear people say this all the time, but I've never heard anyone give an
>example of a concrete situation where it's actually impossible to get C to
>do what you want.  So here I go:
>
>	We have a quadtree data structure that has the interesting
>property that to go one level deeper you shift two bits (the value of
>those two bits decides what child you're going to) into an index, and
>to go up you shift two bits out of the index.  Conveniently, this index
>forms either an absolute address into the quadtree, or, depending on how
>you do things, a simple offset from the absolute address.  Very
>convenient.  You can now do recursive programming without a stack, you
>just need to shift your indexes...it's essentially as if the index was
>itself a stack.
>	In the C paradigm of things, this means we want a static register
>variable, i.e., a globally allocated register.  gcc apparently hasa  bad
>(bad) hack to do this, but I haven't seen it in other compilers and gcc
>generates slow code compared to the compilers we're interested in (SGI's
>cc for Irix).  Besides, we're forced to allocate the register by hand.
>	Otherwise, the C compiler will either have this as a global memory
>variable (slow), or we can pass it on the stack, then we get a dozen
>instances of it.  If the C compiler were designed to prove that a variable
>that always gets shifted at the beginning of a routine and shifted back at
>the end doesn't get changed, and therefore doesn't need a new stack frame,
>we'd be in business, but I've never even seen a C compiler that does a
>very reliable job at tail call optimization so I'm certainly not
>optimistic about this optimization ever being included.
>	With FORTH, of course, you don't worry about it: the data stack is
>basically a register and you can allocate it how you want.  You don't push
>return addresses on it (who would push return addresses on the data stack?
>fools!) so when recurring you never have to shuffle anything about,
>there's your index right on the top of the stack.
>	Sure, Quadtree codes are fairly uncommon.  I guess you might say,
>even, that speed doesn't matter.  If speed doesn't matter, use LCC, forget
>these optimizing compilers -- save yourself the 3 minutes that it takes to
>run the optimizing compiler and allocate those registers you're so fond
>of.  The big myth that permeates all programming language development is
>that no language is inherently slower than another.  This is a lie.  A C
>compiler /could/ recognize this case and allocate a global register or
>keep us in a single stack frame, but no C compiler /would/, EVER, in a
>million years, do this.  And any C compiler that did would, in the course
>of getting to this optimization, implement a billion other comparatively
>complicated optimizations and compile would increase to well over a minute
>for a single small function.
>	I hope there are some doubters reading this so that I haven't
>wasted my time preaching to the choir (I know I read this list long before
>I was convinced that the fundamentals of Programming Language Design
>Research were lies). :)