home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / modula2 / 1568 < prev    next >
Encoding:
Text File  |  1992-12-15  |  3.7 KB  |  94 lines

  1. Newsgroups: comp.lang.modula2
  2. Path: sparky!uunet!spool.mu.edu!yale.edu!ira.uka.de!news.belwue.de!theorie!titania.mathematik.uni-ulm.de!borchert
  3. From: borchert@titania.mathematik.uni-ulm.de (Andreas Borchert)
  4. Subject: Re: Generic stack implementation
  5. Message-ID: <1992Dec15.150410.21677@informatik.uni-ulm.de>
  6. Sender: usenet@informatik.uni-ulm.de (Name for nntp-posting)
  7. Nntp-Posting-Host: titania.mathematik.uni-ulm.de
  8. Organization: University of Ulm, SAI
  9. References: <9212091316.AA14856@elg> <911288c.32.724187845@ace.acadiau.ca>
  10. Date: Tue, 15 Dec 92 15:04:10 GMT
  11. Lines: 81
  12.  
  13. In article <911288c.32.724187845@ace.acadiau.ca>, 911288c@ace.acadiau.ca (HON (EDWIN) KIN CHUNG) writes:
  14. > In article <9212091316.AA14856@elg> ob@IFI.UIB.NO (Ole-Bjorn Tuftedal) writes:
  15. > >From: ob@IFI.UIB.NO (Ole-Bjorn Tuftedal)
  16. > >Subject: Generic stack implementation
  17. > >Date: 9 Dec 92 13:16:09 GMT
  18. > >Here comes the implementation module of the generic stack:
  19. > >==========================================================================
  20. > >
  21. > >IMPLEMENTATION MODULE StackADT;
  22. > >(* Generic stack abstract data type.
  23. > >Sincovec & Wiener:  "Data Structures Using Modula-2", 1986 p. 66 ff.
  24. > >*)
  25. [stuff deleted]
  26. > >   wordcount: CARDINAL;
  27. > >   location: ADDRESS;
  28. > >BEGIN
  29. > >   IF empty(s) THEN
  30. > >      stackunderflow
  31. > >   ELSE
  32. > >      size := s^.size;
  33. > >      oldnode := s^.next;
  34. > >      location := oldnode^.contents;
  35. > >      FOR wordcount := 0 TO size DIV TSIZE(WORD) - 1 DO
  36. > >         item[wordcount] := location^;
  37. > >         INC(location, TSIZE(WORD));
  38. >         ^^^^^^
  39. >         parameter not correct type ??
  40. >     Is this some problem ...???
  41. >     I am using TopSpeed Modular-2.
  42.  
  43. Obviously, TopSpeed Modula-2 violates PIM3 which states in the report
  44. (system dependent facilities) that ADDRESS "is compatible with all pointer
  45. types, and also with the type CARDINAL. Therefore, all operators for
  46. integer arithmetic apply to operands of this type. Hence, the type
  47. ADDRESS can be used to perform address computations and to export the
  48. results as pointers."
  49.  
  50. On the other hand, TopSpeed can argue that ADDRESS and all the other
  51. stuff from SYSTEM is system dependent and thus they have the freedom
  52. to change all these rules.
  53.  
  54. Despite of some odd architectures (8086 and upward belong to these class)
  55. address arithmetic is quite portable. As an example, C uses address
  56. arithmetic extensively and it runs on nearly any platform.
  57.  
  58. >     Can anybody help ??
  59.  
  60. Type functions could provide an alternative:
  61.  
  62.       location := ADDRESS(CARDINAL(location) + CARDINAL(TSIZE(WORD)));
  63.  
  64. But this is far less portable than the original statement because
  65. ADDRESS ist not guaranteed to fit into a CARDINAL (and vice versa).
  66.  
  67. In article <psg.1992Dec14.193901.28257> Randy Bush writes:
  68.  
  69. > eepjm@wombat.newcastle.edu.au (Peter Moylan) writes:
  70. > > TopSpeed Modula-2 won't let you do arithmetic on addresses.  And a
  71. > > good thing, too, in my opinion.  Address arithmetic is one of the
  72. > > most non-portable things you can do, and I'm a little shocked to
  73. > > see an example of it in a textbook.
  74. > Hmmm.  As one of M2's stated design goals was to be able to write the entire
  75. > operating system in M2.  Hence, one wants to write storage [de]allocators,
  76. > device drivers for devices that use multiple addresses, ...
  77. > So, the issue is what is a reasonable zero-cost safety to put around the
  78. > mechanism so it is not accidentally misused?
  79.  
  80. ADDRESS is to be imported from SYSTEM which shouldn't happen accidentally.
  81.  
  82. Nevertheless, it is horrible to be enforced to use features of SYSTEM
  83. to implement generic data types. But luckily we have Oberon :-)
  84.  
  85. -- 
  86. _______________________________________________________________________________
  87.  
  88. Andreas Borchert, University of Ulm, SAI, D-W-7900 Ulm, Germany
  89. Internet: borchert@mathematik.uni-ulm.de
  90.