🚀 go-pugleaf

In article <smL~rDM@check.sm.unisys.com> pmontgom@sm.unisys.com (Peter Montgomery) writes:
>In article <382@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>>In article <923@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>>>
>>>Programming time is therefore not necessarily faster in HLLs.  Frequently,
>>>I see how to use a machine instruction or instructions to accomplish something
>>>which I consider simple and obvious.  Why should I even have to try to find a
>>>way to do in in some HLL?  The HLL gurus have left out too much.
>>
>>Please tell us about some of these instructions.
>
Summary of Montgomery's message:  64-bit integer operations, and find first
bit.  Summary of my reply:  PL/I can express them.

>	Herman Rubin previously mentioned my most important need:  support
>of long long multiplication and division (multiply two 32-bit numbers to
>get a 64-bit product; divide a 64-bit number by a 32-bit number to get
>quotient and remainder).

It is important to distinguish between *languages* and *implementations*.
PL/I, Pascal, ADA, and Algol 68 can all express these calculations.  With
PL/I, you could get exactly what you want with the built-in functions
MULTIPLY and DIVIDE, if the implementation allowed you.

Any programming language which lets the user specify the range of integer
variables could provide access to these instructions if the implementor
chose to let you declare variables with sufficient range.  Instead of
saying "gimme access to arbitrary machine instructions", why not say
"FINISH the implementation of the language which you offered me, and
let me use a BINARY FIXED (63,0) variable if I really want one."


>        Another need is the truncated base 2 logarithm of an unsigned
>integer n.
>        Although all these architectures allow the function to be computed
>directly (without a loop), the CRAY CFT compiler is the only C or FORTRAN
>compiler I know which lets the programmer express this algorithm and get
>inline code.  [The SUN 3 "inline" utility may work, but its manual page
>states "Only opdefs and addressing modes generated by Sun compilers are
>guaranteed to work"; I want to access an instruction NOT generated by
>these compilers.]

The manual doesn't say that only >instructions< generated by the compilers
work, but that only >addressing modes< generated by the compilers are
guaranteed to work.  BFFFO is an instruction, not an addressing mode.
I have successfully used
cat <<'EOF' >haulong.il
	.inline	_haulong,4
	moveq	#32,d0
	movl	sp@+,d1
	bfffo	d1{#0:d0},d1
	bnes	1f
	moveq	#33,d1
    1:	subl	d1,d0
	.end
EOF
with SunOS 3.2 and SunOS 3.5.  {The ffs() library function searches from
the least significant bit towards the most significant bit.}

In PL/I, you could use INDEX(BIT(source,32), '1'B) to look for the
first bit; it would be easy enough for a compiler to recognise this
particular pattern (the bits would in effect be numbered MSB=1..LSB=32).

And of course ADA can handle these things with the aid of machine-code
inserts, and UNIX V.3 C compilers have asm functions.

I really don't want to be mistaken for a friend of PL/I.
My point is just that there *are* medium-level programming languages
(Ada, some Cs, PL/I) which can handle the examples suggested so far,
even ones (Ada, some Cs) which can be made to generate any instruction.

Could we have some discussion of why
    - PL/I BIT(N) and FIXED(P[,Q]) data types and the operations it provides
      are not adequate
    - ADA machine code inserts are not adequate
    - "inline" or V.3 asm functions are not adequate
    - what could be done to make them adequate