Article View: comp.lang.modula2
Article #2193Re: Generic stack implementation
From: Andreas Borchert
Date: Tue, 15 Dec 1992 15:04
Date: Tue, 15 Dec 1992 15:04
81 lines
3888 bytes
3888 bytes
In article <911288c.32.724187845@ace.acadiau.ca>, 911288c@ace.acadiau.ca (HON (EDWIN) KIN CHUNG) writes:
> In article <9212091316.AA14856@elg> ob@IFI.UIB.NO (Ole-Bjorn Tuftedal) writes:
> >From: ob@IFI.UIB.NO (Ole-Bjorn Tuftedal)
> >Subject: Generic stack implementation
> >Date: 9 Dec 92 13:16:09 GMT
> >Here comes the implementation module of the generic stack:
> >==========================================================================
> >
> >IMPLEMENTATION MODULE StackADT;
> >(* Generic stack abstract data type.
> >Sincovec & Wiener: "Data Structures Using Modula-2", 1986 p. 66 ff.
> >*)
[stuff deleted]
> > wordcount: CARDINAL;
> > location: ADDRESS;
> >BEGIN
> > IF empty(s) THEN
> > stackunderflow
> > ELSE
> > size := s^.size;
> > oldnode := s^.next;
> > location := oldnode^.contents;
> > FOR wordcount := 0 TO size DIV TSIZE(WORD) - 1 DO
> > item[wordcount] := location^;
> > INC(location, TSIZE(WORD));
> ^^^^^^
> parameter not correct type ??
>
> Is this some problem ...???
> I am using TopSpeed Modular-2.
Obviously, TopSpeed Modula-2 violates PIM3 which states in the report
(system dependent facilities) that ADDRESS "is compatible with all pointer
types, and also with the type CARDINAL. Therefore, all operators for
integer arithmetic apply to operands of this type. Hence, the type
ADDRESS can be used to perform address computations and to export the
results as pointers."
On the other hand, TopSpeed can argue that ADDRESS and all the other
stuff from SYSTEM is system dependent and thus they have the freedom
to change all these rules.
Despite of some odd architectures (8086 and upward belong to these class)
address arithmetic is quite portable. As an example, C uses address
arithmetic extensively and it runs on nearly any platform.
> Can anybody help ??
Type functions could provide an alternative:
location := ADDRESS(CARDINAL(location) + CARDINAL(TSIZE(WORD)));
But this is far less portable than the original statement because
ADDRESS ist not guaranteed to fit into a CARDINAL (and vice versa).
In article <psg.1992Dec14.193901.28257> Randy Bush writes:
> eepjm@wombat.newcastle.edu.au (Peter Moylan) writes:
>
> > TopSpeed Modula-2 won't let you do arithmetic on addresses. And a
> > good thing, too, in my opinion. Address arithmetic is one of the
> > most non-portable things you can do, and I'm a little shocked to
> > see an example of it in a textbook.
>
> Hmmm. As one of M2's stated design goals was to be able to write the entire
> operating system in M2. Hence, one wants to write storage [de]allocators,
> device drivers for devices that use multiple addresses, ...
>
> So, the issue is what is a reasonable zero-cost safety to put around the
> mechanism so it is not accidentally misused?
ADDRESS is to be imported from SYSTEM which shouldn't happen accidentally.
Nevertheless, it is horrible to be enforced to use features of SYSTEM
to implement generic data types. But luckily we have Oberon :-)
--
_______________________________________________________________________________
Andreas Borchert, University of Ulm, SAI, D-W-7900 Ulm, Germany
Internet: borchert@mathematik.uni-ulm.de
Technical Details
Message-ID:
<1992Dec15.150410.21677@informatik.uni-ulm.de>Path:
arc1-ca.pugleaf.net!sparky!uunet!spool.mu.edu!yale.edu!ira.uka.de!news.belwue.de!theorie!titania.mathematik.uni-ulm.de!borchertReferences:
<9212091316.AA14856@elg> <911288c.32.724187845@ace.acadiau.ca>Show Full Headers
Complete Article Headers
Newsgroups: comp.lang.modula2 Path: arc1-ca.pugleaf.net!sparky!uunet!spool.mu.edu!yale.edu!ira.uka.de!news.belwue.de!theorie!titania.mathematik.uni-ulm.de!borchert From: borchert@titania.mathematik.uni-ulm.de (Andreas Borchert) Subject: Re: Generic stack implementation Message-ID: <1992Dec15.150410.21677@informatik.uni-ulm.de> Sender: usenet@informatik.uni-ulm.de (Name for nntp-posting) Nntp-Posting-Host: titania.mathematik.uni-ulm.de Organization: University of Ulm, SAI References: <9212091316.AA14856@elg> <911288c.32.724187845@ace.acadiau.ca> Date: Tue, 15 Dec 92 15:04:10 GMT Lines: 81