Xref: utzoo comp.lang.misc:2233 comp.arch:7392
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!haven!mimsy!aplcen!osiris!consult
From: consult@osiris.UUCP (Unix Consultation Mailbox )
Newsgroups: comp.lang.misc,comp.arch
Subject: Re: Assembly or ....
Message-ID: <2416@osiris.UUCP>
Date: 29 Nov 88 18:25:59 GMT
References: <1388@aucs.UUCP> <729@convex.UUCP> <1961@crete.cs.glasgow.ac.uk> <8993@smoke.BRL.MIL> <1032@l.cc.purdue.edu>
Reply-To: consult@osiris.UUCP (Unix Consultation Mailbox (Phil))
Followup-To: comp.lang.misc,comp.arch
Organization: The Johns Hopkins Hospital, Information Systems
Lines: 66

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.

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


                                                                 Phil Kos
                                                      Information Systems
...!uunet!pyrdc!osiris!phil                    The Johns Hopkins Hospital
                                                            Baltimore, MD