Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!ames!pacbell!noe!marc
From: marc@noe.UUCP (Marc de Groot)
Newsgroups: comp.lang.forth
Subject: Re: Procedure call overhead
Message-ID: <784@noe.UUCP>
Date: 27 Mar 90 22:40:14 GMT
References: <9003230003.AA15895@jade.berkeley.edu>
Sender: usenet@noe.UUCP
Reply-To: marc@noe.UUCP (Marc de Groot)
Organization: Noe Systems, San Francisco
Lines: 51

In article <9003230003.AA15895@jade.berkeley.edu> wmb@MITCH.ENG.SUN.COM writes:
> [Lots of excellent stuff about the labor cost of factoring C code
>  into small routines deleted.]
>Having said all this, I have to admit that, if you look at the C source
>code for my C Forth 83 product, you will see one excruciatingly long
>procedure in the midst of a collection of reasonably-sized ones.  I justify
>this on (are you ready?) efficiency grounds.  It turns out that, in the
>particular case of trying to implement Forth in C, the procedure call
>overhead really does matter.
[ Irrelevancy to current discussion deleted ]
>Actually, it's not only the procedure call overhead that is the reason
>for the big procedure in C Forth, it's also the inability to declare
>global "register" variables, meaning that you would otherwise have to
>keep the data stack pointer, interpreter pointer, and return stack
>pointer in memory.  (Lest anybody think that I'm criticising C for
>not allowing global "register" variables, I would like to point out
>that there are excellent reasons for this restriction.  I leave the
>reasoning as an exercise for the reader, with the following hint:
>consider that C modules may be separately compiled and later linked
>together).

Mitch,
Thank you for addressing my favorite pet peeves about C.  The language
is highly touted as a systems programming language, yet has the annoying
deficiencies listed above.  Like you, I have implemented Forth in C and
run into exactly these problems.

Many C programmers actually argue with me that code written as many small
subroutines is harder to understand and maintain.  I submit to the net that
the understanding is a matter of practice, and that the maintenance argument
is entirely untenable.  The smaller and more regular the code modules are,
the easier it will be to change and replace them.

As for the inability to declare global register variables, I see your point
about multiple object files with separate compilation and linking.  However,
I would like a way to tell the compiler that I will not generate conflicts
related to the above, and to get global register variables.

Implementing Forth in C has pointed out to me in the most glaring manner
the shortcomings of C.

Finally, I have only one reason for wanting to use C on multiple-person
projects: I can read C code written by slobs.
I *can't* read Forth code written by slobs.


-- 
Marc de Groot (KG6KF)         |"...few people know what to do with a computer.
Noe Systems, San Francisco    | They decide that running an operating system
UUCP: uunet!hoptoad!noe!marc  | is a substitute for doing productive work."
Internet: marc@kg6kf.AMPR.ORG | -Chuck Moore