From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f891f,e3872dcf7881cc60,start X-Google-Attributes: gidf891f,public X-Google-Thread: 109fba,c17a40c108d019fd X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,b865518fde7413cd X-Google-Attributes: gid103376,public X-Google-Thread: f8c65,3a0cb1c81182932 X-Google-Attributes: gidf8c65,public X-Google-Thread: 1014db,e3872dcf7881cc60,start X-Google-Attributes: gid1014db,public X-Google-ArrivalTime: 1993-03-02 18:03:22 PST Xref: sparky comp.lang.ada:4436 comp.lang.c:22036 comp.lang.c++:21902 comp.lang.modula2:1990 comp.lang.misc:4345 Path: sparky!uunet!wupost!howland.reston.ans.net!gatech!concert!aurs01!throopw%sheol From: throopw%sheol@concert.net Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.lang.modula2,comp.lang.misc Subject: Re: Grouping data from different modules together Message-ID: <62368@aurs01.UUCP> Date: 2 Mar 93 16:05:46 GMT References: <1993Mar1.153217.3290@ibr.cs.tu-bs.de> <1993Mar1.153634.4146@ibr.cs.tu-bs.de> <1993Mar1.153053.2961@ibr.cs.tu-bs.de> <1993Mar1.153252.3446@ibr.cs.tu-bs.de> <1993Mar1.171045.17020@wdl.loral.com> <1993Mar1.141751.17670@sei.cmu.edu> <1993Mar2.073345.29349@ib Sender: news@aurs01.UUCP Followup-To: comp.lang.misc Date: 1993-03-02T16:05:46+00:00 List-Id: 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