Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!decwrl!shelby!Portia!alderson@Jessica
From: alderson@Jessica (Rich Alderson)
Newsgroups: comp.lang.misc,comp.lang.c,comp.arch
Subject: architectural support in languages (was Re: Generalizing Integers)
Keywords: PL/I
Message-ID: <2052@Portia.Stanford.EDU>
Date: 4 May 89 18:50:10 GMT
References: <1032@myrias.UUCP> <12289@reed.UUCP> <16568@winchester.mips.COM> <10377@polyslo.CalPoly.EDU> <3899@ficc.uu.net> <2788@garth.UUCP>
Sender: USENET News System <news@Portia.stanford.edu>
Reply-To: alderson@Jessica (Rich Alderson)
Followup-To: comp.lang.misc
Organization: Stanford University Academic Information Resources
Lines: 31
Xref: utzoo comp.lang.misc:2894 comp.lang.c:18376 comp.arch:9546

PL/1 on the System/360 provided much support for the hardware representation of
various data types.  The biggest problem was the decision of the designers to
default FLOAT to DECIMAL, which caused a number of conversion errors to creep
in when doing long chains of operations.

The previous posting was wrong about the use of type markers such as "B" for
binary integers:  Fixed binary was represented as either decimal digits (with
conversion) or as binary digits with a suffixed "B" to prevent their interpre-
tation as large decimal numbers.  Thus, a FIXED BINARY(31,16) number represen-
ting 2**5+2**-1 could be either "32.5" or "10000.1B"--the compiler made no
distinction.

BCD representation was done with the PICTURE declaration:  To hold "32.5" in
exact BCD representation, the variable should be (at least) declared

	PICTURE '99V9'

which says allow 3 digits, with an assumed decimal point between the second and
third.

Because PL/1 allowed overlay of two data items in certain cases, and had a
bitstring type (represented as a string of bits in single quotes and suffixed
with a "B"), manipulation of the raw bits in a fixed binary number (for
example) was possible.  And it was much cleaner, because explicit, than the
Pascal trick of using variant records without tags.

I realize that the previous poster tried to move this off of comp.arch, but it
seemed to me that given the occasional discussion here of HLL support for
machine-level constructs, this had to go there as well.

Rich Alderson