Re: Grouping data from different modules together

[throopw%sheol@concert.net]

First of all, I note that this query was posted as four distinct
articles, <1993Mar1.153634.4146@ibr.cs.tu-bs.de>
and       <1993Mar1.153217.3290@ibr.cs.tu-bs.de>
and       <1993Mar1.153053.2961@ibr.cs.tu-bs.de>
and       <1993Mar1.153252.3446@ibr.cs.tu-bs.de>
with exactly the same text body in each.  (Well, there was a single
extra newline in the one in comp.lang.c)  I may have missed a posting
to comp.lang.pascal; perhaps it didn't arrive here yet.

In general, posting in this way is a Bad Idea, because it wastes storage
space on typical news systems, bandwidth on typical news connections,
and reader time for readers using typical newsreading packages.  A
better way is to post a single article to multiple groups, perhaps with
a Followup-To: setting to gather the discussion back into a single group.
The most discussion of this has occured in the comp.lang.ada group,
but it's relevant to many languages, so I'm issuing a followup-to
comp.lang.misc.  I hope nobody is offended by my attempt to hijack
the discussion in this way.

The original question as I understood it was how to get variables from
scattered modules grouped together contiguously in memory for
efficiency or other pragmatic reasons.

Using "pragmas" or equivalent notions in language implementations
which have them (the example I gave in <731046506@sheol.UUCP> being
taken from a C language system) seems the most practical way to go,
despite not being very portable.  More about portability below.

: From: mab@wdl1.wdl.loral.com (Mark A Biggar)
: Message-ID: <1993Mar1.171045.17020@wdl.loral.com>
: There is a standard way to do this in all the above languages. It is called
: the record stucture.  It is the standard way to group related data items
: together.  This deos require that all the related data items be defined
: in the same file, but if they are related enough to be grouped together, then
: they are related enough to be defined together.

This turns out not to be the case.  For example, items related only in
that they need to occur in specific address ranges because they need
to be placed in ROM vs RAM memory, or items related only in that they
happen to be consecutive IO register mappings, are NOT (I would claim)
related enough to be grouped together in source code.  In fact, I'll
even claim that such items are often UNrelated enough that they ought 
NOT to be grouped together in source code.

I think there are good reasons why such constraints should not
be stated to the compiler (because it has no need to know), but
should instead be stated to the linker/locator (because it does).

Another example of needing consequtivity of things essentially
unrelated needing consecutive storage:

: From: firth@sei.cmu.edu (Robert Firth)
: Message-ID: <1993Mar1.141751.17670@sei.cmu.edu>
: The application was therefore structured as a sequence of small serially
: reusable procedures, [...]
: The table of code fragments had to be linear in memory, and of course was
: constructed by the linker.  After all, when we were maintaining the
: application - several hundred KLOC, a lotta code in those days - and we
: changed a fragment, and it now ran for too long, we broke it in half, and
: surely did *not* want to have to recompile the world after such a change.

The original poster agrees with Robert, and adds:

: From: hestermeyer@ida.ing.tu-bs.de (Andreas Hestermeyer)
: Message-ID: <1993Mar2.073345.29349@ibr.cs.tu-bs.de>
: One should think of a portable way to implement this.

The difficulty with this is, the very notion of "contiguous memory"
involving separately declared variables is itself not portable across
all architectures.  It isn't even portable across all uses of ONE
architecture (the '286... consider that what counts as "contiguous"
depends upon whether one is programming in the "huge model" or
in other models of memory access).

This to me is strong reason why such directives belong in pragmas
and linker directives, and not in portable language constructs.

--
Wayne Throop   throopw%sheol@concert.net
               throop%aurgate@concert.net