Xref: utzoo comp.lang.misc:2241 comp.arch:7400
Path: utzoo!utgpu!watmath!clyde!att!rutgers!mailrus!purdue!i.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.misc,comp.arch
Subject: Re: Assembly or ....
Message-ID: <1037@l.cc.purdue.edu>
Date: 1 Dec 88 13:10:35 GMT
References: <1388@aucs.UUCP> <729@convex.UUCP> <1961@crete.cs.glasgow.ac.uk> <2416@osiris.UUCP>
Organization: Purdue University Statistics Department
Lines: 143

In article <2416@osiris.UUCP>, consult@osiris.UUCP (Unix Consultation Mailbox ) writes:
> I've trimmed all the language-specific groups out of the posting list for
> this followup and directed followups to just comp.lang.misc and comp.arch.
> (I feel the issues being discussed are too general to make it useful to post
> outside of comp.lang.misc, with the exception of comp.arch, where many of
> the points being raised will look very familiar.)
> 
> 
> In article <1032@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
> >A trivial example [of useful operations unsupported in HLLs] is having a
> >list of results to the left of the replacement operator.  I do not mean a
> >vector or a struct; the items may be of different types, and should not be
> >stored in adjacent memory locations.  Most of the time, they should end up
> >in registers.  I have not seen a language which is claimed to produce even
> >reasonably efficient code with this property.  Some of these operations are
> >even hardware.
> 
> I'll have to ask... what kind of things are you talking about here (beyond
> the really obvious one, see below)?  (Which of them "are even hardware"?)
> Why "shouldn't" the results be stored in adjacent memory locations?  And if
> you want to be able to take advantage of the knowledge that they're in
> registers, you'll probably have to use assembly anyway, so why is this a
> requirement for HLLs?  The only "languages" I've seen where any of this
> stuff makes any sense are all assembly, and then only when catering to the
> specifics of the hardware, which can be different even between models of the
> "same" box.

Besides the quotient and remainder, there are operations like unpacking
floating point numbers into exponent and mantissa, which are hardware on
some machines, and should be on others.  I know of machines for which the
hardware instuction to do this even puts the results in different TYPES of
registers.  A few HLL implementations attempt to make use of registers,
although most of them do things badly.

Besides having this situation for hardware operations, it should also be
use for software.  Take, for example, the C function frexp.  The syntax
is
	y = frexp(x,&n)

instead of the more reasonable

	y,n = frexp(x)

There is no reason why the compiler must store the integer n in some location.
But even if this is to be done, the second notation is more appropriate, as it
clearly specifies that the operation returns TWO values.

A commonly used procedure in numerical mathematics is interpolation.  If one
is using fixed interval interpolation, one has the operation

	n,x = m*y

where n is the integer part of the product and x the fraction.  This is 
hardware on the VAX, and probably should be done in fixed-point arithmetic
on most other machines.  (What HLLs support fixed-point "real" arithmetic?)
This is especially the case if m is a power of 2, in which case the multiply
instruction should usually not be used.  But in any case, the pair n,x is the
result of the operation.

Also, one frequently needs a function and its derivative.  The usual bad 
practice is to use two calls.  In most cases, a common calculation is more
efficient.  This would be much more common if the list on the left of =
notation were in use.  Mathematicians have been using functions returning
a list for centuries.  How come the language gurus do not understand this
yet?

> >Another effect of the HLL tyranny is that the operations which are beyond
> >the ken of th HLL designers are disappearing from the machines....  For
> >example, suppose we want to divide a by b, obtaining an integer result i
> >and a remainder c.  I know of no machine with this instruction, and this
> >is not that unusual an instruction to demand.  It is cheap in hardware,
> >and extremely expensive in software--at least 4 instructions.
> 
> I know of at least one machine with this instruction (the LSI-11 with EIS
> for integer divide and multiply).  There are probably many more.  As for it
> being "cheap in hardware", that's not really true, although if you have the
> divide it's virtually free to offer divide with remainder.

I do not know if I made this clear, but a, b, and c are floating.

> I tend to agree with Herman that it would be frequently useful to be able to
> do this in a HLL.  However, frequently useful may not mean useful enough, as
> readers of comp.arch well know.  HLL designers must justify features they
> include, lest their language be named Ada (TM Dept of Redundancy Dept :-).
> Also, there's that little problem Herman mentioned in his followup to Doug
> Gwyn, that different hardware may not implement desired features, or may
> implement them differently enough to make incorporating them into a standard
> HLL very very difficult.  Successful HLLs tend to deal with common subsets
> of hardware features, which are increasingly small these days what with
> diverging architectures.  The newfangled RISC chips and boards are helping
> somewhat although even their designers can't seem to agree on what
> constitutes an ideal instruction set (aside from the Z/OISC people who think
> even Turing machines are too complicated).
> 
> Bear in mind that I am not an expert, merely someone with lots of experience
> with various machines and HLLs.  In other words, I'm probably wrong, but
> probably not by much.
> 
> I think that if Herman had been following comp.arch religiously for the last
> few years he may not have had to ask any of these questions.  Maybe we need
> a list of answers to commonly asked questions... it might help avoid things
> like the recent "which is better, 80386 or 68030" posting...

A check of comp.arch would show that I have been posting to comp.arch for the
past few years.  These questions have not been answered.  I also have been
posting to several of the comp.lang groups.

The fact that operations are not available on all machines does not necessarily
mean that they should not be in the languages.  I recently had to use the
unpack described above from double to long long on a VAX.  It SHOULD have 
been possible to add this to the language as a macro without having to go
through gobs of overhead, as well as the other operations used not present
in any HLL.  The algorithm is statable in an augmented HLL and the machine
dependencies are handled by having a few machine parameters available in
a #include file.  I have a fair amount of experience with machine operations
on different machines, and I find it easier to think in terms of them and 
macros than to use some of the extremely clumsy HLL constructs.  But by a
macro processor, I mean something like what a compiler goes through in 
translating 
		x = y - z

into machine code.

The problem with assembler language is that the above would have to be
written

some-absurd-mnemonic	some permutation of x,y,z

in most assemblers.  I do know of exceptions.  Now in the early days, when
it was hard for computers to handle character strings, the above was needed.
What is a compiler but a typed, overloaded operator, macro converter with a
few gadgets added?  Some of these gadgets can be very useful, but augmenting
the first part to allow more types and more overloading (C++ does this, but
clumsily), user-defined operators, and more flexibility would be far more 
useful.  Also, people who understand the use of hardware-type operations
can suggest them.  The quotient and remainder in floating-point should be
based on simialar hardware to the integer version with an internal trap if
the divisor has larger magnitude than the divident to avoid loss of accuracy.
I have given other examples where hardware was much better than software.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)