NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/lang/modula2/1582

Text File | 1992-12-16 | 3.4 KB | 73 lines

Newsgroups: comp.lang.modula2
Path: sparky!uunet!munnari.oz.au!metro!seagoon.newcastle.edu.au!wombat.newcastle.edu.au!eepjm
From: [e-mail] (Peter Moylan)
Subject: Re: Generic stack implementation
Message-ID: <[e-mail]>
Lines: 61
Sender: [e-mail]
Organization: University of Newcastle, AUSTRALIA
References: <9212091316.AA14856@elg> <[e-mail]> <[e-mail]>
Date: Thu, 17 Dec 1992 00:49:12 GMT

In article <[e-mail]>, [e-mail] (Andreas Borchert) writes:
> In article <[e-mail]>, [e-mail] (HON (EDWIN) KIN CHUNG) writes:
>> In article <9212091316.AA14856@elg> [e-mail] (Ole-Bjorn Tuftedal) writes:
>> >         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, PIM3 is rather vague on what the result of the
computation will be.

Suppose a word holds four bytes on your machine.  Does the operation
    INC (location, TSIZE(WORD))
increment the pointer by four bytes, or by four words?  The answer
probably depends on whether your machine has byte-addressable memory
or word-addressable memory.  Some compiler writers get around this
problem by considering ADDRESS to be equivalent to POINTER TO BYTE
- but this violates the PIM3 rules, which say that an ADDRESS works
like a POINTER TO WORD.

Suppose further that a CARDINAL fits into one word, and that a
pointer needs two words.  (And that the very useful LONGCARD is
not implemented, since PIM3 does not require it.)  What precisely is
meant by the statement "ADDRESS is compatible with CARDINAL" in this
case?

If pointer arithmetic is legal, can you add two pointers together?
Even most assemblers, for a huge variety of machines, consider this
to be illegal, for some very good reasons.

It looks to me as if the PIM3 statements about address arithmetic
were made before Wirth had started thinking about portability
issues.  I'm convinced that this is a design error, which would
probably have been fixed if PIM5 had ever appeared.

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

Have you ever tried to port a large C program from one platform to
another?  Fixing up the address arithmetic in a supposedly portable
C program can be a major headache.

The design of C presupposes a linear address space.  As soon as you
try to use C with a segmented architecture, you find yourself having
to write C in a style which is not quite standard C.  Even so, pointer
arithmetic in C is actually a bit more portable than the PIM3 pointer
arithmetic, because of the C rule that pointer arithmetic includes an
invisible adjustment for the size of the objects being pointed to.

--
Peter Moylan                      [e-mail]