On 2022-01-07, Tim Rentsch wrote:
> Marcus <m.delete@this.bitsnbites.eu> writes:
>
>> On 2021-12-31, Terje Mathisen wrote:
>>
>>> Marcus wrote:
>>>
>>>> On 2021-12-30, EricP wrote:
>>>>
>>>>> C,C++ and a bunch of languages explicitly define booleans as 0 or
>>>>> 1 so this definition won't be optimal for those languages. VAX
>>>>> Fortran used 0,-1 for LOGICAL but I don't know if that was
>>>>> defined by the language or implementation dependant.
>>>
>>> -1 is better than 1, it can be used as a mask.
>>>
>>>> As a software developer I'm painfully aware of this. I decided
>>>> not to care too much about it, though. Really, most software that
>>>> relies on this property of C should be frowned upon. E.g.,
>>>> expressions like:
>>>>
>>>> a = b + (c == d);
>>>>
>>>> ...aren't really good programming practice.
>>>
>>> No! Please tell me it ain't so!
>>>
>>> I use that type of constructs all over the place when writing
>>> branchless code/doing table lookups etc.
>>
>> I think that you'll find that the following code produces the
>> exact same result:
>>
>> int a;
>> if (c == d) {
>> a = b + 1;
>> } else {
>> a = b;
>> }
>>
>> It too is completely branchless.
>
> Being branchless is not the high order bit here.

?? I was responding to a note about relying on comparison results having
the value 0 or 1 for the purpose of producing branchless code.

>
>> My main gripe with the former version is the implicit type
>> conversion (boolean to integer), and that I don't like to see
>> logical operands and arithmetic operands mixed in the same
>> expression.
>
> Apparently you are thinking of some other language, not C.
> The result of comparison operators such as == have type int,
> not some boolean type. And that is not just an accident.
>

True. I usually dwell in C++ land, and there I'm pretty sure that
comparison operators return bool, not int.

Well, there's one more thing... In C, integer zero is "falsy", and
*anything else* is "truthy". But only integer 1 is the valid value of
"true". E.g. consider:

#define FALSE 0
#define TRUE 42

int c = (foo > bar);
if (c) // OK
if (c == 1) // OK
if (c == TRUE) // BAD

int c = (foo > bar) ? TRUE : FALSE;
if (c) // OK
if (c == 1) // BAD
if (c == TRUE) // OK

int c = foo - bar; // c is truthy if foo != bar
if (c) // OK
if (c == TRUE) // BAD
if (c == 1) // BAD

So, in general I do not like code that makes assumptions about the
integer value of a comparison result. I much rather see explicit
if-then-else statements, and have the compiler reduce it to the most
optimal form for the target machine (they do that these days). But
maybe I'm just too influenced by C++ philosophies.

/Marcus

On 2022-01-07, Tim Rentsch wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>
>> Marcus wrote:
>>
>>> On 2021-12-30, EricP wrote:
>>>
>>>> C,C++ and a bunch of languages explicitly define booleans as 0 or 1
>>>> so this definition won't be optimal for those languages.
>>>> VAX Fortran used 0,-1 for LOGICAL but I don't know if that
>>>> was defined by the language or implementation dependant.
>>
>> -1 is better than 1, it can be used as a mask.
>>
>>> As a software developer I'm painfully aware of this. I decided not to
>>> care too much about it, though. Really, most software that relies on
>>> this property of C should be frowned upon. E.g. expressions like:
>>>
>>> a = b + (c == d);
>>>
>>> ...aren't really good programming practice.
>>
>> No! Please tell me it ain't so!
>>
>> I use that type of constructs [frequently ...]
>
> Totally with you on this. People who don't see the benefit of
> using 0/1 values instead of if/else in cases like this are stuck
> in an antiquated way of thinking.
>

Care to elaborate? What context are we talking about here? C? Machine
code? Microarchitecture?

Have a look at https://godbolt.org/z/K7ndn57T1 and feel free to compare
what machine code you get on different architectures for the different C
code snippets (spoiler alert: with modern compilers there will typically
be no difference at all).

My point is that you should strive for writing (high level) code that
is as clear as possible w.r.t. the intent of the program (e.g. avoid
error prone constructs). At the machine code level, OTOH, you should of
course strive for the fastest possible implementation (for your
particular target machine).

/Marcus

Marcus <m.delete@this.bitsnbites.eu> schrieb:

> #define FALSE 0
> #define TRUE 42
>
> int c = (foo > bar);
> if (c) // OK
> if (c == 1) // OK
> if (c == TRUE) // BAD

If you want to compare boolean values like this in C,
you have to massage them somehow, so

if (!c == !TRUE)

or

if (!!c == !!TRUE)

or

if ((c != 0) == (TRUE != 0))

would work.

Unless the compiler can prove that only 0 and 1 will be used,
this will cost additional instructions. If you use a _Bool,
it knows that.

> So, in general I do not like code that makes assumptions about the
> integer value of a comparison result. I much rather see explicit
> if-then-else statements, and have the compiler reduce it to the most
> optimal form for the target machine (they do that these days). But
> maybe I'm just too influenced by C++ philosophies.

While I share your dislike, _Bool addresses at least part of it.

Tim Rentsch wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>
>> The & and | operators normally act on integral data types [...]
>
> Please forgive me for bringing up a technical fine point. The
> operators & and | normally act on integer data types, not
> integral data types. (In fact C doesn't have "integral" data
> types.) The distinction is not just rhetorical: a constant such
> as 3.0 has an integral value, but it does not have an integer
> value.

"Integral operands" is the words my MS compiler documentation uses,
and was the words K&R used for bitwise operators,
meaning either signed or unsigned integer operands.

For bitwise operators the C99 standard says
"Each of the operands shall have integer type"
which it does not qualify as signed or unsigned
and therefore means either.

On Friday, January 7, 2022 at 10:43:28 AM UTC-6, EricP wrote:
> Tim Rentsch wrote:
> > EricP <ThatWould...@thevillage.com> writes:
> >
> >> The & and | operators normally act on integral data types [...]
> >
> > Please forgive me for bringing up a technical fine point. The
> > operators & and | normally act on integer data types, not
> > integral data types. (In fact C doesn't have "integral" data
> > types.) The distinction is not just rhetorical: a constant such
> > as 3.0 has an integral value, but it does not have an integer
> > value.
> "Integral operands" is the words my MS compiler documentation uses,
> and was the words K&R used for bitwise operators,
> meaning either signed or unsigned integer operands.
>
> For bitwise operators the C99 standard says
> "Each of the operands shall have integer type"
> which it does not qualify as signed or unsigned
> and therefore means either.
<
When I did the ISA for a Samsung GPU, I explicitly used the word
"signless" for calculations for which neither signed nor unsigned
were strictly correct.
<
AND, OR, XOR are not really unsigned, they are signless and they
perform their work on a multitude of 1-bit containers SIMD-style.
There are others, signless was used in the presence of the sign
modification bits in each instruction and informed the sign control
circuits not to do anything. On a non SIMD machine setting of the
sign control bits of an instruction which calculates in the signless
domain would raise an Operation Exception.
<
This is a vast step too far for a language to take on, but it is not
too far for ISA designers to take to heart and use efficaciously.

On 1/7/2022 12:22 PM, MitchAlsup wrote:
> On Friday, January 7, 2022 at 10:43:28 AM UTC-6, EricP wrote:
>> Tim Rentsch wrote:
>>> EricP <ThatWould...@thevillage.com> writes:
>>>
>>>> The & and | operators normally act on integral data types [...]
>>>
>>> Please forgive me for bringing up a technical fine point. The
>>> operators & and | normally act on integer data types, not
>>> integral data types. (In fact C doesn't have "integral" data
>>> types.) The distinction is not just rhetorical: a constant such
>>> as 3.0 has an integral value, but it does not have an integer
>>> value.
>> "Integral operands" is the words my MS compiler documentation uses,
>> and was the words K&R used for bitwise operators,
>> meaning either signed or unsigned integer operands.
>>
>> For bitwise operators the C99 standard says
>> "Each of the operands shall have integer type"
>> which it does not qualify as signed or unsigned
>> and therefore means either.
> <
> When I did the ISA for a Samsung GPU, I explicitly used the word
> "signless" for calculations for which neither signed nor unsigned
> were strictly correct.
> <
> AND, OR, XOR are not really unsigned, they are signless and they
> perform their work on a multitude of 1-bit containers SIMD-style.
> There are others, signless was used in the presence of the sign
> modification bits in each instruction and informed the sign control
> circuits not to do anything. On a non SIMD machine setting of the
> sign control bits of an instruction which calculates in the signless
> domain would raise an Operation Exception.
> <
> This is a vast step too far for a language to take on, but it is not
> too far for ISA designers to take to heart and use efficaciously.

In our specs that domain is called "logical", which I think will be more
intuitive than "signless". YMMV.

Ivan Godard <ivan@millcomputing.com> schrieb:
> On 1/7/2022 12:22 PM, MitchAlsup wrote:

>> When I did the ISA for a Samsung GPU, I explicitly used the word
>> "signless" for calculations for which neither signed nor unsigned
>> were strictly correct.

[...]

>> This is a vast step too far for a language to take on, but it is not
>> too far for ISA designers to take to heart and use efficaciously.

A "bucket of bits" could indeed be a viable data type in a programming
language.

> In our specs that domain is called "logical", which I think will be more
> intuitive than "signless". YMMV.

I first misread that as "sinless", which Mitch's architecture is
not, since it has a SIN instruction. Question is, does it need
a REPENT instruction? (Can anybody find a reasonable backronym
for that?)

On Friday, January 7, 2022 at 4:48:52 PM UTC-6, Ivan Godard wrote:
> On 1/7/2022 12:22 PM, MitchAlsup wrote:
> > On Friday, January 7, 2022 at 10:43:28 AM UTC-6, EricP wrote:
> >> Tim Rentsch wrote:
> >>> EricP <ThatWould...@thevillage.com> writes:
> >>>
> >>>> The & and | operators normally act on integral data types [...]
> >>>
> >>> Please forgive me for bringing up a technical fine point. The
> >>> operators & and | normally act on integer data types, not
> >>> integral data types. (In fact C doesn't have "integral" data
> >>> types.) The distinction is not just rhetorical: a constant such
> >>> as 3.0 has an integral value, but it does not have an integer
> >>> value.
> >> "Integral operands" is the words my MS compiler documentation uses,
> >> and was the words K&R used for bitwise operators,
> >> meaning either signed or unsigned integer operands.
> >>
> >> For bitwise operators the C99 standard says
> >> "Each of the operands shall have integer type"
> >> which it does not qualify as signed or unsigned
> >> and therefore means either.
> > <
> > When I did the ISA for a Samsung GPU, I explicitly used the word
> > "signless" for calculations for which neither signed nor unsigned
> > were strictly correct.
> > <
> > AND, OR, XOR are not really unsigned, they are signless and they
> > perform their work on a multitude of 1-bit containers SIMD-style.
> > There are others, signless was used in the presence of the sign
> > modification bits in each instruction and informed the sign control
> > circuits not to do anything. On a non SIMD machine setting of the
> > sign control bits of an instruction which calculates in the signless
> > domain would raise an Operation Exception.
> > <
> > This is a vast step too far for a language to take on, but it is not
> > too far for ISA designers to take to heart and use efficaciously.
> In our specs that domain is called "logical", which I think will be more
> intuitive than "signless". YMMV.
<
Is ROL or ROR; signless, signed, unsigned or logical ?
<

On Friday, January 7, 2022 at 5:38:23 PM UTC-6, Thomas Koenig wrote:
> Ivan Godard <iv...@millcomputing.com> schrieb:
> > On 1/7/2022 12:22 PM, MitchAlsup wrote:
>
> >> When I did the ISA for a Samsung GPU, I explicitly used the word
> >> "signless" for calculations for which neither signed nor unsigned
> >> were strictly correct.
> [...]
> >> This is a vast step too far for a language to take on, but it is not
> >> too far for ISA designers to take to heart and use efficaciously.
> A "bucket of bits" could indeed be a viable data type in a programming
> language.
> > In our specs that domain is called "logical", which I think will be more
> > intuitive than "signless". YMMV.
> I first misread that as "sinless", which Mitch's architecture is
> not, since it has a SIN instruction. Question is, does it need
> a REPENT instruction? (Can anybody find a reasonable backronym
> for that?)
<
Every Architecture needs a REPENT instruction--at least to handle the
MACHINE-CHECK exception !!!

On 1/7/2022 4:56 PM, MitchAlsup wrote:
> On Friday, January 7, 2022 at 4:48:52 PM UTC-6, Ivan Godard wrote:
>> On 1/7/2022 12:22 PM, MitchAlsup wrote:
>>> On Friday, January 7, 2022 at 10:43:28 AM UTC-6, EricP wrote:
>>>> Tim Rentsch wrote:
>>>>> EricP <ThatWould...@thevillage.com> writes:
>>>>>
>>>>>> The & and | operators normally act on integral data types [...]
>>>>>
>>>>> Please forgive me for bringing up a technical fine point. The
>>>>> operators & and | normally act on integer data types, not
>>>>> integral data types. (In fact C doesn't have "integral" data
>>>>> types.) The distinction is not just rhetorical: a constant such
>>>>> as 3.0 has an integral value, but it does not have an integer
>>>>> value.
>>>> "Integral operands" is the words my MS compiler documentation uses,
>>>> and was the words K&R used for bitwise operators,
>>>> meaning either signed or unsigned integer operands.
>>>>
>>>> For bitwise operators the C99 standard says
>>>> "Each of the operands shall have integer type"
>>>> which it does not qualify as signed or unsigned
>>>> and therefore means either.
>>> <
>>> When I did the ISA for a Samsung GPU, I explicitly used the word
>>> "signless" for calculations for which neither signed nor unsigned
>>> were strictly correct.
>>> <
>>> AND, OR, XOR are not really unsigned, they are signless and they
>>> perform their work on a multitude of 1-bit containers SIMD-style.
>>> There are others, signless was used in the presence of the sign
>>> modification bits in each instruction and informed the sign control
>>> circuits not to do anything. On a non SIMD machine setting of the
>>> sign control bits of an instruction which calculates in the signless
>>> domain would raise an Operation Exception.
>>> <
>>> This is a vast step too far for a language to take on, but it is not
>>> too far for ISA designers to take to heart and use efficaciously.
>> In our specs that domain is called "logical", which I think will be more
>> intuitive than "signless". YMMV.
> <
> Is ROL or ROR; signless, signed, unsigned or logical ?
> <

Assuming those are "rotate", they are logical.

On Friday, December 31, 2021 at 5:37:07 AM UTC-7, Marcus wrote:

> I think that you'll find that the following code produces the exact same
> result:
>
> int a;
> if (c == d) {
> a = b + 1;
> } else {
> a = b;
> }
>
> It too is completely branchless.

It WHAT?

Your code snippet is:

test c and d for equality
if they are not equal, branch to #1
a = b+1
branch to #2
#1: a = b
#2 : ...

unless the compiler figures out how to
compile it to branchless code that produces
the same result.

An IF-THEN-ELSE, after all, executes one or the
other of two different code sequences. So its
meaning is to branch.

John Savard

MitchAlsup <MitchAlsup@aol.com> writes:
>Is ROL or ROR; signless, signed, unsigned or logical ?

Depends on how it is extended. If the architecture zero-extends it
(e.g., on AMD64), it's unsigned; if it sign-extends it, it is signed.

Of course, for full-width operations, there is no extension (just like
for add, sub, and mul), so you can call it either way, or invent some
way that tries to cover both. I find "signless" misleading, though
(too close to unsigned).

I wanted to look up how RISC-V does it; in
<https://raw.githubusercontent.com/riscv/riscv-bitmanip/master/bitmanip-0.90.pdf>,
it defines the operations with "uint_xlen_t" operands and results,
whatever that means (it looks unsigned to me, though). It defines
ror, rol, rori for RV32 and RV64, and rorw, rolw, roriw for RV64 only.
Reading up on Section 1.3 of the RISC-V SPEC, RV32 and RV64 are
designed to be incompatible, XLEN is the full width, and I guess the w
variants are the 32-bit variants; I have not found if this means that
rorw is zero-extended or sign-extended (based on the rest of the
instruction set, I would expect sign-extension).

It's interesting that RISC-V chose incompatibility between RV32 and
RV64, like AMD64 and Aarch64, unlike MIPS, SPARC, and PowerPC.
Apparently the conclusion after all the width extension experiences of
various architectures from the mid-1970s to Aarch64 is that the
benefits of a modeless extension (MIPS, SPARC, PowerPC) are too small,
and that the costs of a moded extension (AMD64, Aarch64, and many
others) are acceptable.

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

On 1/8/2022 1:14 AM, Anton Ertl wrote:
> MitchAlsup <MitchAlsup@aol.com> writes:
>> Is ROL or ROR; signless, signed, unsigned or logical ?
>
> Depends on how it is extended. If the architecture zero-extends it
> (e.g., on AMD64), it's unsigned; if it sign-extends it, it is signed.
>
> Of course, for full-width operations, there is no extension (just like
> for add, sub, and mul), so you can call it either way, or invent some
> way that tries to cover both. I find "signless" misleading, though
> (too close to unsigned).
>
> I wanted to look up how RISC-V does it; in
> <https://raw.githubusercontent.com/riscv/riscv-bitmanip/master/bitmanip-0.90.pdf>,
> it defines the operations with "uint_xlen_t" operands and results,
> whatever that means (it looks unsigned to me, though). It defines
> ror, rol, rori for RV32 and RV64, and rorw, rolw, roriw for RV64 only.
> Reading up on Section 1.3 of the RISC-V SPEC, RV32 and RV64 are
> designed to be incompatible, XLEN is the full width, and I guess the w
> variants are the 32-bit variants; I have not found if this means that
> rorw is zero-extended or sign-extended (based on the rest of the
> instruction set, I would expect sign-extension).
>
> It's interesting that RISC-V chose incompatibility between RV32 and
> RV64, like AMD64 and Aarch64, unlike MIPS, SPARC, and PowerPC.
> Apparently the conclusion after all the width extension experiences of
> various architectures from the mid-1970s to Aarch64 is that the
> benefits of a modeless extension (MIPS, SPARC, PowerPC) are too small,
> and that the costs of a moded extension (AMD64, Aarch64, and many
> others) are acceptable.
>
> - anton

No extension on Mill - operations are done in their actual width, just
like lanes in SIMD. The "widen" comes in both the signedInt and
unsignedInt domains.

On 2022-01-08, Quadibloc wrote:
> On Friday, December 31, 2021 at 5:37:07 AM UTC-7, Marcus wrote:
>
>> I think that you'll find that the following code produces the exact same
>> result:
>>
>> int a;
>> if (c == d) {
>> a = b + 1;
>> } else {
>> a = b;
>> }
>>
>> It too is completely branchless.
>
> It WHAT?
>
> Your code snippet is:
>
> test c and d for equality
> if they are not equal, branch to #1
> a = b+1
> branch to #2
> #1: a = b
> #2 : ...
>
> unless the compiler figures out how to
> compile it to branchless code that produces
> the same result.
>

That is exactly what it does. Here are a few examples for the above
"branchy" code:

ARMv7, Clang:
cmp r1, r2
addeq r0, r0, #1

AArch64, GCC:
cmp w1, w2
cinc w0, w0, eq

PowerPC, Clang:
xor 4, 4, 5
cntlzw 4, 4
srwi 4, 4, 5
add 3, 4, 3
extsw 3, 3

RISC-V, Clang:
xor a1, a1, a2
seqz a1, a1
addw a0, a0, a1

x86_64, MSVC:
cmp edx, r8d
lea eax, DWORD PTR [rcx+1]
cmovne eax, ecx

MRISC32, GCC:
seq r2, r2, r3
sub r1, r1, r2

> An IF-THEN-ELSE, after all, executes one or the
> other of two different code sequences. So its
> meaning is to branch.

Actually, the intent of the program is to evaluate the IF-THEN-ELSE
logic. That /can/ be done with a branch instruction, but it is not a
requirement.

I liked this article, aptly named "C is not a low-level language":

https://queue.acm.org/detail.cfm?id=3212479

The point is that a modern C compiler does not translate the C code
statement-by-statament to machine code. Instead it analyzes the C code,
applies transformations, and finally emits the machine code that is best
suited for the target machine.

Thus, there is no guarantee that an IF-statement will produce a branch
instruction. Likewise, code without IF-statements may produce branches.

E.g. the MSVC ARM compiler produces the following machine code for
a = b + (c == d):

cmp r1,r2
bne .L1
adds r0,r0,#1
..L1:

/Marcus

On 1/8/2022 3:23 AM, Quadibloc wrote:
> On Friday, December 31, 2021 at 5:37:07 AM UTC-7, Marcus wrote:
>
>> I think that you'll find that the following code produces the exact same
>> result:
>>
>> int a;
>> if (c == d) {
>> a = b + 1;
>> } else {
>> a = b;
>> }
>>
>> It too is completely branchless.
>
> It WHAT?
>
> Your code snippet is:
>
> test c and d for equality
> if they are not equal, branch to #1
> a = b+1
> branch to #2
> #1: a = b
> #2 : ...
>
> unless the compiler figures out how to
> compile it to branchless code that produces
> the same result.
>
> An IF-THEN-ELSE, after all, executes one or the
> other of two different code sequences. So its
> meaning is to branch.
>

Usual idea is that the branches in simple cases like this can be
optimized away.

This could be done be done via "compiler cleverness".

In my BJX2 ISA, this case can be handled using predicated instructions,
so no (actual) branch is needed. Predication is generally limited to
simple cases, but this isn't too big of an issue in practice (if they
could be predicated, complex cases do not lead to a performance
advantage). In effect, one also needs to set an upper limit for the
total number of operations (since executing a more complex expression
may be slower than branching over it).

....

Marcus wrote:
>
> Thus, there is no guarantee that an IF-statement will produce a branch
> instruction. Likewise, code without IF-statements may produce branches.
>
> E.g. the MSVC ARM compiler produces the following machine code for
> a = b + (c == d):
>
> cmp r1,r2
> bne .L1
> adds r0,r0,#1
> ..L1:
>
>
> /Marcus

I've seen references to papers on predicate implementations that
optimize it in HW by turning them back into branches or equivalent.

Example below is like that, in that it only generates uOps for the
predicate path predicted to be executed, and replays if mispredicted:

Predicate prediction for efficient out-of-order execution, 2003
https://dl.acm.org/doi/abs/10.1145/782814.782840

On Saturday, January 8, 2022 at 3:23:01 AM UTC-6, Quadibloc wrote:
> On Friday, December 31, 2021 at 5:37:07 AM UTC-7, Marcus wrote:
>
> > I think that you'll find that the following code produces the exact same
> > result:
> >
> > int a;
> > if (c == d) {
> > a = b + 1;
> > } else {
> > a = b;
> > }
> >
> > It too is completely branchless.
> It WHAT?
>
> Your code snippet is:
>
> test c and d for equality
> if they are not equal, branch to #1
> a = b+1
> branch to #2
> #1: a = b
> #2 : ...
>
> unless the compiler figures out how to
> compile it to branchless code that produces
> the same result.
>
> An IF-THEN-ELSE, after all, executes one or the
> other of two different code sequences. So its
> meaning is to branch.
<
One can execute the then-clause or the else-clause using
predication--which is branch free. Predication is the
branch free branch !!
>
> John Savard

On Saturday, January 8, 2022 at 4:00:56 AM UTC-6, Anton Ertl wrote:
> MitchAlsup <Mitch...@aol.com> writes:
> >Is ROL or ROR; signless, signed, unsigned or logical ?
<
> Depends on how it is extended. If the architecture zero-extends it
> (e.g., on AMD64), it's unsigned; if it sign-extends it, it is signed.
<
These rotate a full width register into a full width register by a given
number of bits. no bits are lost, and none gained.
>
> Of course, for full-width operations, there is no extension (just like
> for add, sub, and mul), so you can call it either way, or invent some
> way that tries to cover both. I find "signless" misleading, though
> (too close to unsigned).
<
signed represents the value space -2^(n-1)..+2^(n-1)-1
unsigned represents the value space 0..2^n-1
signless does not represent a value space at all--its just a bunch of bits.
>
> I wanted to look up how RISC-V does it; in
> <https://raw.githubusercontent.com/riscv/riscv-bitmanip/master/bitmanip-0.90.pdf>,
> it defines the operations with "uint_xlen_t" operands and results,
> whatever that means (it looks unsigned to me, though). It defines
> ror, rol, rori for RV32 and RV64, and rorw, rolw, roriw for RV64 only.
> Reading up on Section 1.3 of the RISC-V SPEC, RV32 and RV64 are
> designed to be incompatible, XLEN is the full width, and I guess the w
> variants are the 32-bit variants; I have not found if this means that
> rorw is zero-extended or sign-extended (based on the rest of the
> instruction set, I would expect sign-extension).
>
> It's interesting that RISC-V chose incompatibility between RV32 and
> RV64, like AMD64 and Aarch64, unlike MIPS, SPARC, and PowerPC.
> Apparently the conclusion after all the width extension experiences of
> various architectures from the mid-1970s to Aarch64 is that the
> benefits of a modeless extension (MIPS, SPARC, PowerPC) are too small,
> and that the costs of a moded extension (AMD64, Aarch64, and many
> others) are acceptable.
>
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On Saturday, January 8, 2022 at 10:50:35 AM UTC-7, MitchAlsup wrote:

> These rotate a full width register into a full width register by a given
> number of bits. no bits are lost, and none gained.

Given that, surely they could be referred to as "logical" operations,
as distinct from "numerical" operations; that ought to make it
sufficiently clear that 'signed' or 'unsigned' are not properly
applicable.

John Savard

On Saturday, January 8, 2022 at 2:37:50 PM UTC-6, Quadibloc wrote:
> On Saturday, January 8, 2022 at 10:50:35 AM UTC-7, MitchAlsup wrote:
>
> > These rotate a full width register into a full width register by a given
> > number of bits. no bits are lost, and none gained.
> Given that, surely they could be referred to as "logical" operations,
> as distinct from "numerical" operations; that ought to make it
> sufficiently clear that 'signed' or 'unsigned' are not properly
> applicable.
<
This gets back to the concept that the right hand side of a << or >> operator
needs to be unsigned--as certainly a negative number is simply not portable
there. In effect << and >> are mixed type operators.
>
> John Savard

On Saturday, January 8, 2022 at 2:37:27 PM UTC-7, MitchAlsup wrote:

> This gets back to the concept that the right hand side of a << or >> operator
> needs to be unsigned--as certainly a negative number is simply not portable
> there. In effect << and >> are mixed type operators.

I'd have to say that's questionable, simply because computers using any
representation other than two's complement for integers simply haven't
existed for the last several decades.

John Savard

On Saturday, January 8, 2022 at 7:07:03 PM UTC-6, Quadibloc wrote:
> On Saturday, January 8, 2022 at 2:37:27 PM UTC-7, MitchAlsup wrote:
>
> > This gets back to the concept that the right hand side of a << or >> operator
> > needs to be unsigned--as certainly a negative number is simply not portable
> > there. In effect << and >> are mixed type operators.
<
> I'd have to say that's questionable, simply because computers using any
> representation other than two's complement for integers simply haven't
> existed for the last several decades.
<
So, what does (13 << -7) mean ?
<
>
> John Savard

MitchAlsup wrote:
> On Saturday, January 8, 2022 at 7:07:03 PM UTC-6, Quadibloc wrote:
>> On Saturday, January 8, 2022 at 2:37:27 PM UTC-7, MitchAlsup wrote:
>>
>>> This gets back to the concept that the right hand side of a << or >> operator
>>> needs to be unsigned--as certainly a negative number is simply not portable
>>> there. In effect << and >> are mixed type operators.
> <
>> I'd have to say that's questionable, simply because computers using any
>> representation other than two's complement for integers simply haven't
>> existed for the last several decades.
> <
> So, what does (13 << -7) mean ?

VAX says it means (13 >> 7)

On Saturday, January 8, 2022 at 7:26:37 PM UTC-6, EricP wrote:
> MitchAlsup wrote:
> > On Saturday, January 8, 2022 at 7:07:03 PM UTC-6, Quadibloc wrote:
> >> On Saturday, January 8, 2022 at 2:37:27 PM UTC-7, MitchAlsup wrote:
> >>
> >>> This gets back to the concept that the right hand side of a << or >> operator
> >>> needs to be unsigned--as certainly a negative number is simply not portable
> >>> there. In effect << and >> are mixed type operators.
> > <
> >> I'd have to say that's questionable, simply because computers using any
> >> representation other than two's complement for integers simply haven't
> >> existed for the last several decades.
> > <
> > So, what does (13 << -7) mean ?
<
> VAX says it means (13 >> 7)
<
I happen to be well aware of what VAX said it means.
<
The question is what should a high level language say it means ?
<
And the second question is what should an ISA do when it gets a SL Rd,R13,R-7 ?

MitchAlsup wrote:
> On Saturday, January 8, 2022 at 7:26:37 PM UTC-6, EricP wrote:
>> MitchAlsup wrote:
>>> On Saturday, January 8, 2022 at 7:07:03 PM UTC-6, Quadibloc wrote:
>>>> On Saturday, January 8, 2022 at 2:37:27 PM UTC-7, MitchAlsup wrote:
>>>>
>>>>> This gets back to the concept that the right hand side of a << or >> operator
>>>>> needs to be unsigned--as certainly a negative number is simply not portable
>>>>> there. In effect << and >> are mixed type operators.
>>> <
>>>> I'd have to say that's questionable, simply because computers using any
>>>> representation other than two's complement for integers simply haven't
>>>> existed for the last several decades.
>>> <
>>> So, what does (13 << -7) mean ?
> <
>> VAX says it means (13 >> 7)
> <
> I happen to be well aware of what VAX said it means.
> <
> The question is what should a high level language say it means ?

What VAX says, of course.

> And the second question is what should an ISA do when it gets a SL Rd,R13,R-7 ?

Have you considered VAX compatibility?