Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!quintus!ok
From: ok@quintus.uucp (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: "Numerical Recipes in C" is nonport
Message-ID: <411@quintus.UUCP>
Date: 16 Sep 88 04:14:06 GMT
References: <5162@hoptoad.uucp> <225800069@uxe.cso.uiuc.edu>
Sender: news@quintus.UUCP
Reply-To: ok@quintus.UUCP (Richard A. O'Keefe)
Organization: Quintus Computer Systems, Inc.
Lines: 44

In article <225800069@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes:
>
>In article <225800065@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu 
>(that's me folks) writes:
>>>	Generate code in an array.
>>>	Jump to the beginning of the array. *
>The usually sane Doug Gwyn replies:
>
>>I'm getting a bit tired of talk about "fatal flaws" in the proposed
>>ANSI C standard from people who don't understand the goals and
>>constraints under which such a standard is developed.  ...
>>It is not the job of a C standard to render
>>already nonportable code suddenly, magically portable.
>
>I don't care one whit about what the goals and constraints of X3J11
>(or X3J3 for that matter) ARE. I care about what they OUGHT to do.
>I don't see why being able to create code and execute it could
>cause the hardware of any machine fits.

The most famous example is the B6700, where memory consisted of 52-bit
words (1 parity, 3 tag, 48 data).  Even tags (0 = single precision,
2 = double precision, 4 & 6 hairy) were things user code could manipulate,
odd tags (1 = indirect reference, 5 = array description, 7 = procedure,
3 = boundary/stack control word/code) were not.  At my home university
we installed a hack (for the benefit of a load-and-go Fortran compiler)
which took an array and changed it to code.  But you couldn't use it as
code and data *both* at the same time, and there were a number of other
restrictions.  When MCP 3.0 of the operating system came out, a better
approach would have been to create a code file and attach it as a dynamic
library (that way the code would not have been locked in physical memory).

There are quite a few machines with separate I/D.  The UNIX PERQ was (is?)
one of them.  Some modern RISCs are.  A micro-controller with execute
access only to a ROM would not be able to do this.  And so on.

But all of this misses what I think Doug Gwyn's point is.
If you are generating code into an array, *that* part of the program is
*already* non-portable (because the code is machine-dependent).  The
ANSI C commmittee cannot be expected to demand that everyone emulate
the 80286 in order to make programs which generate 80286 code into an
array and jump to it portable.  If you move your program to another
machine you are going to have to rewrite much if not most of the code
that generates the instructions.  What is so terrible about changing
the call as well?