> Intuitive is in the mind of the beholder, and in my mind, if you
> want to shift right, you should say so.

I was thinking of a language where you might want to allow use of the
shift operator not just on fixed size integers, but also on things like
bignums and arbitrary size fractional numbers.
For fractional number you'd have nice properties like
`(a << b) >> c == a << (b - c)`.

Stefan

On 11/01/2022 02:42, Quadibloc wrote:
> On Monday, January 10, 2022 at 2:31:20 PM UTC-7, MitchAlsup wrote:
>> On Monday, January 10, 2022 at 3:03:39 PM UTC-6, John Levine wrote:
>
>>> I'd rather say that shifts are only defined for values between zero
>>> and the word size, which excludes all negative values.
>
>> AND THUS: the right side operand SHOULD be unsigned !!!
>
> That does not follow. While C does have an unsigned integer type,
> many languages see no need to bother with such a thing, and for
> functions and operators to admit of a DOMAIN ERROR condition
> when used improperly is nothing strange.
>

If a language has a way to express a type that is strictly in the range
0 .. 32 (for 32-bit integers - with obvious changes for other sizes),
then the right hand operand should arguably be of that type. If not,
then any superset is equally good or bad. There's no advantage to
requiring an unsigned type here - it still has values outside of the
range just like signed integer types.

In C, a shift of the word size is not valid. "u << n" for a 32-bit
unsigned int "u" is only defined for n from 0 to 31 inclusive. This
catches people out sometimes, as it seems obvious that "u << 32" should
be defined as 0. The operation is undefined as on some cpus, if the
right hand operand is in a register it is effectively masked by 0x1f
before the shift - thus "u << 32" would give "u". Supporting shifts by
the full bit-width of the left hand operand could easily require quite
inefficient code.

(I'm not saying C's interpretation here is the only sensible choice, I'm
merely saying what it does.)

John Levine wrote:
> According to Stefan Monnier <monnier@iro.umontreal.ca>:
>>> So, what does (13 << -7) mean ?
>>
>> I suspect everyone in this group knows what the above means in
>> C according to the C standard, but if you're asking what we think it
>> should mean instead (either in C or in other languages), then my answer
>> is that it should mean the same as (13 >> 7) because it's the most
>> intuitive behavior, and the cleanest semantics.
>
> Intuitive is in the mind of the beholder, and in my mind, if you
> want to shift right, you should say so.
>
> I'd rather say that shifts are only defined for values between zero
> and the word size, which excludes all negative values.
>
> What's the result of (13 << N) where N is an argument that might
> have a negative value? On computers that treat a variable shift
> argument as an unsigned number (all of them these days) does the
> computer have to generate code to test the sign of N and so forth?
>
> The VAX designers outsmarted themselves (not the only time) when
> they had one shift instruction with a signed argument rather than
> separate left and right shifts. I can't think of a time I've
> done shifting and didn't know when I wrote the code which direction
> I wanted to shift, even if the number of shifts was variable.

I have in fact been here a few times (2 or 3?), i.e. when writing codec
code: It would have been natural to shift either direction, but I was
usually able to bias the values in such a way that the negative shifts
went away.

There might have been one remaining case where I fell back to shifting
twice, once in each direction?

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

EricP wrote:
> John Levine wrote:
>> According to Stefan Monnier  <monnier@iro.umontreal.ca>:
>>>> So, what does (13 << -7) mean ?
>>> I suspect everyone in this group knows what the above means in
>>> C according to the C standard, but if you're asking what we think it
>>> should mean instead (either in C or in other languages), then my answer
>>> is that it should mean the same as (13 >> 7) because it's the most
>>> intuitive behavior, and the cleanest semantics.
>>
>> Intuitive is in the mind of the beholder, and in my mind, if you
>> want to shift right, you should say so.
>>
>> I'd rather say that shifts are only defined for values between zero
>> and the word size, which excludes all negative values.
>>
>> What's the result of (13 << N) where N is an argument that might
>> have a negative value?  On computers that treat a variable shift
>> argument as an unsigned number (all of them these days) does the
>> computer have to generate code to test the sign of N and so forth?
>
> It could have both left and right shift instructions
> where a positive count is in the instructions' direction,
> and a negative count is the reverse direction for both.
> Symmetry!
>
> Now question #2: what does it mean when N >= data operand bit-size?

That used to be "return zero" (or all sign bits for an arithmetic shift
right), and Intel started out that way on the 8086:

shl ax,cl

would perform the shift as many time as CL specified, so 0..255 times,
but any value 16 or above woud give the same zero result in AX.

Then on the 286 (or maybe even the 186?) they optimized this by only
allowing shifts from 0 to 31 bits, so it was still possible to zero out
the target reg by having CL = 16..31, and you could usefully do a
double-wide shift like SHRD which combines two registers and shift them
together.

There were two big problems with this approach:

a) The shift count was truncated with a mask, i.e. bottom 5 bits,
instead of a compare, so a shift of exactly 32 bits would now be treated
as a NOP.

b) When the 386 came around, the C standard had already allowed shift
amounts to be limited to reg_size - 1, so Intel saw no need to extend
the shift mask to 6 bits which would have been logical.

There were a bunch of other cpus being developed around the same
timeframe, in a race to the bottom the cheapest approach have won:
Extract 5 or 6 bits from the shift count, discarding the rest.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

EricP <ThatWouldBeTelling@thevillage.com> writes:
>Now question #2: what does it mean when N >= data operand bit-size?

0

But again, I have not actually found the deviation of existing
architectures to be a problem in practice.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Terje Mathisen <terje.mathisen@tmsw.no> writes:
>b) When the 386 came around, the C standard had already allowed shift
>amounts to be limited to reg_size - 1, so Intel saw no need to extend
>the shift mask to 6 bits which would have been logical.
>
>There were a bunch of other cpus being developed around the same
>timeframe, in a race to the bottom the cheapest approach have won:
>Extract 5 or 6 bits from the shift count, discarding the rest.

The CPUs around the time were including a barrel shifter for
single-cycle shifts (which consumed quite a bit of chip area). On
these shifters this behaviour is natural: bit 0 of the shift count
controls one MUX, bit 1 another MUX, and so on, up to bit 4 (for
32-bit shifters). No extraction and discarding happens. If you want
to implement a result 0 for shift amounts >31, you need to nor bit
5..31 of the shift count and "and" the result of the barrel shifter
with that. This adds one gate level to the shift operation.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Quadibloc <jsavard@ecn.ab.ca> writes:

> On Monday, January 10, 2022 at 2:03:39 PM UTC-7, John Levine wrote:
>
>> The VAX designers outsmarted themselves (not the only time) when
>> they had one shift instruction with a signed argument rather than
>> separate left and right shifts.
>
> I'll definitely agree that this is a very unusual instruction. However
> nice it might seem to have such an instruction, and to define the
> << and >> operators in the way it makes feasible, in the real world
> this isn't needed, as you say.
>
> In fact, while I would not have been surprised to hear that the
> PDP-10 had such a shift instruction, I'm rather amazed that
> this was done with the VAX.

With its extreme orthoganility goal? It would be a bigger surprise if
it didn't do it that way.

Quadibloc wrote:
> On Monday, January 10, 2022 at 2:03:39 PM UTC-7, John Levine wrote:
>
>> The VAX designers outsmarted themselves (not the only time) when
>> they had one shift instruction with a signed argument rather than
>> separate left and right shifts.
>
> I'll definitely agree that this is a very unusual instruction. However
> nice it might seem to have such an instruction, and to define the
> << and >> operators in the way it makes feasible, in the real world
> this isn't needed, as you say.
>
> In fact, while I would not have been surprised to hear that the
> PDP-10 had such a shift instruction, I'm rather amazed that
> this was done with the VAX.
>
> John Savard

The PDP-11 ASH instruction operates on 16-bit word operands and
ASHC Arithmetic Shift Combined operates on a 32-bit register pair
as VAX ASHL does for a 32-bit longword and ASHQ a 64-bit quadword.
In all cases +ve count was left, -ve was right.

The PDP-11 also has ASL Arithmetic Shift Left and ASR for right
but they only shift 1 place.

Also VAX had PDP-11 instruction execution mode.
They were clearly aiming for PDP-11 assembler compatibility.

On Tuesday, January 11, 2022 at 6:48:33 AM UTC-6, Anton Ertl wrote:
> Terje Mathisen <terje.m...@tmsw.no> writes:
> >b) When the 386 came around, the C standard had already allowed shift
> >amounts to be limited to reg_size - 1, so Intel saw no need to extend
> >the shift mask to 6 bits which would have been logical.
<
This comes tantalizingly close to stating that everyone should simply follow Intel.
<
> >
> >There were a bunch of other cpus being developed around the same
> >timeframe, in a race to the bottom the cheapest approach have won:
> >Extract 5 or 6 bits from the shift count, discarding the rest.
<
Do you not think that, for a modern ISA, one CAN take a better position?
<
> The CPUs around the time were including a barrel shifter for
> single-cycle shifts (which consumed quite a bit of chip area). On
> these shifters this behaviour is natural: bit 0 of the shift count
> controls one MUX, bit 1 another MUX, and so on, up to bit 4 (for
> 32-bit shifters).
<
You are describing the IBM log-shifter which pretty much supplanted barrel
shifters on processes with more than 2 metal layers.
<
> No extraction and discarding happens. If you want
> to implement a result 0 for shift amounts >31, you need to nor bit
> 5..31 of the shift count and "and" the result of the barrel shifter
> with that. This adds one gate level to the shift operation.
<
One can do anything with a log-shifter as one can do with a barrel shifter
and with approximately equal added cost. The log=-shifter cost is less
than a barrel shifter cost.
<
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

According to Joe Pfeiffer <pfeiffer@cs.nmsu.edu>:
>> In fact, while I would not have been surprised to hear that the
>> PDP-10 had such a shift instruction, I'm rather amazed that
>> this was done with the VAX.
>
>With its extreme orthoganility goal? It would be a bigger surprise if
>it didn't do it that way.

Indeed it did, LSH and LSHC for one- and two-word logical shifts,
ASH and ASHC for arithmetic shifts, and ROT and ROTC for rotates,
with the address taken as a signed 9-bit number.

ASHC right shifts treated the two words as two signed numbers, so the sign
of the low word copied the sign of the high word and bits shifted out of
the bottom of the high word were shifted into the second bit of the low
word and v/v. I don't think that turned out to be very useful

Of course, we're talking about an architecture designed in 1963. Perhaps
the tradeoffs in computer design have changed since then.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

According to Ivan Godard <ivan@millcomputing.com>:
>> The VAX designers outsmarted themselves (not the only time) when
>> they had one shift instruction with a signed argument ...

>Perhaps VAX followed the semantics of ADD? After all, 13 + -7 is 6, not
>some very large number - so there is really no reason for SUB to be in
>the ISA.

Well, sure, the PDP-8 didn't have a subtract instruction either. But I don't think
minimizing the number of instructions in the ISA is a big deal, it's a tradeoff between
implementation complexity and instruction count. VAX went way in the direction of
complex microcoded implementation which even at the time should have been seen as
a dead end.

S/360 had separate left and right shifts and it seems to have worn pretty well.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Tuesday, January 11, 2022 at 12:47:03 PM UTC-6, John Levine wrote:
> According to Joe Pfeiffer <pfei...@cs.nmsu.edu>:
> >> In fact, while I would not have been surprised to hear that the
> >> PDP-10 had such a shift instruction, I'm rather amazed that
> >> this was done with the VAX.
> >
> >With its extreme orthoganility goal? It would be a bigger surprise if
> >it didn't do it that way.
> Indeed it did, LSH and LSHC for one- and two-word logical shifts,
> ASH and ASHC for arithmetic shifts, and ROT and ROTC for rotates,
> with the address taken as a signed 9-bit number.
<
9-bits ?
32-bits (1 registers) is 5-bits 6-bits when signed
64-bits (2 registers) is 6-bits 7-bits when signed
And the VAX immediates supported 8-bit as the small size.
<
Why 9-bits ?
<
>
> ASHC right shifts treated the two words as two signed numbers, so the sign
> of the low word copied the sign of the high word and bits shifted out of
> the bottom of the high word were shifted into the second bit of the low
> word and v/v. I don't think that turned out to be very useful
>
> Of course, we're talking about an architecture designed in 1963. Perhaps
> the tradeoffs in computer design have changed since then.
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

According to MitchAlsup <MitchAlsup@aol.com>:
>> ASH and ASHC for arithmetic shifts, and ROT and ROTC for rotates,
>> with the address taken as a signed 9-bit number.
><
>9-bits ?

Yeah, the high bit of the 18-bit address was the sign, the low
8 bits the value, all treated as two-s complement number,

>64-bits (2 registers) is 6-bits 7-bits when signed
>Why 9-bits ?

The PDP-10 was 36 bits so a two-word value was 72 bits.

Dunno why it was 9 bits rather than 8 and I am pretty sure
everyone who knew has died. As likely as not it was some
quirk of the way the PDP-6 was implemented.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On 1/11/2022 12:32 PM, John Levine wrote:
> According to MitchAlsup <MitchAlsup@aol.com>:
>>> ASH and ASHC for arithmetic shifts, and ROT and ROTC for rotates,
>>> with the address taken as a signed 9-bit number.
>> <
>> 9-bits ?
>
> Yeah, the high bit of the 18-bit address was the sign, the low
> 8 bits the value, all treated as two-s complement number,
>
>> 64-bits (2 registers) is 6-bits 7-bits when signed
>> Why 9-bits ?
>
> The PDP-10 was 36 bits so a two-word value was 72 bits.
>
> Dunno why it was 9 bits rather than 8 and I am pretty sure
> everyone who knew has died. As likely as not it was some
> quirk of the way the PDP-6 was implemented.
>
>
>

Character addressing on a 36-bit machine: 4x9=36. Earliest had 6-bit
chars but that was already understood as wrong.

MitchAlsup wrote:
> On Tuesday, January 11, 2022 at 6:48:33 AM UTC-6, Anton Ertl wrote:
>> Terje Mathisen <terje.m...@tmsw.no> writes:
>>> b) When the 386 came around, the C standard had already allowed shift
>>> amounts to be limited to reg_size - 1, so Intel saw no need to extend
>>> the shift mask to 6 bits which would have been logical.
> <
> This comes tantalizingly close to stating that everyone should simply follow Intel.

Rather the opposite: I am trying to explain, not excuse the current
situation. :-(

> <
>>>
>>> There were a bunch of other cpus being developed around the same
>>> timeframe, in a race to the bottom the cheapest approach have won:
>>> Extract 5 or 6 bits from the shift count, discarding the rest.
> <
> Do you not think that, for a modern ISA, one CAN take a better position?

Yes, please!

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On Mi 12 Jan 2022 at 09:15, Terje Mathisen <terje.mathisen@tmsw.no> wrote:

> Rather the opposite: I am trying to explain, not excuse the current
> situation. :-(

I've come yo bury Caesar, not to praise him!

'Andreas

On 2022-01-10, Quadibloc wrote:
> On Saturday, January 8, 2022 at 6:16:14 PM UTC-7, MitchAlsup wrote:
>
>> So, what does (13 << -7) mean ?
>
> From the replies, I see that this is a completely different
> can of worms. I would tend to favor the VAX interpretation,
> but it's unclear to me that it would be worth the extra
> run-time overhead that it might imply.

Yeah, I once considered that interpretation for MRISC32, but then
discovered that there are a lot of cases that need to be handled
(sign, left-shift overflow, right-shift overflow with/without sign),
plus you need to consider the full value range (32/64 bits) as opposed
to just the LSB:s (5/6 bits). And then there are legitimate use cases
for "the other" interpretation (masking out the 5/6 LSB:s), too.

In the end it made sense to go with the simplest solution since that is
what compilers are used to dealing with, and C programmers can not rely
on the behavior either way.

>
> John Savard
>

On Monday, January 10, 2022 at 11:36:01 AM UTC-6, Quadibloc wrote:
> On Saturday, January 8, 2022 at 6:16:14 PM UTC-7, MitchAlsup wrote:
>
> > So, what does (13 << -7) mean ?
> From the replies, I see that this is a completely different
> can of worms. I would tend to favor the VAX interpretation,
> but it's unclear to me that it would be worth the extra
> run-time overhead that it might imply.
<
The VAX interpretation does not allow for shifts to be used as
bit-manipulation instructions (extract signed and unsigned).
>
> John Savard

On 1/12/2022 1:24 PM, MitchAlsup wrote:
> On Monday, January 10, 2022 at 11:36:01 AM UTC-6, Quadibloc wrote:
>> On Saturday, January 8, 2022 at 6:16:14 PM UTC-7, MitchAlsup wrote:
>>
>>> So, what does (13 << -7) mean ?
>> From the replies, I see that this is a completely different
>> can of worms. I would tend to favor the VAX interpretation,
>> but it's unclear to me that it would be worth the extra
>> run-time overhead that it might imply.
> <
> The VAX interpretation does not allow for shifts to be used as
> bit-manipulation instructions (extract signed and unsigned).

That turns into a rotate and a shft right. But isn't that what a
hardware EXTR is going to do anyway?

On Wednesday, January 12, 2022 at 4:24:36 PM UTC-6, Ivan Godard wrote:
> On 1/12/2022 1:24 PM, MitchAlsup wrote:
> > On Monday, January 10, 2022 at 11:36:01 AM UTC-6, Quadibloc wrote:
> >> On Saturday, January 8, 2022 at 6:16:14 PM UTC-7, MitchAlsup wrote:
> >>
> >>> So, what does (13 << -7) mean ?
> >> From the replies, I see that this is a completely different
> >> can of worms. I would tend to favor the VAX interpretation,
> >> but it's unclear to me that it would be worth the extra
> >> run-time overhead that it might imply.
> > <
> > The VAX interpretation does not allow for shifts to be used as
> > bit-manipulation instructions (extract signed and unsigned).
<
> That turns into a rotate and a shft right. But isn't that what a
> hardware EXTR is going to do anyway?
<
Technically an extract is:
<
r = ((c << (containerWidth - fieldWidth - offset)) >> (containerWidth-fieldWidth));
<
However, what we do in HW is:
<
m = tableM[fieldWidth]; // mask m:: often done with table
s = ~0u << (fieldWidth+offset); // sign extension bits :: often done with table
t = (c >> offset) & m | ( signed || (c & ( 1 << (fieldWidth+offset)) ? s : 0);
<
as this uses 1 shifter and either tables or greater-than decoders.
<
But the part I was hinting at is that we have a large container for this shift
count and we need only a few bits on one end. So, in My 66000, the upper ½
of the container is allowed to contain a value 0..64 (where both 0 and 64
mean 64-bit field width).
<
Done this way, shifts are degenerate subsets of EXT.
<
If you use the sign bit<63> to control shift direction, you probably should not
be using bits<37:32> as the field width because pasting the fieldWidth into
such a container is simply harder.
<
I learned the hard way about placing both containers too close together
in the Mc 88100.

According to MitchAlsup <MitchAlsup@aol.com>:
>On Monday, January 10, 2022 at 11:36:01 AM UTC-6, Quadibloc wrote:
>> On Saturday, January 8, 2022 at 6:16:14 PM UTC-7, MitchAlsup wrote:
>>
>> > So, what does (13 << -7) mean ?
>> From the replies, I see that this is a completely different
>> can of worms. I would tend to favor the VAX interpretation,
>> but it's unclear to me that it would be worth the extra
>> run-time overhead that it might imply.
><
>The VAX interpretation does not allow for shifts to be used as
>bit-manipulation instructions (extract signed and unsigned).

Why would you care, since it had bit aligned extract, insert, and
compare instructions, that took a base address, size, and bit offset
as separate operands.

Dunno if compilers ever generated them.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Wednesday, January 12, 2022 at 6:27:03 PM UTC-6, John Levine wrote:
> According to MitchAlsup <Mitch...@aol.com>:
> >On Monday, January 10, 2022 at 11:36:01 AM UTC-6, Quadibloc wrote:
> >> On Saturday, January 8, 2022 at 6:16:14 PM UTC-7, MitchAlsup wrote:
> >>
> >> > So, what does (13 << -7) mean ?
> >> From the replies, I see that this is a completely different
> >> can of worms. I would tend to favor the VAX interpretation,
> >> but it's unclear to me that it would be worth the extra
> >> run-time overhead that it might imply.
> ><
> >The VAX interpretation does not allow for shifts to be used as
> >bit-manipulation instructions (extract signed and unsigned).
<
> Why would you care, since it had bit aligned extract, insert, and
> compare instructions, that took a base address, size, and bit offset
> as separate operands.
<
Conservation of instruction count in my own designs.
>
> Dunno if compilers ever generated them.
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

It appears that Ivan Godard <ivan@millcomputing.com> said:
>> [ why the PDP-6 used a 9 bit shift count ]
>>> 64-bits (2 registers) is 6-bits 7-bits when signed
>>> Why 9-bits ?
>>
>> The PDP-10 was 36 bits so a two-word value was 72 bits.
>>
>> Dunno why it was 9 bits rather than 8 and I am pretty sure
>> everyone who knew has died. As likely as not it was some
>> quirk of the way the PDP-6 was implemented.
>
>Character addressing on a 36-bit machine: 4x9=36. Earliest had 6-bit
>chars but that was already understood as wrong.

That's not how the PDP-6 worked. The only addresses were word addresses.
It had a full set of halfword instructions but which halfword was encoded
in the instruction, e.g. HLRZ halfword left to right and zero the other
half, which did a Lisp CDR.

For byte handling, it had byte pointers with the six bit byte size and
bit offset fields at the top of the pointer word, and the rest was the
word address with optional and little used indirect and index fields.
LDB and DBP loaded or deposited a byte from a register into the byte
the pointer pointed to, IBP incremented a pointer to the next byte, in
the next word if need be, and ILDB and IDBP incremented and then
loaded or stored. Any byte size from 1 bit to 36 worked equally well.

In practice text files were stored as 7-bit ASCII, 5 characters to the
word, null characters allowed for padding and ignored. The low bit was
a flag that the five characters were a decimal line number not
logically part of the line.

Later versions of the DEC-20 added microcoded string operations but the
pointer format was the same.

So anyway, nine bits? Naah.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On 1/12/2022 2:46 PM, MitchAlsup wrote:
> On Wednesday, January 12, 2022 at 4:24:36 PM UTC-6, Ivan Godard wrote:
>> On 1/12/2022 1:24 PM, MitchAlsup wrote:
>>> On Monday, January 10, 2022 at 11:36:01 AM UTC-6, Quadibloc wrote:
>>>> On Saturday, January 8, 2022 at 6:16:14 PM UTC-7, MitchAlsup wrote:
>>>>
>>>>> So, what does (13 << -7) mean ?
>>>> From the replies, I see that this is a completely different
>>>> can of worms. I would tend to favor the VAX interpretation,
>>>> but it's unclear to me that it would be worth the extra
>>>> run-time overhead that it might imply.
>>> <
>>> The VAX interpretation does not allow for shifts to be used as
>>> bit-manipulation instructions (extract signed and unsigned).
> <
>> That turns into a rotate and a shft right. But isn't that what a
>> hardware EXTR is going to do anyway?
> <
> Technically an extract is:
> <
> r = ((c << (containerWidth - fieldWidth - offset)) >> (containerWidth-fieldWidth));
> <
> However, what we do in HW is:
> <
> m = tableM[fieldWidth]; // mask m:: often done with table
> s = ~0u << (fieldWidth+offset); // sign extension bits :: often done with table
> t = (c >> offset) & m | ( signed || (c & ( 1 << (fieldWidth+offset)) ? s : 0);
> <
> as this uses 1 shifter and either tables or greater-than decoders.
> <
> But the part I was hinting at is that we have a large container for this shift
> count and we need only a few bits on one end. So, in My 66000, the upper ½
> of the container is allowed to contain a value 0..64 (where both 0 and 64
> mean 64-bit field width).
> <
> Done this way, shifts are degenerate subsets of EXT.
> <
> If you use the sign bit<63> to control shift direction, you probably should not
> be using bits<37:32> as the field width because pasting the fieldWidth into
> such a container is simply harder.
> <
> I learned the hard way about placing both containers too close together
> in the Mc 88100.

Hmm. So the container is a field descriptor. But it's not actually a
bitRow, because it can't cross word boundaries - more like a PDP-10 PLT
IIRC. Gives you some encoding entropy, but not actually any new
semantic, and you have to build the descriptor, which you avoid when
offset and width are separate arguments.

Where ISAs really fall down is parsing a bit stream: grab a dynamic
number of bits off the front of a bit stream, advancing the stream; word
boundaries are not significant. The problem is that HW provides word
streams (loop/load) and mapping that to a bit stream is nasty. The logic
is the same as mapping a line stream into a (VL) instruction stream in
the decoder's instruction buffer, but how to represent that in an ISA?

Ivan Godard wrote:
> On 1/12/2022 2:46 PM, MitchAlsup wrote:
>> On Wednesday, January 12, 2022 at 4:24:36 PM UTC-6, Ivan Godard wrote:
>>> On 1/12/2022 1:24 PM, MitchAlsup wrote:
>>>> On Monday, January 10, 2022 at 11:36:01 AM UTC-6, Quadibloc wrote:
>>>>> On Saturday, January 8, 2022 at 6:16:14 PM UTC-7, MitchAlsup wrote:
>>>>>
>>>>>> So, what does (13 << -7) mean ?
>>>>>  From the replies, I see that this is a completely different
>>>>> can of worms. I would tend to favor the VAX interpretation,
>>>>> but it's unclear to me that it would be worth the extra
>>>>> run-time overhead that it might imply.
>>>> <
>>>> The VAX interpretation does not allow for shifts to be used as
>>>> bit-manipulation instructions (extract signed and unsigned).
>> <
>>> That turns into a rotate and a shft right. But isn't that what a
>>> hardware EXTR is going to do anyway?
>> <
>> Technically an extract is:
>> <
>>         r = ((c << (containerWidth - fieldWidth - offset)) >>
>> (containerWidth-fieldWidth));
>> <
>> However, what we do in HW is:
>> <
>>         m = tableM[fieldWidth];              // mask m:: often done
>> with table
>>         s = ~0u << (fieldWidth+offset); // sign extension bits ::
>> often done with table
>>         t = (c >> offset) & m | ( signed || (c & ( 1 <<
>> (fieldWidth+offset)) ? s : 0);
>> <
>> as this uses 1 shifter and either tables or greater-than decoders.
>> <
>> But the part I was hinting at is that we have a large container for
>> this shift
>> count and we need only a few bits on one end. So, in My 66000, the
>> upper ½
>> of the container is allowed to contain a value 0..64 (where both 0 and 64
>> mean 64-bit field width).
>> <
>> Done this way, shifts are degenerate subsets of EXT.
>> <
>> If you use the sign bit<63> to control shift direction, you probably
>> should not
>> be using bits<37:32> as the field width because pasting the fieldWidth
>> into
>> such a container is simply harder.
>> <
>> I learned the hard way about placing both containers too close together
>> in the Mc 88100.
>
> Hmm. So the container is a field descriptor. But it's not actually a
> bitRow, because it can't cross word boundaries - more like a PDP-10 PLT
> IIRC. Gives you some encoding entropy, but not actually any new
> semantic, and you have to build the descriptor, which you avoid when
> offset and width are separate arguments.
>
> Where ISAs really fall down is parsing a bit stream: grab a dynamic
> number of bits off the front of a bit stream, advancing the stream; word
> boundaries are not significant. The problem is that HW provides word
> streams (loop/load) and mapping that to a bit stream is nasty. The logic
> is the same as mapping a line stream into a (VL) instruction stream in
> the decoder's instruction buffer, but how to represent that in an ISA?

We did use to have something like that back in the PDP days with the
variable-sized load byte opcode that would automatically step forward to
the next work if needed.

Today we would need a separate hw mechanism for that bitstream buffer,
and probably a filling mechanism which either would need to be
hardware-only or possibly a FILL_IF_ROOM target,offs,[src] opcode that
would load the next (8/16/32 bits into the target register at offs bit
offset, updating the OFFS reg and SRC pointer, but only if there was
room, otherwise it is a NOP. The main problem is the need to update all
three register operands. :-(

Having it would however make it far easier to handle arbitrary bit
streams, avoiding the current need for branchy code.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"