Re: Grouping data from different modules together

[hestermeyer@ida.ing.tu-bs.de (Andreas Hestermeyer)]

In article <62368@aurs01.UUCP> throopw%sheol@concert.net writes:
>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...

Sorry, I posted this to a couple of the lang.xxx groups to start a discussion.
I simply do not know how to send ONE post to more than one group other than
posting the article twice.

>
>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).
>

But how should we tell the linker ? If we don't do that in the language
we again run into a situation where we would have to make changes in more 
than one file, if we change only one thing. 
And, looking at the way linkers presently get their instructions what to do :
it's all in the language by using keywords like 'extern' (C,C++). Why shouldn't
something like this be used here ?

>
>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).
>

Hmm, I don't really see what you mean. If you're addressing segmented 
memory models like in the 80x86 architecture : right. But still, there
is physical contiguous memory and the compiler should be able to
map our variables where we want them. Well, I often do not want to know
'where' in memory (at which physical address) they are, simply the fact
that they reside in a contiguous portion of memory and that I have access 
to the start address and to the size of the block is sufficient. 
I agree that binding the variables to addresses might often be better
implemented as a pragma. Anyhow, other languages ( (Turbo)Pascal, ADA)
do provide this feature and they do a good job, I think.

Andreas Hestermeyer