ICLZ of UNSIGNED FIXED BIN(16,0)

[Thomas David Rivers]

The IBM documentation for the ICLZ builtin says this:

If the argument x is of the type SIGNED FIXED BIN(p) with p <= 15,
it is
converted to SIGNED FIXED BIN(31). If it is of the type UNSIGNED
FIXED BIN(p)
with p <= 16, it is converted to UNSIGNED FIXED BIN(32).

So, in this example; I expect the argument 'k' to be converted to an
UNSIGNED FIXED BIN(32):

test: proc options(main);

dcl res fixed bin(31);
dcl k unsigned fixed bin(16);

k = 1;
res = ICLZ(k);
display('RES is ' || res);

end;

And - thus, the result of the ICLZ on a value of X'1' with a 32-bit
integer parameter would
be 31.

However, when you execute this program, the result is 15 - which
indicates it's
not being treated as an UNSIGNED FIXED BIN(32).

Is this a doc error, or a compiler-error, or am I misunderstanding the
documentation?

- Thanks -
- Dave Rivers -



--
riv...@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

[John W Kennedy]

On 3/7/22 1:25 AM, Thomas David Rivers wrote:
> The IBM documentation for the ICLZ builtin says this:
>
>      If the argument x is of the type SIGNED FIXED BIN(p) with p <= 15,
> it is
>      converted to SIGNED FIXED BIN(31). If it is of the type UNSIGNED
> FIXED BIN(p)
>      with p <= 16, it is converted to UNSIGNED FIXED BIN(32).
>
> So, in this example; I expect the argument 'k' to be converted to an
> UNSIGNED FIXED BIN(32):
>
> test: proc options(main);
>
> dcl res fixed bin(31);
> dcl k unsigned fixed bin(16);
>
>  k = 1;
>  res = ICLZ(k);
>  display('RES is ' || res);
>
> end;
>
> And - thus, the result of the ICLZ on a value of X'1' with a 32-bit
> integer parameter would
> be 31.
>
> However, when you execute this program, the result is 15 - which
> indicates it's
> not being treated as an UNSIGNED FIXED BIN(32).
>
> Is this a doc error, or a compiler-error, or am I misunderstanding the
> documentation?

The documentation seems messy. For one thing, it does not allow for
64-bit numbers. Given that, I don’t trust it.


--
John W. Kennedy
Algernon Burbage, Lord Roderick, Father Martin, Bishop Baldwin,
King Pellinore, Captain Bailey, Merlin -- A Kingdom for a Stage!

[Peter Flass]

The documentation has been going downhill since PL/I(F). Newer features are
all poorly documented. The only way to find out how some things work is to
actually use them. In this particular case, though, if it’s not a bug
there’s a possibility that the implementation changed but the reference was
not updated to match.

--
Pete

[John W Kennedy]

I have often referred here to the old PL/I Language Specification (not
updated since 1968) as the only available answer to many corner cases.
Unfortunately, the ICLZ function is of too recent vintage.

And, unlike Ada, PL/I documentation rarely makes a clear distinction
between the declared type of a variable and the hardware type that
underlies it, and that seems to be in play here.

Ah well. Nowadays, I'm committed to Swift (and SwiftUI) anyway.

[Robin Vowels]

On Tuesday, March 8, 2022 at 12:12:24 PM UTC+11, Thomas David Rivers wrote:
> The IBM documentation for the ICLZ builtin says this:

.
You need to quote ALL the documentation, then we will know what you are
talking about.
.

> If the argument x is of the type SIGNED FIXED BIN(p) with p <= 15,
> it is
> converted to SIGNED FIXED BIN(31). If it is of the type UNSIGNED
> FIXED BIN(p)
> with p <= 16, it is converted to UNSIGNED FIXED BIN(32).
>
> So, in this example; I expect the argument 'k' to be converted to an
> UNSIGNED FIXED BIN(32):

.
So far, so good.
.

> test: proc options(main);
>
> dcl res fixed bin(31);
> dcl k unsigned fixed bin(16);
>
> k = 1;
> res = ICLZ(k);
> display('RES is ' || res);
>
> end;
>
> And - thus, the result of the ICLZ on a value of X'1'

You mean, 1, surely.
.

> with a 32-bit integer parameter would

.
You mean, with a 16-bit unsigned integer ARGUMENT,
which ICLZ converts to 32-bit unsigned integer value.
.
> be 31.
.
Yes, that's what should be expected.

.
> However, when you execute this program, the result is 15 - which
> indicates it's
> not being treated as an UNSIGNED FIXED BIN(32).

.
That appears to be the case.

.
> Is this a doc error, or a compiler-error, or am I misunderstanding the
> documentation?

.
Looks like a compiler error.

[Thomas David Rivers]

Robin Vowels wrote:

>On Tuesday, March 8, 2022 at 12:12:24 PM UTC+11, Thomas David Rivers wrote:
>
>

>>The IBM documentation for the ICLZ builtin says this:
>>
>>If the argument x is of the type SIGNED FIXED BIN(p) with p <= 15,
>>it is
>>converted to SIGNED FIXED BIN(31). If it is of the type UNSIGNED
>>FIXED BIN(p)
>>with p <= 16, it is converted to UNSIGNED FIXED BIN(32).
>>
>>So, in this example; I expect the argument 'k' to be converted to an
>>UNSIGNED FIXED BIN(32):
>>
>>test: proc options(main);
>>
>>dcl res fixed bin(31);
>>dcl k unsigned fixed bin(16);
>>
>>k = 1;
>>res = ICLZ(k);
>>display('RES is ' || res);
>>
>>end;
>>
>>And - thus, the result of the ICLZ on a value of X'1' with a 32-bit
>>integer parameter would be 31.
>>
>>

>.
>What? Why would it not be 1 ?

>.
>
>
>>However, when you execute this program, the result is 15 - which
>>indicates it's not being treated as an UNSIGNED FIXED BIN(32).
>>
>>

>.
>You haven't made it clear what you are doing.
>Your program should print the value 1.
>.
>
>
That is the entire program, and the output of the program is:

RES is 15

The ICLZ builtin function counts the number of leading zeros
in the underlying representation of the value; which depends on
the size of that representation.

The IBM documentation seems to, possibly, indicate that any value
represented by a datum smaller than a 4-byte integer is first converted
to a 4-byte
integer. Which means that the number of leading zeros in such a
representation
would be a value in the range 0 to 32 (although the count-leading-zeros
operation is
undefined for a zero value, and in some hardware, e.g. x86, returns
strange results,
so a careful program would check for a zero value, and the actual range
of the
count-leading-zeros operation should be considered to be 0 to 31.)

This program demonstrates that, contrary to the documentation, the compiler
is not converting the value to a 4-byte integer to determine the count
of leading zero bits
but is instead using the underlying represenation of the value, a 2-byte
integer.

In this case, an UNSIGNED FIXED BINARY value with a precision of 16 can
have an underlying representation of 2 bytes (16 bits.) A value of 1 would
then be in binary: 00000000 00000001 and thus have 15 leading zeros; hence
the result of 15.

Note that if the conversion to a FIXED BIN(31) had occured, as mentioned in
the documentation, the underlying representation would require 4 bytes
(32 bits) and
the result would be 31, not 15 (31 leading zero bits followed by a 1 bit.)

As to why one might wish to use the count-leading-zeros operation, I refer
you to the Wikipedia page that describes this and related operations and
their applications:

https://en.wikipedia.org/wiki/Find_first_set

As to the IBM documentation, the complete documentation on the ICLZ
builtin function can be found at the IBM web site, which you can arrive
at by
following this link:

https://www.ibm.com/docs/en/epfz/5.3?topic=subroutines-iclz

This is it, in its entirety (although re-formatted for posting):

ICLZ
Last Updated: 2021-09-08

ICLZ returns a FIXED BIN(31) value that indicates the number of
leading zeros in
a FIXED BIN value.

>>----- ICLZ( x ) ------ ><

x
Specifies a REAL FIXED BIN value with a scale factor of zero.

If the argument x is of the type SIGNED FIXED BIN(p) with p <= 15, it
is converted to
SIGNED FIXED BIN(31). If it is of the type UNSIGNED FIXED BIN(p) with
p <= 16, it is
converted to UNSIGNED FIXED BIN(32).

I did receive a reply from IBM regarding this, mentioning that they are
having
some difficulties responding to the thread. Their e-mail noted that the
documentation will be corrected to reflect the compiler's behavior.
So, this
is a documentation error.

I just wanted to answer Robin's questions, and put an end to this thread
for any future reader.

[Peter Flass]

Nope, sorry:-; Does this mean that ICLZ of a fixed bin(31) negative number
would return zero? I’m not familiar with these new-ish builtins. I stopped
using IBM PL/I at some relatively early level of Enterprise PL/I.

Kind of as an aside, I find the documentation for UNSIGNED data lacking in
general. I guess that with arithmetic and comparisons between signed and
unsigned data the unsigned is converted to signed, but this isn’t (or at
least wasn’t) spelled out. I think a while ago I ran some tests on this,
but I don’t have the results handy now.

--
Pete

[Robin Vowels]

On Wednesday, March 16, 2022 at 4:47:11 AM UTC+11, Thomas David Rivers wrote:
> Robin Vowels wrote:
>
> >On Tuesday, March 8, 2022 at 12:12:24 PM UTC+11, Thomas David Rivers wrote:
> >
> >
> >>The IBM documentation for the ICLZ builtin says this:
> >>
> >>If the argument x is of the type SIGNED FIXED BIN(p) with p <= 15,
> >>it is
> >>converted to SIGNED FIXED BIN(31). If it is of the type UNSIGNED
> >>FIXED BIN(p)
> >>with p <= 16, it is converted to UNSIGNED FIXED BIN(32).
> >>
> >>So, in this example; I expect the argument 'k' to be converted to an
> >>UNSIGNED FIXED BIN(32):
> >>
> >>test: proc options(main);
> >>
> >>dcl res fixed bin(31);
> >>dcl k unsigned fixed bin(16);
> >>
> >>k = 1;
> >>res = ICLZ(k);
> >>display('RES is ' || res);
> >>
> >>end;
> >>
> >>And - thus, the result of the ICLZ on a value of X'1' with a 32-bit
> >>integer parameter would be 31.

You have replied to a posting that I deleted on the 9th March.
It s now the 16th March.
Please read my subsequent post.

[Robin Vowels]

.
Check out the relationship between declarations and the storage
requirements. See the chapters, "Data Declarations" and "Limits".

[Robin Vowels]

On Wednesday, March 16, 2022 at 7:33:01 AM UTC+11, bearlyabus...@gmail.com wrote:

> Nope, sorry:-; Does this mean that ICLZ of a fixed bin(31) negative number
> would return zero?

.
It would raise SIZE and/or FIXEDOVERFLOW.

[John W Kennedy]

Why on Earth would it?

[Robin Vowels]

On Thursday, March 17, 2022 at 8:40:08 AM UTC+11, John W. Kennedy wrote:
> On 3/16/22 6:35 AM, Robin Vowels wrote:
> > On Wednesday, March 16, 2022 at 7:33:01 AM UTC+11, bearlyabus...@gmail.com wrote:
> >
> >> Nope, sorry:-; Does this mean that ICLZ of a fixed bin(31) negative number
> >> would return zero?
> > .
> > It would raise SIZE and/or FIXEDOVERFLOW.
.
> Why on Earth would it?

.
Because it's PL/I, not some mickey-mouse language like C or Fortran.
.
Does this satisfy you?
.
(FOFL, SIZE):
TEST: PROCEDURE OPTIONS (MAIN);
DECLARE US UNSIGNED FIXED BINARY (31);
DECLARE S FIXED BINARY (31) ;
S = -12345;
US = S;
PUT DATA (US);
END TEST;
.
OUTPUT:
.
IBM0342I ONCODE=0340 The SIZE condition was raised.
At offset +???????? in procedure with entry TEST

PL/I tells you when significant digits are lost.

[Peter Flass]

How about if US is precision (32)?

--
Pete

[Robin Vowels]

.
Why should that make any difference?

[Thomas David Rivers]

Peter Flass wrote:

>
>
>Nope, sorry:-; Does this mean that ICLZ of a fixed bin(31) negative number
>would return zero?
>
>

Yes - it would return 0 as there would be zero leading zero-bits in the
representation.

The count-leading-zeros operation is mostly used with unsigned values.

- Dave R. -

[Robin Vowels]

On Friday, March 18, 2022 at 6:31:51 AM UTC+11, bearlyabus...@gmail.com wrote:

.
Exactly the same result.

[Peter Flass]

OK, so converting ANY negative number to UNSIGNED will raise SIZE. Good to
know.

--
Pete

[John W Kennedy]

On 3/17/22 2:57 AM, Thomas David Rivers wrote:
> Peter Flass wrote:
>
>>
>>
>> Nope, sorry:-; Does this mean that ICLZ of a fixed bin(31) negative
>> number
>> would return zero?
>>
> Yes - it would return 0 as there would be zero leading zero-bits in the
> representation.
>
> The count-leading-zeros operation is mostly used with unsigned values.
>
>   - Dave R. -
>

To begin with, unlike many modern languages, PL/I doesn’t define BINARY
FIXED as 2’s complement (reasonably enough; IBM had not used
2’s-complement before), so ICLZ doesn’t have a defined value for a
negative input at all. It also isn’t defined for p>32 (UNSIGNED) or p>31
(SIGNED).

[Robin Vowels]

On Saturday, March 19, 2022 at 11:55:57 AM UTC+11, John W. Kennedy wrote:
> On 3/17/22 2:57 AM, Thomas David Rivers wrote:
> > Peter Flass wrote:
> >
> >>
> >>
> >> Nope, sorry:-; Does this mean that ICLZ of a fixed bin(31) negative
> >> number
> >> would return zero?
> >>
> > Yes - it would return 0 as there would be zero leading zero-bits in the
> > representation.
> >
> > The count-leading-zeros operation is mostly used with unsigned values.

.

> To begin with, unlike many modern languages, PL/I doesn’t define BINARY
> FIXED as 2’s complement (reasonably enough; IBM had not used
> 2’s-complement before),

.
Whether or not that is true, twos complement representation was
used from the year 1950 and earlier, and has been the most widely-used
for binary representation.

> so ICLZ doesn’t have a defined value for a
> negative input at all.

.
That doesn't follow; the value could be defined by negating the value
and then counting the leading zeros.

.
> It also isn’t defined for p>32 (UNSIGNED) or p>31
> (SIGNED).

.
There's no reason that it couldn't be defined when the argument
is 64 bits.

[Robin Vowels]

Supposedly someone had a use for this operation.
I could not find whether System z had a hardware instruction
for this task.
.
The CDC Cyber had a population count instruction
that counted the 1-bits in a binary word.
.
On DEUCE there was a need for such an operation,
though there was no such instruction.
.
However, the task was possible using the multiplier
as a shift register, and by simultaneously adding
the contents of the multiplier register to an accumulator.
(c. 1960)

[John W Kennedy]

On 3/19/22 3:08 AM, Robin Vowels wrote:
> Supposedly someone had a use for this operation.
> I could not find whether System z had a hardware instruction
> for this task.

It has, for at least ten years now: Find Leftmost One / FLOGR.
Hilariously, with regard to this discussion, it is defined only in terms
of 64-bit unsigned values.

The 1130 and 1800 had an instruction in the same area, designed for use
in postnormalization of software-implemented floating point: Shift Left
and Count.

> .
> The CDC Cyber had a population count instruction
> that counted the 1-bits in a binary word.
> .
> On DEUCE there was a need for such an operation,
> though there was no such instruction.
> .
> However, the task was possible using the multiplier
> as a shift register, and by simultaneously adding
> the contents of the multiplier register to an accumulator.
> (c. 1960)

[John W Kennedy]

On 3/19/22 12:15 AM, Robin Vowels wrote:
> On Saturday, March 19, 2022 at 11:55:57 AM UTC+11, John W. Kennedy wrote:
>> On 3/17/22 2:57 AM, Thomas David Rivers wrote:
>>> Peter Flass wrote:
>>>
>>>>
>>>>
>>>> Nope, sorry:-; Does this mean that ICLZ of a fixed bin(31) negative
>>>> number
>>>> would return zero?
>>>>
>>> Yes - it would return 0 as there would be zero leading zero-bits in the
>>> representation.
>>>
>>> The count-leading-zeros operation is mostly used with unsigned values.
> .
>> To begin with, unlike many modern languages, PL/I doesn’t define BINARY
>> FIXED as 2’s complement (reasonably enough; IBM had not used
>> 2’s-complement before),
> .
> Whether or not that is true, twos complement representation was
> used from the year 1950 and earlier, and has been the most widely-used
> for binary representation.

Not by IBM.

>> so ICLZ doesn’t have a defined value for a
>> negative input at all.
> .
> That doesn't follow; the value could be defined by negating the value
> and then counting the leading zeros.

“Could be defined” is the opposite of “defined”.

> .
>> It also isn’t defined for p>32 (UNSIGNED) or p>31
>> (SIGNED).
> .
> There's no reason that it couldn't be defined when the argument
> is 64 bits.

Again, what matters is that it /isn’t/ defined. This is what a
definition looks like: it’s the definition of the z/Architecture FLOGR
instruction:

FIND LEFTMOST ONE

FLOGR R1,R2 [RRE]
'B983' /////////// R1 R2
0---------15 16 - 23 24-27 28-31

Bits 0-63 of general register R2 are scanned left to right for the
leftmost one bit. A 64-bit binary integer designating the bit position
of the leftmost one bit, or 64 if there is no one bit, is placed in
general register R1. When a one bit is found in the second operand, the
original contents of general register R2, with the leftmost one bit set
to zero, are placed in general reg- ister R1 + 1. When a one bit is not
found, the contents of general register R1 + 1 are set to zeros.

The condition code indicates whether or not a one bit was found in the
second operand.

The R1 field designates an even-odd pair of general registers and must
designate an even-numbered register; otherwise, a specification
exception is recognized.

Resulting Condition Code:

0 No one bit found
1 --
2 One bit found
3 --

Program Exceptions:

• Operation (if the extended-immediate facility is not installed)

• Specification

Programming Notes:

1. An example of the use of the FIND LEFTMOST ONE instruction is given
in Appendix A, “Number Representation and Instruction-Use Examples.”

2. When the R1 and R2 fields designate the same register, the original
contents of general register R2 are replaced by the resulting
bit-position value, or 64 if no one bit was found.

3. When the R2 field designates general register R1 + 1, the leftmost
one bit (if any) of general register R2 is set to zero; if no one bit is
found, the entire register is set to zero.

4. When the R2 field designates neither the even nor the odd registers
designated by the R1 field, then general register R2 is not modified.

[Robin Vowels]

On Sunday, March 20, 2022 at 5:20:06 AM UTC+11, John W. Kennedy wrote:
> On 3/19/22 12:15 AM, Robin Vowels wrote:
> > On Saturday, March 19, 2022 at 11:55:57 AM UTC+11, John W. Kennedy wrote:
> >> On 3/17/22 2:57 AM, Thomas David Rivers wrote:
> >>> Peter Flass wrote:
> >>>
> >>>>
> >>>>
> >>>> Nope, sorry:-; Does this mean that ICLZ of a fixed bin(31) negative
> >>>> number
> >>>> would return zero?
> >>>>
> >>> Yes - it would return 0 as there would be zero leading zero-bits in the
> >>> representation.
> >>>
> >>> The count-leading-zeros operation is mostly used with unsigned values.
> > .
> >> To begin with, unlike many modern languages, PL/I doesn’t define BINARY
> >> FIXED as 2’s complement (reasonably enough; IBM had not used
> >> 2’s-complement before),
> > .
> > Whether or not that is true, twos complement representation was
> > used from the year 1950 and earlier, and has been the most widely-used
> > for binary representation.
>
> Not by IBM.

.
so what? I didn't say that it was.

.
> >> so ICLZ doesn’t have a defined value for a
> >> negative input at all.
> > .
> > That doesn't follow; the value could be defined by negating the value
> > and then counting the leading zeros.
.
> “Could be defined” is the opposite of “defined”.

What?

> >> It also isn’t defined for p>32 (UNSIGNED) or p>31 (SIGNED).
> > .
> > There's no reason that it couldn't be defined when the argument
> > is 64 bits.
> Again, what matters is that it /isn’t/ defined. This is what a
> definition looks like: it’s the definition of the z/Architecture FLOGR
> instruction:
>
> FIND LEFTMOST ONE

What's surprising is that the instruction has been available since at least 2008.

It is therefore even more surprising that ICLZ has not been defined for a 64-bit
operand. Really perverse.

[John W Kennedy]

On 3/19/22 9:44 PM, Robin Vowels wrote:
> On Sunday, March 20, 2022 at 5:20:06 AM UTC+11, John W. Kennedy wrote:
>> On 3/19/22 12:15 AM, Robin Vowels wrote:
>>> On Saturday, March 19, 2022 at 11:55:57 AM UTC+11, John W. Kennedy wrote:
>>>> On 3/17/22 2:57 AM, Thomas David Rivers wrote:
>>>>> Peter Flass wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> Nope, sorry:-; Does this mean that ICLZ of a fixed bin(31) negative
>>>>>> number
>>>>>> would return zero?
>>>>>>
>>>>> Yes - it would return 0 as there would be zero leading zero-bits in the
>>>>> representation.
>>>>>
>>>>> The count-leading-zeros operation is mostly used with unsigned values.
>>> .
>>>> To begin with, unlike many modern languages, PL/I doesn’t define BINARY
>>>> FIXED as 2’s complement (reasonably enough; IBM had not used
>>>> 2’s-complement before),
>>> .
>>> Whether or not that is true, twos complement representation was
>>> used from the year 1950 and earlier, and has been the most widely-used
>>> for binary representation.
>>
>> Not by IBM.
> .
> so what? I didn't say that it was.

But I was talking about why is is unsurprising that IBM did not define
PL/I as using 2's-complement, as the designers of (say) Java and Swift
did. (But consider that the designers of Ada did not. In fact they had
to insert an ad-hoc clause /allowing/ 2's-complement.) To IBM and its
customers in the early 60s, 2's-complement was an exotic and daring
experiment.

> .
>>>> so ICLZ doesn’t have a defined value for a
>>>> negative input at all.
>>> .
>>> That doesn't follow; the value could be defined by negating the value
>>> and then counting the leading zeros.
> .
>> “Could be defined” is the opposite of “defined”.
>
> What?

That which “could be defined” is, by definition, something that has not
yet been defined.

>>>> It also isn’t defined for p>32 (UNSIGNED) or p>31 (SIGNED).
>>> .
>>> There's no reason that it couldn't be defined when the argument
>>> is 64 bits.
>> Again, what matters is that it /isn’t/ defined. This is what a
>> definition looks like: it’s the definition of the z/Architecture FLOGR
>> instruction:
>>
>> FIND LEFTMOST ONE
>
> What's surprising is that the instruction has been available since at least 2008.
>
> It is therefore even more surprising that ICLZ has not been defined for a 64-bit
> operand. Really perverse.

My ultimate point in all of this.

[Robin Vowels]

On Monday, March 21, 2022 at 8:23:00 AM UTC+11, John W. Kennedy wrote:

> But I was talking about why is is unsurprising that IBM did not define
> PL/I as using 2's-complement, as the designers of (say) Java and Swift
> did. (But consider that the designers of Ada did not. In fact they had
> to insert an ad-hoc clause /allowing/ 2's-complement.) To IBM and its
> customers in the early 60s, 2's-complement was an exotic and daring
> experiment.
.

Not to us. At our site, twos complement equipment had been used
for 10 years before S/360.

And twos complement was not an "experiment". It was used on
Pilot ACE (1951), etc

[John W Kennedy]

And so? If the National Physical Laboratory had had any major input in
the language eventually to be known as PL/I, there wouldn’t have been
the embarrassing public kerfuffle over the name.

[Robin Vowels]

On Sunday, March 27, 2022 at 11:19:01 AM UTC+11, John W. Kennedy wrote:
> On 3/26/22 12:33 AM, Robin Vowels wrote:
> > On Monday, March 21, 2022 at 8:23:00 AM UTC+11, John W. Kennedy wrote:
> >
> >> But I was talking about why is is unsurprising that IBM did not define
> >> PL/I as using 2's-complement, as the designers of (say) Java and Swift
> >> did. (But consider that the designers of Ada did not. In fact they had
> >> to insert an ad-hoc clause /allowing/ 2's-complement.) To IBM and its
> >> customers in the early 60s, 2's-complement was an exotic and daring
> >> experiment.
> > .
> > Not to us. At our site, twos complement equipment had been used
> > for 10 years before S/360.
> >
> > And twos complement was not an "experiment". It was used on
> > Pilot ACE (1951), etc

> And so? If the National Physical Laboratory

How is this relevant?

> had had any major input in the language

The NPL was not into language design. It was into
numerical work and construction of computers.

> eventually to be known as PL/I, there wouldn’t have been
> the embarrassing public kerfuffle over the name.

How is this relevant?

The choice of name was the sole prerogative of IBM.

[John W Kennedy]

On 3/26/22 10:21 PM, Robin Vowels wrote:
> On Sunday, March 27, 2022 at 11:19:01 AM UTC+11, John W. Kennedy wrote:
>> On 3/26/22 12:33 AM, Robin Vowels wrote:
>>> On Monday, March 21, 2022 at 8:23:00 AM UTC+11, John W. Kennedy wrote:
>>>
>>>> But I was talking about why is is unsurprising that IBM did not define
>>>> PL/I as using 2's-complement, as the designers of (say) Java and Swift
>>>> did. (But consider that the designers of Ada did not. In fact they had
>>>> to insert an ad-hoc clause /allowing/ 2's-complement.) To IBM and its
>>>> customers in the early 60s, 2's-complement was an exotic and daring
>>>> experiment.
>>> .
>>> Not to us. At our site, twos complement equipment had been used
>>> for 10 years before S/360.
>>>
>>> And twos complement was not an "experiment". It was used on
>>> Pilot ACE (1951), etc
>
>> And so? If the National Physical Laboratory
>
> How is this relevant?

NPL built the Pilot ACE.

>> had had any major input in the language
>
> The NPL was not into language design. It was into
> numerical work and construction of computers.

I didn’t say they were.

>> eventually to be known as PL/I, there wouldn’t have been
>> the embarrassing public kerfuffle over the name.
>
> How is this relevant?
>
> The choice of name was the sole prerogative of IBM.

Which was my point:

2's-complement was new to the IBM world in the 360. Therefore, it would
have been bizarre if IBM had specified that PL/I required
2's-complement, although some new languages, created long after PL/I, do.

[Robin Vowels]

On Tuesday, March 8, 2022 at 12:12:24 PM UTC+11, Thomas David Rivers wrote:
> The IBM documentation for the ICLZ builtin says this:
>
> If the argument x is of the type SIGNED FIXED BIN(p) with p <= 15,
> it is
> converted to SIGNED FIXED BIN(31). If it is of the type UNSIGNED
> FIXED BIN(p)
> with p <= 16, it is converted to UNSIGNED FIXED BIN(32).
>
> So, in this example; I expect the argument 'k' to be converted to an
> UNSIGNED FIXED BIN(32):
>
> test: proc options(main);
>
> dcl res fixed bin(31);
> dcl k unsigned fixed bin(16);
>
> k = 1;
> res = ICLZ(k);
> display('RES is ' || res);
>
> end;
>
> And - thus, the result of the ICLZ on a value of X'1' with a 32-bit
> integer parameter would
> be 31.
>
> However, when you execute this program, the result is 15 - which
> indicates it's
> not being treated as an UNSIGNED FIXED BIN(32).
>
> Is this a doc error, or a compiler-error, or am I misunderstanding the
> documentation?

.
The specification of ICLZ was changed in May 2022.
Does it now do what you expect from the documentation in the LRM?