"Numerical Recipes in C" is nonport

[Richard A. O'Keefe]

In article <225800063 at uxe.cso.uiuc.edu> mcdonald at uxe.cso.uiuc.edu writes:
>This seems logically inconsistent. You say that on the Unisys A-series
>that the problem is in the compiler. But then you say there is no
>C compiler. If the problem exists in other language compilers,
>simply leave it out of C! Simply write the compiler so that it doesn't
>check pointers. (If it did do that, wouldn't it be a horrendous time
>penalty? Every time you said "pointer++" it would have to check
>bounds, unless the pointer were declared the non-existant "noalias".)
>
>What about assembly language? What is to stop things from 
>happening there with out of bounds pointers?
>
>Doug McDonald

WHAT assembly language?  NEWP (an Algol-like language) is as close to
assembly language as one gets on the A-series.  The point is that the
machine was not designed to do pointer arithmetic (there isn't even a
single notion of "address"; Indirect Reference Words and Indexed
Descriptors have different tags and interpretations).  The operating
system has been able to rely on this.  If you generate code to do
"pointer arithmetic" on, say, Indexed Descriptors, you find that (a) you
just bypassed the Virtual Memory system, and (b) bye-bye system integrity!
The compilers don't general special code to check pointers, so it isn't
something you can "leave out of" C.

The systems-programming languages do have things called pointers, which are
Indexed Descriptors, and can be adjusted.  But incrementing such a pointer
by N involves touching each word of storage referenced so that a boundary
word won't be missed (not a performance hit, because this is not the kind
of thing A-series machines are normally asked to do).

I know of two BCPL compilers for the A-series, one actual one and one that
was designed but not finished.  Neither of them was a pretty sight.  (The
PL/I compiler had similar troubles.)

The A-series is a "high level" architecture for a particular set of
languages (Algol, Fortran, COBOL) and that you can't expect languages
outside that set to map well onto it.