home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #23 / NN_1992_23.iso / spool / vmsnet / internal / 1457 < prev    next >
Encoding:
Internet Message Format  |  1992-10-15  |  4.8 KB

  1. Path: sparky!uunet!stanford.edu!agate!usenet.ins.cwru.edu!ukma!darwin.sura.net!zaphod.mps.ohio-state.edu!usc!news.service.uci.edu!unogate!mvb.saic.com!macro32
  2. From: REGI's <NUNEZ@esevvx.cica.es>
  3. Newsgroups: vmsnet.internals
  4. Subject: (None)
  5. Message-ID: <01GPZGKLQOYO0001ZZ@esevvx.cica.es>
  6. Date: Thu, 15 Oct 1992 16:50:00 UTC+0100
  7. Organization: Macro32<==>Vmsnet.Internals Gateway
  8. X-Gateway-Source-Info: Mailing List
  9. Lines: 99
  10.  
  11. >X-Envelope-to: MACRO32@WKUVX1.bitnet
  12. >X-VMS-To: IN::"MACRO32@WKUVX1.BITNET"
  13.  
  14. 1
  15. 12-OCT-1992 20:04:35.45
  16.    1 00:00:00.00
  17. 13-OCT-1992 20:04:35.45
  18. @UKCC.uky.edu:MacroMan@WKUVX1.BITNET
  19. gutier@SEVAXU.CICA.ES
  20.  
  21. Received: from UKCC.uky.edu by ESEVVX.CICA.ES ;  9-OCT-1992 20:04:32.46
  22. Received: from ukcc.uky.edu by UKCC.uky.edu (IBM VM SMTP V2R2)
  23.    with BSMTP id 4897; Fri, 09 Oct 92 13:39:07 EDT
  24. Received: from WKUVX1.BITNET by ukcc.uky.edu (Mailer R2.08) with BSMTP id 6915;
  25.  Fri, 09 Oct 92 13:39:06 EDT
  26. Errors-To: MacroMan@WKUVX1.BITNET
  27. X-ListName: "VMS Internals, MACRO, and BLISS Discussions"
  28.     <MACRO32@WKUVX1.BITNET>
  29. Received: from CUNYVM.BITNET (MAILER) by WKUVX1 (MX V3.1C) with BSMTP; Fri, 09
  30.           Oct 1992 12:32:27 CDT
  31. Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.08) with BSMTP id 8368; Fri,
  32.           09 Oct 92 13:23:23 EDT
  33. Received: from MVB.SAIC.COM by CUNYVM.CUNY.EDU (IBM VM SMTP V2R2) with TCP;
  34.           Fri, 09 Oct 92 13:23:20 EDT
  35. Xref: unogate vmsnet.internals:1419 vmsnet.misc:1011 comp.lang.c:21899
  36. From: <bruce@ais.com>
  37. Reply-To: MACRO32@WKUVX1.BITNET
  38. X-Newsgroups: vmsnet.internals,vmsnet.misc,comp.lang.c
  39. Subject: RE: C Language question
  40. Message-ID: <1992Oct9.110102.5773@ais.com>
  41. Date: 9 Oct 92 11:01:02 GMT
  42. References: <8543225@MVB.SAIC.COM>
  43. Organization: Applied Information Systems, Chapel Hill, NC
  44. Lines: 61
  45. To: MACRO32@WKUVX1.BITNET
  46. X-Gateway-Source-Info: USENET
  47.  
  48. In article <8543225@MVB.SAIC.COM>, "Andy, Systems Manager"
  49.  <UDAA055@ELM.CC.KCL.AC.UK> writes:
  50. > Nigel Arnot writes:
  51. >
  52. >>Question: in C, if one declares char a[I][J], is there anything in the
  53. >>language standard that guarantees that &a[0][0] is the first of a set of
  54. >>I*J contiguous chars, and that a[i+1][0] is guaranteed to be the same
  55. >>storage location as a[i][J] ).
  56. >>
  57. >
  58. > I suppose that it is conceivable for a compiler to use a mechanism for
  59. > indexing that allows the individual elements of an array to be scattered
  60. > in virtual memory. Assuming this is not the case then I think the
  61. > following explanation holds.
  62. >
  63. > A single `dimensioned' array or vector, such as a[i], is contiguous in
  64. > memory in any language. (Obviously, otherwise indexing couldn't work).
  65.  
  66. This isn't quite true.  Most languages don't have a construct for
  67. non-connected storage, but it is by no means impossible.  PL/I for
  68. example has a mechanism for dealing with non-connected (non-contiguous)
  69. storage:
  70.  
  71.         non_connected:  procedure;
  72.         declare array (100, 100) fixed binary;
  73.         declare sub entry ((*) fixed binary);
  74.  
  75.                 call sub (array (*, 1));
  76.                 end non_connected;
  77.  
  78. Since elements are stored in row-major order in PL/I (as in just
  79. about every major language except Fortran), this fragment passes to
  80. the `sub' procedure a `slice' of the `array' which is formed from the
  81. first column of the array - or in other words, from every 101st element
  82. of the `array' as it is stored in memory.  The usual implementation is
  83. for the compiler to write a descriptor that describes the required `step'
  84. size for the array, and to pass that descriptor to the sub-procedure
  85. rather than the address of the array itself.  Because this is less
  86. efficient than indexing items in connected storage (because of the
  87. implied multiply that the optimizer can't reduce in strength since
  88. it doesn't know the multiplier at compile-time, unlike connected
  89. storage where it does know the element size and therefore the step
  90. size between elements), most implementations will pass the address
  91. of the array rather than the descriptor if the formal argument is
  92. declared to be `connected' or to have an explicit array size (the
  93. (*) in the declaration for `sub' says the array can have any size).
  94.  
  95. Anyway this is rather off the track.  C doesn't have a concept of
  96. `connected' versus `unconnected' storage of array items, and has
  97. the explicit definitions that the address of the array is equal to
  98. the address of array[0] and that successive elements of the array
  99. are stored in sequential addresses.  Since a multi-dimensional
  100. array in C is just an array of arrays, this implies that the entire
  101. object must be in connected storage.  I don't think that you could
  102. build a conforming compiler that didn't treat arrays the way Nigel
  103. describes.
  104.  
  105. If there is really a lot of interest in this topic maybe it should be
  106. moved to comp.lang.c or possibly vmsnet.misc rather than remain in
  107. vmsnet.internals, which is a VMS internals newsgroup ...
  108.  
  109. Bruce C. Wright
  110.