Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!mtune!mtx5c!mtx5d!mtx5a!mat
From: mat@mtx5a.COM (m.terribile)
Newsgroups: comp.lang.c
Subject: Re: Re: Another portable code question
Message-ID: <1849@mtx5a.COM>
Date: Mon, 6-Jul-87 15:08:50 EDT
Article-I.D.: mtx5a.1849
Posted: Mon Jul  6 15:08:50 1987
Date-Received: Fri, 10-Jul-87 06:28:48 EDT
References: <16673@cca.CCA.COM> <1763@ttrdc.UUCP>
Organization: AT&T Information Systems, Middletown, NJ 07748-4801.
Lines: 60

> >>> There it is in a nutshell, you really don't need the * unless the function
> >>> is declared int (**func)();, then you have pointer to pointer to a fun
> >>> tion returning an integer.
> >
> >True ususally you want to pass the address of a strucuture.  But what if
> >you change the values of the structure in the function, and DON'T want
> >to know about the changes after returning from the function????
> 
> Maybe I am not too familiar with the BIG frame architectures, but I am
> somewhat familiar with items of the Sun/uVaxII genre on down.  The issue
> actually boils down to efficiency of structures and the simple fact is:
> 
> Operations on static variables are ALWAYS faster than operations on auto
> variables.

No it does not, and no they are not.

It does not boil down to that because the question of *what* you are pssing,
and with what semantics, will not go away just because you want it to.

And no, static references are not always cheaper.  On the 68000, a reference
to a something at a fixed address requires 2 to 4 bytes more memory and takes
2 to 4 extra clock cycles than a reference relative to an address register.

> ...  If you insist upon doing big structs as "auto" (stack) variables,
> then there is probably not much difference in speed - both passing a
> structure on the stack and copying to a local "auto" are slow.

You do what you need to to get the semantics you need.  If you don't need
it, don't do it.

> ...  Secondly, MANY C compilers still do not support pushing anything other
> than simple arguments on the stack.  Pushing whole structures is NOT
> portable in my book.

Refusing to use an enhancement that became available years ago and has become
as near to standard as anything else in the language is a disservice to
yourself and to the people who worked to create the enhancement.

> As it turns out, almost ALL efficient C compilers handle static memory
> allocation much better than stack, too.  So, you are not saving any REAL
> memory, although swap decreases.  (Use of static is REQUIRED in our Sun 3.0
> compilers here at USC, ANY auto variable over 16k-bytes in size gets lunched
> on the second recursive entry.

*THIS* is a nonstandard compiler bug.

> It took me 2 weeks and head bashing with the also buggie dbxtool to figure
> this one out.  By breaking things up to <16k-bytes and using static, the
> code zooms!)

Arguing from bugs through bugs what can you expect except misfeatures?
-- 

	from Mole End			Mark Terribile
		(scrape .. dig )	mtx5b!mat
					(Please mail to mtx5b!mat, NOT mtx5a!
						mat, or to mtx5a!mtx5b!mat)
					(mtx5b!mole-end!mat will also reach me)
    ,..      .,,       ,,,   ..,***_*.