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