🚀 go-pugleaf

In article <7958@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes:
>In article <TMB.92Nov20140542@arolla.idiap.ch> tmb@idiap.ch writes:
> > I think it might well be worth trying to standardize an interface to
> > arithmetic that provides you with access to the low-level arithmetic
> > primitives that you need. However, in order to make your code truly
> > portable, you will need to come up with an interface that takes into
> > account that there are machines with odd word sizes. Such a facility
> > needs to have a much more abstract and much more task-specific than a
> > general facility for accessing "low-level features". That is precisely
> > why I think that Rubin and Silverman are barking up the wrong tree.

	[Excellent discussion by Dik Winter of some of the problems deleted.]

>As I said, I do not know what the real solution is, it is certainly not
>as clear-cut as Herman thinks.

I never said that the solution is clear-cut.  I do not think we are 
anywhere near a passable solution.  What others and I, looking at this
problem, have suggested is that improved access to the hardware, and 
improved means of communicating to the compilers, assemblers, etc., 
be provided, with as much flexibility as possible.  

Since the problem is that complicated, the means of communication must be
greatly enhanced.  My suggestion for a versatile macro processor has not,
as far as I can tell, been met by what has been suggested.  The macro
processor I have in mind is one where I can write out a transformation,
describe it, and you can take my description, modify it slightly to your
environment, and implement it in your production of code.

Full efficiency of code can be attained by hand-optimization, with whatever
aid one can get from computers, for a given machine.  But there are aspects
of a program which are at least partially portable, and certainly more 
comprehensible in some other form than assembler, especially the current
assemblers.  The improvements can only be made incrementally, and whenever
some aspect of the problem is considered, complications are likely to arise.


-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!snap.stat!hrubin(UUCP)