Most ISAs (ignoring those with implicit CCs) have a bunch of compare ops
and one- or two-way branches. Mitch has one compare op and a multi-test
branch. ISTM that there's no gain in entropy either way, although one or
the other may pack better if the ISA is stuck with fixed size
instructions. Yes?

On Tuesday, September 6, 2022 at 10:31:26 PM UTC-5, Ivan Godard wrote:
> Most ISAs (ignoring those with implicit CCs) have a bunch of compare ops
> and one- or two-way branches. Mitch has one compare op and a multi-test
> branch. ISTM that there's no gain in entropy either way, although one or
> the other may pack better if the ISA is stuck with fixed size
> instructions. Yes?
<
It goes deeper than that! CMP creates a bit-vector of all sorts of things one might
want to know between 2 values. This relationship can be sampled in "branch context"
with the Branch-on-Bit (BB) instruction, or it can be sampled in "data context" with
the {signed or unsigned} extract (SL) instruction. Since My 66000 already had
extract instructions, this obviates any need to create SETcc-like instructions,
making the instruction set more "reduced". So with 4 instructions {CMP, FCMP,
BB, and SL} one can do anything one wants from a relationship between 2 values.
Compare this to the SETcc instructions in the INT and FP sides of RISC-V and
the CMP-BC instruction lacking in immediates,.........and come to our own conclusion.
<
RISC-V will argue that CMP-BC saves the compare instruction (code path
length argument) whereas in practice; due to lack of immediates and other
more minor ISA deficiencies, most of the purported gain is lost.
<
When comparing (sic) RISC-V code (and by extension MIPS code) with My
66000 code out of LLVM, we both execute the same number of instructions
in "branch context"*. For as many compare-branches as they do, I get a CMP
with immediate and branch-on-bit (they have to put a constant into a register in
order to use CMP-BC. This alone, gets rid of ½ of any RISC-V advantage that
was thought to exist.)
<
Plus, over on the FP side, RISC-V does not provide FP compare to zero and branch
which My 66000 does. Also, over here, My 66000 can compare to a FP constant
and branch-on bit in 2 instructions, LLVM RISC-V compiler has to synthesize an
address, then load the constant, then SETcc and finally Branch on condition..
<
And finally, My 66000 has a complete set of predicates. Every time a PRED is used
that contains both a then-clause and an else-clause, It saves a branch (and the
power wasted disrupting the FETCH process.)
<
Then there is the problem of epilogues. My 66000 has a single instruction to perform
restoration of the preserved registers and transfer of control back to caller. RISC-V,
because of the length of the epilogue sequence, will branch to the sequence instead
of performing the sequence at multiple locations. My 66000 does not need to
"economize" in this fashion.
<
And at the microarchitectural level, every CMP-BB can be CoIssued as if it
were a single instruction, so can LD-BB, ST-BB, and OPER-BB. You just have to
setup the FETCH-DECODE process to FETCH-wide and be able to issue 2
successive instructions (as long as you don't overload the 3R1W register
porting.)
<
(*) In "branch context" means all of the instructions needed to effect a flow control
decision--including the loading of constants (or other operands) to be compared
against, but not including any arithmetic that was inherent in creating the
situation on which a branch could be effected. For example:: if( x & 7 ); the
AND with #7 is not part of branch context.
<
In counting of CoreMark and LLVM main.c My 66000 only has 95% as many
branches (instructions which potentially alter the flow of control) as RISC_V.
With regards to switch(s); My 66000 uses an indexed table of 16-bit displacements
while RISC-V uses an indexed table of 64-bit absolutes--saving space, avoiding
the waste of a register, and the pollution of the data cache
<
Code size of My 66000 is essentially identical with RISC-V using the compressed
extension when My 66000 uses no compression whatsoever.

On 9/7/2022 9:00 AM, MitchAlsup wrote:
> On Tuesday, September 6, 2022 at 10:31:26 PM UTC-5, Ivan Godard wrote:
>> Most ISAs (ignoring those with implicit CCs) have a bunch of compare ops
>> and one- or two-way branches. Mitch has one compare op and a multi-test
>> branch. ISTM that there's no gain in entropy either way, although one or
>> the other may pack better if the ISA is stuck with fixed size
>> instructions. Yes?
> <
> It goes deeper than that! CMP creates a bit-vector of all sorts of things one might
> want to know between 2 values. This relationship can be sampled in "branch context"
> with the Branch-on-Bit (BB) instruction, or it can be sampled in "data context" with
> the {signed or unsigned} extract (SL) instruction. Since My 66000 already had
> extract instructions, this obviates any need to create SETcc-like instructions,
> making the instruction set more "reduced". So with 4 instructions {CMP, FCMP,
> BB, and SL} one can do anything one wants from a relationship between 2 values.
> Compare this to the SETcc instructions in the INT and FP sides of RISC-V and
> the CMP-BC instruction lacking in immediates,.........and come to our own conclusion.
> <
> RISC-V will argue that CMP-BC saves the compare instruction (code path
> length argument) whereas in practice; due to lack of immediates and other
> more minor ISA deficiencies, most of the purported gain is lost.
> <
> When comparing (sic) RISC-V code (and by extension MIPS code) with My
> 66000 code out of LLVM, we both execute the same number of instructions
> in "branch context"*. For as many compare-branches as they do, I get a CMP
> with immediate and branch-on-bit (they have to put a constant into a register in
> order to use CMP-BC. This alone, gets rid of ½ of any RISC-V advantage that
> was thought to exist.)
> <
> Plus, over on the FP side, RISC-V does not provide FP compare to zero and branch
> which My 66000 does. Also, over here, My 66000 can compare to a FP constant
> and branch-on bit in 2 instructions, LLVM RISC-V compiler has to synthesize an
> address, then load the constant, then SETcc and finally Branch on condition.
> <
> And finally, My 66000 has a complete set of predicates. Every time a PRED is used
> that contains both a then-clause and an else-clause, It saves a branch (and the
> power wasted disrupting the FETCH process.)
> <
> Then there is the problem of epilogues. My 66000 has a single instruction to perform
> restoration of the preserved registers and transfer of control back to caller. RISC-V,
> because of the length of the epilogue sequence, will branch to the sequence instead
> of performing the sequence at multiple locations. My 66000 does not need to
> "economize" in this fashion.
> <
> And at the microarchitectural level, every CMP-BB can be CoIssued as if it
> were a single instruction, so can LD-BB, ST-BB, and OPER-BB. You just have to
> setup the FETCH-DECODE process to FETCH-wide and be able to issue 2
> successive instructions (as long as you don't overload the 3R1W register
> porting.)
> <
> (*) In "branch context" means all of the instructions needed to effect a flow control
> decision--including the loading of constants (or other operands) to be compared
> against, but not including any arithmetic that was inherent in creating the
> situation on which a branch could be effected. For example:: if( x & 7 ); the
> AND with #7 is not part of branch context.
> <
> In counting of CoreMark and LLVM main.c My 66000 only has 95% as many
> branches (instructions which potentially alter the flow of control) as RISC_V.
> With regards to switch(s); My 66000 uses an indexed table of 16-bit displacements
> while RISC-V uses an indexed table of 64-bit absolutes--saving space, avoiding
> the waste of a register, and the pollution of the data cache
> <
> Code size of My 66000 is essentially identical with RISC-V using the compressed
> extension when My 66000 uses no compression whatsoever.

Yeah, but I was asking entropy, not ISA comparisons. Does one multi-rest
and a result selector have the same entropy as lots of one-way tests and
no selector? Seems to me it does. Whether that entropy packs better into
actual instructions in different ISAs is not the question; if he
entropuis are equal then there is no fundamental entropy reason to
choose one over the other, and so you can leave it up to packing density
and ease of unpack.

On Wednesday, September 7, 2022 at 2:12:51 PM UTC-5, Ivan Godard wrote:
> On 9/7/2022 9:00 AM, MitchAlsup wrote:
> > On Tuesday, September 6, 2022 at 10:31:26 PM UTC-5, Ivan Godard wrote:
> >> Most ISAs (ignoring those with implicit CCs) have a bunch of compare ops
> >> and one- or two-way branches. Mitch has one compare op and a multi-test
> >> branch. ISTM that there's no gain in entropy either way, although one or
> >> the other may pack better if the ISA is stuck with fixed size
> >> instructions. Yes?
<judicious snip>
> > In counting of CoreMark and LLVM main.c My 66000 only has 95% as many
> > branches (instructions which potentially alter the flow of control) as RISC_V.
> > With regards to switch(s); My 66000 uses an indexed table of 16-bit displacements
> > while RISC-V uses an indexed table of 64-bit absolutes--saving space, avoiding
> > the waste of a register, and the pollution of the data cache
> > <
> > Code size of My 66000 is essentially identical with RISC-V using the compressed
> > extension when My 66000 uses no compression whatsoever.
<
> Yeah, but I was asking entropy, not ISA comparisons. Does one multi-rest
> and a result selector have the same entropy as lots of one-way tests and
> no selector? Seems to me it does.
<
Depends if you are defining entropy in OpCodes or bits or semantic actions ?
{That is are you measuring entropy before-or-after performing the act of
instruction-encode.}
<
< Whether that entropy packs better into
> actual instructions in different ISAs is not the question; if he
> entropuis are equal then there is no fundamental entropy reason to
> choose one over the other, and so you can leave it up to packing density
> and ease of unpack.
<
My general guess (GUESS) is that if RISC-V had the universal constant scheme
of My 66000, that RISC-V CMP-BC instruction would have greater density. But
they don't and I can't see any way of them getting there.*
<
How much greater ? :: down in the 1% OpCode range.
<
I was surprised how infrequent RISC-V CMP-BC occurred in actual code, and
how often the compiler changed counted loops into count up to zero. I was
also surprised to discover real code of RISC-V having to paste a constant in
order to do:: {if, for, while}×( x rel_op constant ).
<
(*) But I think what you are getting at is related to my statement from about 18
months ago when I stated the ideal size of a fixed format instruction was about
36-bits.

On 9/7/2022 12:42 PM, MitchAlsup wrote:
> On Wednesday, September 7, 2022 at 2:12:51 PM UTC-5, Ivan Godard wrote:
>> On 9/7/2022 9:00 AM, MitchAlsup wrote:
>>> On Tuesday, September 6, 2022 at 10:31:26 PM UTC-5, Ivan Godard wrote:
>>>> Most ISAs (ignoring those with implicit CCs) have a bunch of compare ops
>>>> and one- or two-way branches. Mitch has one compare op and a multi-test
>>>> branch. ISTM that there's no gain in entropy either way, although one or
>>>> the other may pack better if the ISA is stuck with fixed size
>>>> instructions. Yes?
> <judicious snip>
>>> In counting of CoreMark and LLVM main.c My 66000 only has 95% as many
>>> branches (instructions which potentially alter the flow of control) as RISC_V.
>>> With regards to switch(s); My 66000 uses an indexed table of 16-bit displacements
>>> while RISC-V uses an indexed table of 64-bit absolutes--saving space, avoiding
>>> the waste of a register, and the pollution of the data cache
>>> <
>>> Code size of My 66000 is essentially identical with RISC-V using the compressed
>>> extension when My 66000 uses no compression whatsoever.
> <
>> Yeah, but I was asking entropy, not ISA comparisons. Does one multi-rest
>> and a result selector have the same entropy as lots of one-way tests and
>> no selector? Seems to me it does.
> <
> Depends if you are defining entropy in OpCodes or bits or semantic actions ?
> {That is are you measuring entropy before-or-after performing the act of
> instruction-encode.}

Information-theoretic entropy, in bits, nats, shannons or hartleys as
you choose.

> <
> < Whether that entropy packs better into
>> actual instructions in different ISAs is not the question; if he
>> entropuis are equal then there is no fundamental entropy reason to
>> choose one over the other, and so you can leave it up to packing density
>> and ease of unpack.
> <
> My general guess (GUESS) is that if RISC-V had the universal constant scheme
> of My 66000, that RISC-V CMP-BC instruction would have greater density. But
> they don't and I can't see any way of them getting there.*
> <
> How much greater ? :: down in the 1% OpCode range.
> <
> I was surprised how infrequent RISC-V CMP-BC occurred in actual code, and
> how often the compiler changed counted loops into count up to zero. I was
> also surprised to discover real code of RISC-V having to paste a constant in
> order to do:: {if, for, while}×( x rel_op constant ).
> <
> (*) But I think what you are getting at is related to my statement from about 18
> months ago when I stated the ideal size of a fixed format instruction was about
> 36-bits.

actually I was thinking about whether, and how, a multitest compare
would fit in our ISA. We already have a bit-test instruction, so turning
a result into a bool for store is provided for. But we only have two-way
branches, so we'd need either a compare-bittest-branch sequence or add a
selecting branch.

At that point I realized that the number of distinct cases (i.e. the
natural entropy) required y a selecting branch is the same as the number
of distinct compares required to feed a bool to a non-selecting branch.
Hence the entropy must be the same. Being suspicious of such insights, I
posted to confirm.

We wouldn't want to do a compare-bittest-branch because that costs a
slot and a cycle over simple separate comparison ops. We don't have any
packing constraints in the encoding, so separate comparison ops has no
don't-fit problems. Adding say 32 opcodes to a slot that already has
several hundred costs around 0.1 bit entropy for every op therein, while
adding 5 bits to each branch to select from the 32 conditions costs 5
bits from branches alone, say 0.25 of the ops in a slot with branches.

That would seem to favor separate opcodes, but only for the particular
slot population. Multiple test opcodes costs less each for more
instructions; multitest costs more but for fewer instructions. So which
is better (ignoring packing) depends on how many other codes are in the
same slot.

On Wednesday, September 7, 2022 at 9:39:06 PM UTC-5, Ivan Godard wrote:
> On 9/7/2022 12:42 PM, MitchAlsup wrote:
> > On Wednesday, September 7, 2022 at 2:12:51 PM UTC-5, Ivan Godard wrote:
> >> On 9/7/2022 9:00 AM, MitchAlsup wrote:
> >>> On Tuesday, September 6, 2022 at 10:31:26 PM UTC-5, Ivan Godard wrote:
> >>>> Most ISAs (ignoring those with implicit CCs) have a bunch of compare ops
> >>>> and one- or two-way branches. Mitch has one compare op and a multi-test
> >>>> branch. ISTM that there's no gain in entropy either way, although one or
> >>>> the other may pack better if the ISA is stuck with fixed size
> >>>> instructions. Yes?
> > <judicious snip>
> >>> In counting of CoreMark and LLVM main.c My 66000 only has 95% as many
> >>> branches (instructions which potentially alter the flow of control) as RISC_V.
> >>> With regards to switch(s); My 66000 uses an indexed table of 16-bit displacements
> >>> while RISC-V uses an indexed table of 64-bit absolutes--saving space, avoiding
> >>> the waste of a register, and the pollution of the data cache
> >>> <
> >>> Code size of My 66000 is essentially identical with RISC-V using the compressed
> >>> extension when My 66000 uses no compression whatsoever.
> > <
> >> Yeah, but I was asking entropy, not ISA comparisons. Does one multi-rest
> >> and a result selector have the same entropy as lots of one-way tests and
> >> no selector? Seems to me it does.
> > <
> > Depends if you are defining entropy in OpCodes or bits or semantic actions ?
> > {That is are you measuring entropy before-or-after performing the act of
> > instruction-encode.}
> Information-theoretic entropy, in bits, nats, shannons or hartleys as
> you choose.
> > <
> > < Whether that entropy packs better into
> >> actual instructions in different ISAs is not the question; if he
> >> entropuis are equal then there is no fundamental entropy reason to
> >> choose one over the other, and so you can leave it up to packing density
> >> and ease of unpack.
> > <
> > My general guess (GUESS) is that if RISC-V had the universal constant scheme
> > of My 66000, that RISC-V CMP-BC instruction would have greater density. But
> > they don't and I can't see any way of them getting there.*
> > <
> > How much greater ? :: down in the 1% OpCode range.
> > <
> > I was surprised how infrequent RISC-V CMP-BC occurred in actual code, and
> > how often the compiler changed counted loops into count up to zero. I was
> > also surprised to discover real code of RISC-V having to paste a constant in
> > order to do:: {if, for, while}×( x rel_op constant ).
> > <
> > (*) But I think what you are getting at is related to my statement from about 18
> > months ago when I stated the ideal size of a fixed format instruction was about
> > 36-bits.
> actually I was thinking about whether, and how, a multitest compare
> would fit in our ISA. We already have a bit-test instruction, so turning
> a result into a bool for store is provided for. But we only have two-way
> branches, so we'd need either a compare-bittest-branch sequence or add a
> selecting branch.
>
> At that point I realized that the number of distinct cases (i.e. the
> natural entropy) required y a selecting branch is the same as the number
> of distinct compares required to feed a bool to a non-selecting branch.
> Hence the entropy must be the same. Being suspicious of such insights, I
> posted to confirm.
>
> We wouldn't want to do a compare-bittest-branch because that costs a
> slot and a cycle over simple separate comparison ops. We don't have any
> packing constraints in the encoding, so separate comparison ops has no
> don't-fit problems. Adding say 32 opcodes to a slot that already has
> several hundred costs around 0.1 bit entropy for every op therein, while
> adding 5 bits to each branch to select from the 32 conditions costs 5
> bits from branches alone, say 0.25 of the ops in a slot with branches.
>
> That would seem to favor separate opcodes, but only for the particular
> slot population. Multiple test opcodes costs less each for more
> instructions; multitest costs more but for fewer instructions. So which
> is better (ignoring packing) depends on how many other codes are in the
> same slot.
<
In actuality, I call my Branch-on-bit instruction 1-instruction but in actuality
it has 64 instances (1 for every bit position in a register). You can either
consider this 64 instructions, or 1 instruction with a 6-bit immediate. I
lean towards the later and encoded it that way.
<
Similarly, there are 48 different ways to convert amongst the data types
(when you consider all of the rounding modes). I consider this 1-instruction
as the pipeline has but a single sequence to run this instruction down it, and
a small constant used to discriminate which of the instances is in play now..

> Most ISAs (ignoring those with implicit CCs) have a bunch of compare ops and
> one- or two-way branches. Mitch has one compare op and a multi-test
> branch. ISTM that there's no gain in entropy either way, although one or the
> other may pack better if the ISA is stuck with fixed size instructions. Yes?

A difference I can see is:
- with the test encoded together with the compare operation, you have
N possible tests to encode.
- with the test encoded as a bit-select in the branch, you have
M possible bits to select.
Say you only support 8 different tests, but your words are 64bits,
that's a difference of 3bit vs 6bits.

Then another difference is when a single compare's results are used in
N subsequent branches, in which case you save the repetition of
the operands compared to the scheme where you need to perform
N different comparisons.

I don't think either factor will make much difference in real life, tho.

Stefan

Ivan Godard <ivan@millcomputing.com> schrieb:

> Information-theoretic entropy, in bits, nats, shannons or hartleys as
> you choose.

I would probably prefer J/(mol*K), but since Boltzmann's constant
is so small, the numbers would be quite small (although still well
within the range of an IEEE single precision variable).

On 9/8/2022 9:14 AM, MitchAlsup wrote:
> On Wednesday, September 7, 2022 at 9:39:06 PM UTC-5, Ivan Godard wrote:
>> On 9/7/2022 12:42 PM, MitchAlsup wrote:
>>> On Wednesday, September 7, 2022 at 2:12:51 PM UTC-5, Ivan Godard wrote:
>>>> On 9/7/2022 9:00 AM, MitchAlsup wrote:
>>>>> On Tuesday, September 6, 2022 at 10:31:26 PM UTC-5, Ivan Godard wrote:
>>>>>> Most ISAs (ignoring those with implicit CCs) have a bunch of compare ops
>>>>>> and one- or two-way branches. Mitch has one compare op and a multi-test
>>>>>> branch. ISTM that there's no gain in entropy either way, although one or
>>>>>> the other may pack better if the ISA is stuck with fixed size
>>>>>> instructions. Yes?
>>> <judicious snip>
>>>>> In counting of CoreMark and LLVM main.c My 66000 only has 95% as many
>>>>> branches (instructions which potentially alter the flow of control) as RISC_V.
>>>>> With regards to switch(s); My 66000 uses an indexed table of 16-bit displacements
>>>>> while RISC-V uses an indexed table of 64-bit absolutes--saving space, avoiding
>>>>> the waste of a register, and the pollution of the data cache
>>>>> <
>>>>> Code size of My 66000 is essentially identical with RISC-V using the compressed
>>>>> extension when My 66000 uses no compression whatsoever.
>>> <
>>>> Yeah, but I was asking entropy, not ISA comparisons. Does one multi-rest
>>>> and a result selector have the same entropy as lots of one-way tests and
>>>> no selector? Seems to me it does.
>>> <
>>> Depends if you are defining entropy in OpCodes or bits or semantic actions ?
>>> {That is are you measuring entropy before-or-after performing the act of
>>> instruction-encode.}
>> Information-theoretic entropy, in bits, nats, shannons or hartleys as
>> you choose.
>>> <
>>> < Whether that entropy packs better into
>>>> actual instructions in different ISAs is not the question; if he
>>>> entropuis are equal then there is no fundamental entropy reason to
>>>> choose one over the other, and so you can leave it up to packing density
>>>> and ease of unpack.
>>> <
>>> My general guess (GUESS) is that if RISC-V had the universal constant scheme
>>> of My 66000, that RISC-V CMP-BC instruction would have greater density. But
>>> they don't and I can't see any way of them getting there.*
>>> <
>>> How much greater ? :: down in the 1% OpCode range.
>>> <
>>> I was surprised how infrequent RISC-V CMP-BC occurred in actual code, and
>>> how often the compiler changed counted loops into count up to zero. I was
>>> also surprised to discover real code of RISC-V having to paste a constant in
>>> order to do:: {if, for, while}×( x rel_op constant ).
>>> <
>>> (*) But I think what you are getting at is related to my statement from about 18
>>> months ago when I stated the ideal size of a fixed format instruction was about
>>> 36-bits.
>> actually I was thinking about whether, and how, a multitest compare
>> would fit in our ISA. We already have a bit-test instruction, so turning
>> a result into a bool for store is provided for. But we only have two-way
>> branches, so we'd need either a compare-bittest-branch sequence or add a
>> selecting branch.
>>
>> At that point I realized that the number of distinct cases (i.e. the
>> natural entropy) required y a selecting branch is the same as the number
>> of distinct compares required to feed a bool to a non-selecting branch.
>> Hence the entropy must be the same. Being suspicious of such insights, I
>> posted to confirm.
>>
>> We wouldn't want to do a compare-bittest-branch because that costs a
>> slot and a cycle over simple separate comparison ops. We don't have any
>> packing constraints in the encoding, so separate comparison ops has no
>> don't-fit problems. Adding say 32 opcodes to a slot that already has
>> several hundred costs around 0.1 bit entropy for every op therein, while
>> adding 5 bits to each branch to select from the 32 conditions costs 5
>> bits from branches alone, say 0.25 of the ops in a slot with branches.
>>
>> That would seem to favor separate opcodes, but only for the particular
>> slot population. Multiple test opcodes costs less each for more
>> instructions; multitest costs more but for fewer instructions. So which
>> is better (ignoring packing) depends on how many other codes are in the
>> same slot.
> <
> In actuality, I call my Branch-on-bit instruction 1-instruction but in actuality
> it has 64 instances (1 for every bit position in a register). You can either
> consider this 64 instructions, or 1 instruction with a 6-bit immediate. I
> lean towards the later and encoded it that way.
> <
> Similarly, there are 48 different ways to convert amongst the data types
> (when you consider all of the rounding modes). I consider this 1-instruction
> as the pipeline has but a single sequence to run this instruction down it, and
> a small constant used to discriminate which of the instances is in play now.

If I were not using my current scheme, would probably go for something like:
BZ Rn, label //Branch if Rn==0
BNZ Rn, label //Branch if Rn!=0
BGE Rn, label //Branch if Rn>=0 (Sign=0)
BLT Rn, label //Branch if Rn< 0 (Sign=1)

Average case would still be 2 instructions for compare-and-branch, and
it would be cheaper for hardware than the strategy used by RISC-V.

Supporting arbitrary bits could be useful, estimated cost ~ 30 LUTs (vs
~ 14 LUTs for an Rn==0 check). Could reduce many "if(x&mask)" operations
to a single branch, but would likely still need an (Rn==0) / (Rn!=0)
check to deal with the general cases.

Less cost and latency either way than requiring a relative comparison.

With the mechanism above, say:
if(x)
BNZ x, lbl
if(!x)
BZ x, lbl
if(x&mask)
AND x, mask, t
BNZ t, lbl
if(!(x&mask))
AND x, mask, t
BZ t, lbl
if(x==y)
SUB x, y, t
BZ t, lbl
if(x!=y)
SUB x, y, t
BNZ t, lbl
if(x<y)
SUB x, y, t
BLT t, lbl
if(x>y)
SUB y, x, t
BLT t, lbl
if(x<=y)
SUB y, x, t
BGE t, lbl
if(x>=y)
SUB x, y, t
BGE t, lbl

Assuming 64-bit, would need dedicated compare ops for 64-bit comparisons
(for 32-bit, SUB should work assuming 32-bit values are kept sign or
zero extended).

Constant cases would be similar, except:
if(x>c) ..
if(x<=c) ..

Can't be directly encoded in 2 ops if we only have:
SUB Rm, imm, Rn // Rn=Rm-Imm
Would likely also need:
RSUB Rm, imm, Rn // Rn=Imm-Rm

One could argue about MSB tagged pointers, but I already have this issue
and mostly ignore it. Normal C code doesn't use pointer tagging; and
there is no need to do relative comparisons for the Link Register or
similar, ...; so can mostly sweep this whole issue under the carpet.

One drawback is that there would no longer be a particularly "good" way
to support predicated instructions (at least much beyond interpreting
certain short-forward-branches as a predicate mask or similar).

....

On Thursday, September 8, 2022 at 9:26:25 AM UTC-5, Stefan Monnier wrote:
> > Most ISAs (ignoring those with implicit CCs) have a bunch of compare ops and
> > one- or two-way branches. Mitch has one compare op and a multi-test
> > branch. ISTM that there's no gain in entropy either way, although one or the
> > other may pack better if the ISA is stuck with fixed size instructions. Yes?
<
> A difference I can see is:
> - with the test encoded together with the compare operation, you have
> N possible tests to encode.
> - with the test encoded as a bit-select in the branch, you have
> M possible bits to select.
> Say you only support 8 different tests, but your words are 64bits,
> that's a difference of 3bit vs 6bits.
<
You then have to weigh the cost of not having such an available combination.
Say, your compiler wants to flip then and else clauses with a FP compare.
You want the NaN comparisons to go into the else-clause even after re-
arrangement. Here you need not 8 ways to perform the comparisons but 14.
{Unless you don't care about what numerical analysts care about......}
<
Then consider if you ever want to compare with "any byte zero", "Any halfword
zero",.... "compare any byte equal",..."compare any byte LT",...,...,...
these are trivial to add with the bit-vector approach and "expensive" with the
compare-and-branch approach.
>
> Then another difference is when a single compare's results are used in
> N subsequent branches, in which case you save the repetition of
> the operands compared to the scheme where you need to perform
> N different comparisons.
<
Not surprisingly, reuse of a comparison occurs slightly less often than
reuse of typical results--however, Brian's LLVM compiler seems to find
these cases.
>
> I don't think either factor will make much difference in real life, tho.
>
Probably right.
>
> Stefan

On Thursday, September 8, 2022 at 1:30:22 PM UTC-5, BGB wrote:
> On 9/8/2022 9:14 AM, MitchAlsup wrote:
> > On Wednesday, September 7, 2022 at 9:39:06 PM UTC-5, Ivan Godard wrote:
<snip>
> If I were not using my current scheme, would probably go for something like:
> BZ Rn, label //Branch if Rn==0
> BNZ Rn, label //Branch if Rn!=0
> BGE Rn, label //Branch if Rn>=0 (Sign=0)
> BLT Rn, label //Branch if Rn< 0 (Sign=1)
>
> Average case would still be 2 instructions for compare-and-branch, and
> it would be cheaper for hardware than the strategy used by RISC-V.
>
>
> Supporting arbitrary bits could be useful, estimated cost ~ 30 LUTs (vs
> ~ 14 LUTs for an Rn==0 check). Could reduce many "if(x&mask)" operations
> to a single branch, but would likely still need an (Rn==0) / (Rn!=0)
> check to deal with the general cases.
>
> Less cost and latency either way than requiring a relative comparison.
>
>
> With the mechanism above, say:
> if(x)
> BNZ x, lbl
> if(!x)
> BZ x, lbl
> if(x&mask)
> AND x, mask, t
> BNZ t, lbl
> if(!(x&mask))
> AND x, mask, t
> BZ t, lbl
> if(x==y)
> SUB x, y, t
> BZ t, lbl
> if(x!=y)
> SUB x, y, t
> BNZ t, lbl
> if(x<y)
> SUB x, y, t
> BLT t, lbl
> if(x>y)
> SUB y, x, t
> BLT t, lbl
> if(x<=y)
> SUB y, x, t
> BGE t, lbl
> if(x>=y)
> SUB x, y, t
> BGE t, lbl
>
> Assuming 64-bit, would need dedicated compare ops for 64-bit comparisons
> (for 32-bit, SUB should work assuming 32-bit values are kept sign or
> zero extended).
>
> Constant cases would be similar, except:
> if(x>c) ..
> if(x<=c) ..
>
> Can't be directly encoded in 2 ops if we only have:
> SUB Rm, imm, Rn // Rn=Rm-Imm
> Would likely also need:
> RSUB Rm, imm, Rn // Rn=Imm-Rm
>
"Breakdown, go ahead and give it to me
Breakdown, honey, take me through the night" Tom Petty and the Heartbreakers....
>
> One could argue about MSB tagged pointers, but I already have this issue
> and mostly ignore it. Normal C code doesn't use pointer tagging; and
> there is no need to do relative comparisons for the Link Register or
> similar, ...; so can mostly sweep this whole issue under the carpet.
>
>
> One drawback is that there would no longer be a particularly "good" way
> to support predicated instructions (at least much beyond interpreting
> certain short-forward-branches as a predicate mask or similar).
>
>
> ...

On 9/8/2022 4:39 PM, MitchAlsup wrote:
> On Thursday, September 8, 2022 at 1:30:22 PM UTC-5, BGB wrote:
>> On 9/8/2022 9:14 AM, MitchAlsup wrote:
>>> On Wednesday, September 7, 2022 at 9:39:06 PM UTC-5, Ivan Godard wrote:
> <snip>
>> If I were not using my current scheme, would probably go for something like:
>> BZ Rn, label //Branch if Rn==0
>> BNZ Rn, label //Branch if Rn!=0
>> BGE Rn, label //Branch if Rn>=0 (Sign=0)
>> BLT Rn, label //Branch if Rn< 0 (Sign=1)
>>
>> Average case would still be 2 instructions for compare-and-branch, and
>> it would be cheaper for hardware than the strategy used by RISC-V.
>>
>>
>> Supporting arbitrary bits could be useful, estimated cost ~ 30 LUTs (vs
>> ~ 14 LUTs for an Rn==0 check). Could reduce many "if(x&mask)" operations
>> to a single branch, but would likely still need an (Rn==0) / (Rn!=0)
>> check to deal with the general cases.
>>
>> Less cost and latency either way than requiring a relative comparison.
>>
>>
>> With the mechanism above, say:
>> if(x)
>> BNZ x, lbl
>> if(!x)
>> BZ x, lbl
>> if(x&mask)
>> AND x, mask, t
>> BNZ t, lbl
>> if(!(x&mask))
>> AND x, mask, t
>> BZ t, lbl
>> if(x==y)
>> SUB x, y, t
>> BZ t, lbl
>> if(x!=y)
>> SUB x, y, t
>> BNZ t, lbl
>> if(x<y)
>> SUB x, y, t
>> BLT t, lbl
>> if(x>y)
>> SUB y, x, t
>> BLT t, lbl
>> if(x<=y)
>> SUB y, x, t
>> BGE t, lbl
>> if(x>=y)
>> SUB x, y, t
>> BGE t, lbl
>>
>> Assuming 64-bit, would need dedicated compare ops for 64-bit comparisons
>> (for 32-bit, SUB should work assuming 32-bit values are kept sign or
>> zero extended).
>>
>> Constant cases would be similar, except:
>> if(x>c) ..
>> if(x<=c) ..
>>
>> Can't be directly encoded in 2 ops if we only have:
>> SUB Rm, imm, Rn // Rn=Rm-Imm
>> Would likely also need:
>> RSUB Rm, imm, Rn // Rn=Imm-Rm
>>

I was initially looking at stuff, and reverse-subtract cases initially
seemed rare.

But, I added a mock-up pseudo-instruction (faked by a constant load
followed by a 3R subtract), and modified the 3AC->ASM code to try to use it.

Then suddenly they appeared all over the place, along with a noticeable
improvement in Doom framerates (and a slight decrease in the Load/Store
density).

It seems like reverse subtracts weren't quite as rare as I thought, and
it was also seemingly adversely effecting the register allocator (which
would handle the constants in these cases by treating them like they
were variables; albeit ones' without any backing memory; so they simply
disappear when evicted, and generate a constant-load when used again).

Goes and adds the actual instruction as a test, seems it is still pretty
far down the ranking (still nowhere near as common as most of the other
ALU ops).

It seems like the gains were more likely due to not dealing with these
constants via the register allocator, than due to any particular merit
of the instruction itself.

> "Breakdown, go ahead and give it to me
> Breakdown, honey, take me through the night" Tom Petty and the Heartbreakers....

Not really heard much of Tom Petty, I think my parents like his music
though.

Am personally more into House/Dubstep/EDM/etc.

When I was younger, I was kinda into Goth (was mostly Synthpop based at
the time, I guess vs an older Rock/Metal based style). I guess when I
got a little older though, I ended up taking issue with the genre's
almost cult-like obsession with vampires and occult topics.

Well, and I guess at some point I went from seeing existence through a
primarily negative lens, to being more neutral. Say, where in the
greater scheme of thing, ones' existence is mostly meaningless, but like
at least one can try to make the best of it; like it doesn't do much
good to spend all of ones' time being caught up in ones' existence being
ultimately meaningless, etc.

Unlike some people, could really never make the jump to believing there
is intrinsic value in anything; but will at least to claim that a sort
of localized value exists (say, things can have value so long as there
are still people to take value in them).

Well, or, say, value exists for humans in much the same way as software
exists for computers. If there were no computers, there would not be any
way for software to exist, but as long as they exist, so too does the
software they contain.

Well, ignoring any religious / theological arguments; ultimately can't
take a solid stance on this; nor is it entirely obvious whether this is
enough to justify a claim that intrinsic value exists, or if it merely
changes the scope slightly.

I guess I loosely identify with existentialism, but also disagree with
their tendency to assign emotional/subjective qualities to existence
being (ultimately) meaningless (basically "smells" too much like the
same sort of underlying philosophy as the goth subculture). Say, the
lack of meaning not being any sort of malice, but rather, nothing
whatsoever (can't assign malice to something which doesn't really exist
in the first place).

Not quite figured out how other people think in these areas.
Sometimes I am left with some inward facing concerns as to "who I am",
but am then left to no real way to "fix" them nor with any real way that
they are "fixable".

Torn between trying to go into this topic, but it is an difficult area,
and I am kinda really needing to go to sleep...

Kinda really need to sleep, I guess now is probably not the right time
to go into my thoughts here.

>>
>> One could argue about MSB tagged pointers, but I already have this issue
>> and mostly ignore it. Normal C code doesn't use pointer tagging; and
>> there is no need to do relative comparisons for the Link Register or
>> similar, ...; so can mostly sweep this whole issue under the carpet.
>>
>>
>> One drawback is that there would no longer be a particularly "good" way
>> to support predicated instructions (at least much beyond interpreting
>> certain short-forward-branches as a predicate mask or similar).
>>
>>
>> ...

On 9/9/2022 2:55 AM, BGB wrote:
> On 9/8/2022 4:39 PM, MitchAlsup wrote:
>> On Thursday, September 8, 2022 at 1:30:22 PM UTC-5, BGB wrote:
>>> On 9/8/2022 9:14 AM, MitchAlsup wrote:
>>>> On Wednesday, September 7, 2022 at 9:39:06 PM UTC-5, Ivan Godard wrote:
>> <snip>
>>> If I were not using my current scheme, would probably go for
>>> something like:
>>> BZ Rn, label //Branch if Rn==0
>>> BNZ Rn, label //Branch if Rn!=0
>>> BGE Rn, label //Branch if Rn>=0 (Sign=0)
>>> BLT Rn, label //Branch if Rn< 0 (Sign=1)
>>>
>>> Average case would still be 2 instructions for compare-and-branch, and
>>> it would be cheaper for hardware than the strategy used by RISC-V.
>>>
>>>
>>> Supporting arbitrary bits could be useful, estimated cost ~ 30 LUTs (vs
>>> ~ 14 LUTs for an Rn==0 check). Could reduce many "if(x&mask)" operations
>>> to a single branch, but would likely still need an (Rn==0) / (Rn!=0)
>>> check to deal with the general cases.
>>>
>>> Less cost and latency either way than requiring a relative comparison.
>>>
>>>
>>> With the mechanism above, say:
>>> if(x)
>>> BNZ x, lbl
>>> if(!x)
>>> BZ x, lbl
>>> if(x&mask)
>>> AND x, mask, t
>>> BNZ t, lbl
>>> if(!(x&mask))
>>> AND x, mask, t
>>> BZ t, lbl
>>> if(x==y)
>>> SUB x, y, t
>>> BZ t, lbl
>>> if(x!=y)
>>> SUB x, y, t
>>> BNZ t, lbl
>>> if(x<y)
>>> SUB x, y, t
>>> BLT t, lbl
>>> if(x>y)
>>> SUB y, x, t
>>> BLT t, lbl
>>> if(x<=y)
>>> SUB y, x, t
>>> BGE t, lbl
>>> if(x>=y)
>>> SUB x, y, t
>>> BGE t, lbl
>>>
>>> Assuming 64-bit, would need dedicated compare ops for 64-bit comparisons
>>> (for 32-bit, SUB should work assuming 32-bit values are kept sign or
>>> zero extended).
>>>
>>> Constant cases would be similar, except:
>>> if(x>c) ..
>>> if(x<=c) ..
>>>
>>> Can't be directly encoded in 2 ops if we only have:
>>> SUB Rm, imm, Rn // Rn=Rm-Imm
>>> Would likely also need:
>>> RSUB Rm, imm, Rn // Rn=Imm-Rm
>>>
>
> I was initially looking at stuff, and reverse-subtract cases initially
> seemed rare.
>
> But, I added a mock-up pseudo-instruction (faked by a constant load
> followed by a 3R subtract), and modified the 3AC->ASM code to try to use
> it.
>
> Then suddenly they appeared all over the place, along with a noticeable
> improvement in Doom framerates (and a slight decrease in the Load/Store
> density).
>
> It seems like reverse subtracts weren't quite as rare as I thought, and
> it was also seemingly adversely effecting the register allocator (which
> would handle the constants in these cases by treating them like they
> were variables; albeit ones' without any backing memory; so they simply
> disappear when evicted, and generate a constant-load when used again).
>
>
> Goes and adds the actual instruction as a test, seems it is still pretty
> far down the ranking (still nowhere near as common as most of the other
> ALU ops).
>
> It seems like the gains were more likely due to not dealing with these
> constants via the register allocator, than due to any particular merit
> of the instruction itself.
>
>
>> "Breakdown, go ahead and give it to me
>> Breakdown, honey, take me through the night" Tom Petty and the
>> Heartbreakers....
>
> Not really heard much of Tom Petty, I think my parents like his music
> though.
>
> Am personally more into House/Dubstep/EDM/etc.
>
>
> When I was younger, I was kinda into Goth (was mostly Synthpop based at
> the time, I guess vs an older Rock/Metal based style). I guess when I
> got a little older though, I ended up taking issue with the genre's
> almost cult-like obsession with vampires and occult topics.
>
>
> Well, and I guess at some point I went from seeing existence through a
> primarily negative lens, to being more neutral. Say, where in the
> greater scheme of thing, ones' existence is mostly meaningless, but like
> at least one can try to make the best of it; like it doesn't do much
> good to spend all of ones' time being caught up in ones' existence being
> ultimately meaningless, etc.
>
>
> Unlike some people, could really never make the jump to believing there
> is intrinsic value in anything; but will at least to claim that a sort
> of localized value exists (say, things can have value so long as there
> are still people to take value in them).
>
> Well, or, say, value exists for humans in much the same way as software
> exists for computers. If there were no computers, there would not be any
> way for software to exist, but as long as they exist, so too does the
> software they contain.
>
> Well, ignoring any religious / theological arguments; ultimately can't
> take a solid stance on this; nor is it entirely obvious whether this is
> enough to justify a claim that intrinsic value exists, or if it merely
> changes the scope slightly.
>
> I guess I loosely identify with existentialism, but also disagree with
> their tendency to assign emotional/subjective qualities to existence
> being (ultimately) meaningless (basically "smells" too much like the
> same sort of underlying philosophy as the goth subculture). Say, the
> lack of meaning not being any sort of malice, but rather, nothing
> whatsoever (can't assign malice to something which doesn't really exist
> in the first place).
>
>
> Not quite figured out how other people think in these areas.
> Sometimes I am left with some inward facing concerns as to "who I am",
> but am then left to no real way to "fix" them nor with any real way that
> they are "fixable".
>
> Torn between trying to go into this topic, but it is an difficult area,
> and I am kinda really needing to go to sleep...
>
> Kinda really need to sleep, I guess now is probably not the right time
> to go into my thoughts here.

There's extrinsic meaning (or lack thereof), or there's intrinsic
meaning, that one asserts. "Yes life has meaning, because I say it does".

On 9/9/2022 5:12 AM, Ivan Godard wrote:
> On 9/9/2022 2:55 AM, BGB wrote:
>> On 9/8/2022 4:39 PM, MitchAlsup wrote:
>>> On Thursday, September 8, 2022 at 1:30:22 PM UTC-5, BGB wrote:
>>>> On 9/8/2022 9:14 AM, MitchAlsup wrote:
>>>>> On Wednesday, September 7, 2022 at 9:39:06 PM UTC-5, Ivan Godard
>>>>> wrote:
>>> <snip>
>>>> If I were not using my current scheme, would probably go for
>>>> something like:
>>>> BZ Rn, label //Branch if Rn==0
>>>> BNZ Rn, label //Branch if Rn!=0
>>>> BGE Rn, label //Branch if Rn>=0 (Sign=0)
>>>> BLT Rn, label //Branch if Rn< 0 (Sign=1)
>>>>
>>>> Average case would still be 2 instructions for compare-and-branch, and
>>>> it would be cheaper for hardware than the strategy used by RISC-V.
>>>>
>>>>
>>>> Supporting arbitrary bits could be useful, estimated cost ~ 30 LUTs (vs
>>>> ~ 14 LUTs for an Rn==0 check). Could reduce many "if(x&mask)"
>>>> operations
>>>> to a single branch, but would likely still need an (Rn==0) / (Rn!=0)
>>>> check to deal with the general cases.
>>>>
>>>> Less cost and latency either way than requiring a relative comparison.
>>>>
>>>>
>>>> With the mechanism above, say:
>>>> if(x)
>>>> BNZ x, lbl
>>>> if(!x)
>>>> BZ x, lbl
>>>> if(x&mask)
>>>> AND x, mask, t
>>>> BNZ t, lbl
>>>> if(!(x&mask))
>>>> AND x, mask, t
>>>> BZ t, lbl
>>>> if(x==y)
>>>> SUB x, y, t
>>>> BZ t, lbl
>>>> if(x!=y)
>>>> SUB x, y, t
>>>> BNZ t, lbl
>>>> if(x<y)
>>>> SUB x, y, t
>>>> BLT t, lbl
>>>> if(x>y)
>>>> SUB y, x, t
>>>> BLT t, lbl
>>>> if(x<=y)
>>>> SUB y, x, t
>>>> BGE t, lbl
>>>> if(x>=y)
>>>> SUB x, y, t
>>>> BGE t, lbl
>>>>
>>>> Assuming 64-bit, would need dedicated compare ops for 64-bit
>>>> comparisons
>>>> (for 32-bit, SUB should work assuming 32-bit values are kept sign or
>>>> zero extended).
>>>>
>>>> Constant cases would be similar, except:
>>>> if(x>c) ..
>>>> if(x<=c) ..
>>>>
>>>> Can't be directly encoded in 2 ops if we only have:
>>>> SUB Rm, imm, Rn // Rn=Rm-Imm
>>>> Would likely also need:
>>>> RSUB Rm, imm, Rn // Rn=Imm-Rm
>>>>
>>
>> I was initially looking at stuff, and reverse-subtract cases initially
>> seemed rare.
>>
>> But, I added a mock-up pseudo-instruction (faked by a constant load
>> followed by a 3R subtract), and modified the 3AC->ASM code to try to
>> use it.
>>
>> Then suddenly they appeared all over the place, along with a
>> noticeable improvement in Doom framerates (and a slight decrease in
>> the Load/Store density).
>>
>> It seems like reverse subtracts weren't quite as rare as I thought,
>> and it was also seemingly adversely effecting the register allocator
>> (which would handle the constants in these cases by treating them like
>> they were variables; albeit ones' without any backing memory; so they
>> simply disappear when evicted, and generate a constant-load when used
>> again).
>>
>>
>> Goes and adds the actual instruction as a test, seems it is still
>> pretty far down the ranking (still nowhere near as common as most of
>> the other ALU ops).
>>
>> It seems like the gains were more likely due to not dealing with these
>> constants via the register allocator, than due to any particular merit
>> of the instruction itself.
>>
>>
>>> "Breakdown, go ahead and give it to me
>>> Breakdown, honey, take me through the night" Tom Petty and the
>>> Heartbreakers....
>>
>> Not really heard much of Tom Petty, I think my parents like his music
>> though.
>>
>> Am personally more into House/Dubstep/EDM/etc.
>>
>>
>> When I was younger, I was kinda into Goth (was mostly Synthpop based
>> at the time, I guess vs an older Rock/Metal based style). I guess when
>> I got a little older though, I ended up taking issue with the genre's
>> almost cult-like obsession with vampires and occult topics.
>>
>>
>> Well, and I guess at some point I went from seeing existence through a
>> primarily negative lens, to being more neutral. Say, where in the
>> greater scheme of thing, ones' existence is mostly meaningless, but
>> like at least one can try to make the best of it; like it doesn't do
>> much good to spend all of ones' time being caught up in ones'
>> existence being ultimately meaningless, etc.
>>
>>
>> Unlike some people, could really never make the jump to believing
>> there is intrinsic value in anything; but will at least to claim that
>> a sort of localized value exists (say, things can have value so long
>> as there are still people to take value in them).
>>
>> Well, or, say, value exists for humans in much the same way as
>> software exists for computers. If there were no computers, there would
>> not be any way for software to exist, but as long as they exist, so
>> too does the software they contain.
>>
>> Well, ignoring any religious / theological arguments; ultimately can't
>> take a solid stance on this; nor is it entirely obvious whether this
>> is enough to justify a claim that intrinsic value exists, or if it
>> merely changes the scope slightly.
>>
>> I guess I loosely identify with existentialism, but also disagree with
>> their tendency to assign emotional/subjective qualities to existence
>> being (ultimately) meaningless (basically "smells" too much like the
>> same sort of underlying philosophy as the goth subculture). Say, the
>> lack of meaning not being any sort of malice, but rather, nothing
>> whatsoever (can't assign malice to something which doesn't really
>> exist in the first place).
>>
>>
>> Not quite figured out how other people think in these areas.
>> Sometimes I am left with some inward facing concerns as to "who I am",
>> but am then left to no real way to "fix" them nor with any real way
>> that they are "fixable".
>>
>> Torn between trying to go into this topic, but it is an difficult
>> area, and I am kinda really needing to go to sleep...
>>
>> Kinda really need to sleep, I guess now is probably not the right time
>> to go into my thoughts here.
>

( Didn't get much sleep, not an ideal scenario... )

> There's extrinsic meaning (or lack thereof), or there's intrinsic
> meaning, that one asserts. "Yes life has meaning, because I say it does".

Yeah, I can believe in extrinsic meaning at least.

I am socially expected to believe in intrinsic meaning, except:
There isn't a whole lot of evidence to support it;
Things like moral ethics turn into a big convoluted mess if one assumes
it exists;
The model is a lot simpler if one assumes that only extrinsic value exists.

But, one is then left to say to others, "I value you because you are
useful to me, I hope I can also be of some use."

But, if one expresses it this way, people tend to respond like you just
crapped in their coffee. This is not ideal either, but it is hard to see
it any other way; say if one looks at their own thoughts, can't find any
'intrinsic' motives that are not in some way self-serving. One may find
they have no reason to care about their well-being other than how they
might be useful, and they have no reason to care about oneself either.

One can see that another person is upset, but then realize that they
can't relate to their feelings in these areas. Best one can do is limit
interactions, maybe try to stay on friendly terms, but then live in a
world where most people will eventually turn hostile.

Like, say, what if my emotional landscape looks about like the surface
of the moon?... I can't fix this...

One can try to act friendly towards people, but then also note that
ones' "baseline" interaction style tend to come off as abrasive and
impersonal. But, this becomes a "litmus test" of sorts, it isn't really
worthwhile trying to interact with people who demand that one maintains
a sort of false persona (and even if they do, these sorts of people tend
to turn hostile in the end).

On 9/9/2022 11:07 AM, BGB wrote:
> On 9/9/2022 5:12 AM, Ivan Godard wrote:
>> On 9/9/2022 2:55 AM, BGB wrote:
>>> On 9/8/2022 4:39 PM, MitchAlsup wrote:
>>>> On Thursday, September 8, 2022 at 1:30:22 PM UTC-5, BGB wrote:
>>>>> On 9/8/2022 9:14 AM, MitchAlsup wrote:
>>>>>> On Wednesday, September 7, 2022 at 9:39:06 PM UTC-5, Ivan Godard
>>>>>> wrote:
>>>> <snip>
>>>>> If I were not using my current scheme, would probably go for
>>>>> something like:
>>>>> BZ Rn, label //Branch if Rn==0
>>>>> BNZ Rn, label //Branch if Rn!=0
>>>>> BGE Rn, label //Branch if Rn>=0 (Sign=0)
>>>>> BLT Rn, label //Branch if Rn< 0 (Sign=1)
>>>>>
>>>>> Average case would still be 2 instructions for compare-and-branch, and
>>>>> it would be cheaper for hardware than the strategy used by RISC-V.
>>>>>
>>>>>
>>>>> Supporting arbitrary bits could be useful, estimated cost ~ 30 LUTs
>>>>> (vs
>>>>> ~ 14 LUTs for an Rn==0 check). Could reduce many "if(x&mask)"
>>>>> operations
>>>>> to a single branch, but would likely still need an (Rn==0) / (Rn!=0)
>>>>> check to deal with the general cases.
>>>>>
>>>>> Less cost and latency either way than requiring a relative comparison.
>>>>>
>>>>>
>>>>> With the mechanism above, say:
>>>>> if(x)
>>>>> BNZ x, lbl
>>>>> if(!x)
>>>>> BZ x, lbl
>>>>> if(x&mask)
>>>>> AND x, mask, t
>>>>> BNZ t, lbl
>>>>> if(!(x&mask))
>>>>> AND x, mask, t
>>>>> BZ t, lbl
>>>>> if(x==y)
>>>>> SUB x, y, t
>>>>> BZ t, lbl
>>>>> if(x!=y)
>>>>> SUB x, y, t
>>>>> BNZ t, lbl
>>>>> if(x<y)
>>>>> SUB x, y, t
>>>>> BLT t, lbl
>>>>> if(x>y)
>>>>> SUB y, x, t
>>>>> BLT t, lbl
>>>>> if(x<=y)
>>>>> SUB y, x, t
>>>>> BGE t, lbl
>>>>> if(x>=y)
>>>>> SUB x, y, t
>>>>> BGE t, lbl
>>>>>
>>>>> Assuming 64-bit, would need dedicated compare ops for 64-bit
>>>>> comparisons
>>>>> (for 32-bit, SUB should work assuming 32-bit values are kept sign or
>>>>> zero extended).
>>>>>
>>>>> Constant cases would be similar, except:
>>>>> if(x>c) ..
>>>>> if(x<=c) ..
>>>>>
>>>>> Can't be directly encoded in 2 ops if we only have:
>>>>> SUB Rm, imm, Rn // Rn=Rm-Imm
>>>>> Would likely also need:
>>>>> RSUB Rm, imm, Rn // Rn=Imm-Rm
>>>>>
>>>
>>> I was initially looking at stuff, and reverse-subtract cases
>>> initially seemed rare.
>>>
>>> But, I added a mock-up pseudo-instruction (faked by a constant load
>>> followed by a 3R subtract), and modified the 3AC->ASM code to try to
>>> use it.
>>>
>>> Then suddenly they appeared all over the place, along with a
>>> noticeable improvement in Doom framerates (and a slight decrease in
>>> the Load/Store density).
>>>
>>> It seems like reverse subtracts weren't quite as rare as I thought,
>>> and it was also seemingly adversely effecting the register allocator
>>> (which would handle the constants in these cases by treating them
>>> like they were variables; albeit ones' without any backing memory; so
>>> they simply disappear when evicted, and generate a constant-load when
>>> used again).
>>>
>>>
>>> Goes and adds the actual instruction as a test, seems it is still
>>> pretty far down the ranking (still nowhere near as common as most of
>>> the other ALU ops).
>>>
>>> It seems like the gains were more likely due to not dealing with
>>> these constants via the register allocator, than due to any
>>> particular merit of the instruction itself.
>>>
>>>
>>>> "Breakdown, go ahead and give it to me
>>>> Breakdown, honey, take me through the night" Tom Petty and the
>>>> Heartbreakers....
>>>
>>> Not really heard much of Tom Petty, I think my parents like his music
>>> though.
>>>
>>> Am personally more into House/Dubstep/EDM/etc.
>>>
>>>
>>> When I was younger, I was kinda into Goth (was mostly Synthpop based
>>> at the time, I guess vs an older Rock/Metal based style). I guess
>>> when I got a little older though, I ended up taking issue with the
>>> genre's almost cult-like obsession with vampires and occult topics.
>>>
>>>
>>> Well, and I guess at some point I went from seeing existence through
>>> a primarily negative lens, to being more neutral. Say, where in the
>>> greater scheme of thing, ones' existence is mostly meaningless, but
>>> like at least one can try to make the best of it; like it doesn't do
>>> much good to spend all of ones' time being caught up in ones'
>>> existence being ultimately meaningless, etc.
>>>
>>>
>>> Unlike some people, could really never make the jump to believing
>>> there is intrinsic value in anything; but will at least to claim that
>>> a sort of localized value exists (say, things can have value so long
>>> as there are still people to take value in them).
>>>
>>> Well, or, say, value exists for humans in much the same way as
>>> software exists for computers. If there were no computers, there
>>> would not be any way for software to exist, but as long as they
>>> exist, so too does the software they contain.
>>>
>>> Well, ignoring any religious / theological arguments; ultimately
>>> can't take a solid stance on this; nor is it entirely obvious whether
>>> this is enough to justify a claim that intrinsic value exists, or if
>>> it merely changes the scope slightly.
>>>
>>> I guess I loosely identify with existentialism, but also disagree
>>> with their tendency to assign emotional/subjective qualities to
>>> existence being (ultimately) meaningless (basically "smells" too much
>>> like the same sort of underlying philosophy as the goth subculture).
>>> Say, the lack of meaning not being any sort of malice, but rather,
>>> nothing whatsoever (can't assign malice to something which doesn't
>>> really exist in the first place).
>>>
>>>
>>> Not quite figured out how other people think in these areas.
>>> Sometimes I am left with some inward facing concerns as to "who I
>>> am", but am then left to no real way to "fix" them nor with any real
>>> way that they are "fixable".
>>>
>>> Torn between trying to go into this topic, but it is an difficult
>>> area, and I am kinda really needing to go to sleep...
>>>
>>> Kinda really need to sleep, I guess now is probably not the right
>>> time to go into my thoughts here.
>>
>
> ( Didn't get much sleep, not an ideal scenario... )
>
>> There's extrinsic meaning (or lack thereof), or there's intrinsic
>> meaning, that one asserts. "Yes life has meaning, because I say it does".
>
> Yeah, I can believe in extrinsic meaning at least.
>
>
> I am socially expected to believe in intrinsic meaning, except:
> There isn't a whole lot of evidence to support it;

It's intrinsic; it needs no evidence. You deem it good because you have
defined what good is.

> Things like moral ethics turn into a big convoluted mess if one assumes
> it exists;
> The model is a lot simpler if one assumes that only extrinsic value exists.

Pure intrinsic is simple too.

> But, one is then left to say to others, "I value you because you are
> useful to me, I hope I can also be of some use."

"I value you because in the cosmology I have created valuing you makes a
satisfying cosmology"

On Friday, September 9, 2022 at 2:21:51 PM UTC-5, Ivan Godard wrote:
<merciful snip>
> >
> The challenge is to define a cosmology in which lameness is possible but
<
s/cosmology/ontology/
<
> is nevertheless fair. One such is the great judge in the sky that
> magically retitrates all earthly unfairness back to a neutral moral ph.
> I happen to find that design unsatisfying for other reasons, but it is
> at least fair.
<
Infinite punishment for finite crimes is "fair" ?!?

On 9/9/2022 2:21 PM, Ivan Godard wrote:
> On 9/9/2022 11:07 AM, BGB wrote:
>> On 9/9/2022 5:12 AM, Ivan Godard wrote:
>>> On 9/9/2022 2:55 AM, BGB wrote:
>>>> On 9/8/2022 4:39 PM, MitchAlsup wrote:
>>>>> On Thursday, September 8, 2022 at 1:30:22 PM UTC-5, BGB wrote:
>>>>>> On 9/8/2022 9:14 AM, MitchAlsup wrote:
>>>>>>> On Wednesday, September 7, 2022 at 9:39:06 PM UTC-5, Ivan Godard
>>>>>>> wrote:
>>>>> <snip>
>>>>>> If I were not using my current scheme, would probably go for
>>>>>> something like:
>>>>>> BZ Rn, label //Branch if Rn==0
>>>>>> BNZ Rn, label //Branch if Rn!=0
>>>>>> BGE Rn, label //Branch if Rn>=0 (Sign=0)
>>>>>> BLT Rn, label //Branch if Rn< 0 (Sign=1)
>>>>>>
>>>>>> Average case would still be 2 instructions for compare-and-branch,
>>>>>> and
>>>>>> it would be cheaper for hardware than the strategy used by RISC-V.
>>>>>>
>>>>>>
>>>>>> Supporting arbitrary bits could be useful, estimated cost ~ 30
>>>>>> LUTs (vs
>>>>>> ~ 14 LUTs for an Rn==0 check). Could reduce many "if(x&mask)"
>>>>>> operations
>>>>>> to a single branch, but would likely still need an (Rn==0) / (Rn!=0)
>>>>>> check to deal with the general cases.
>>>>>>
>>>>>> Less cost and latency either way than requiring a relative
>>>>>> comparison.
>>>>>>
>>>>>>
>>>>>> With the mechanism above, say:
>>>>>> if(x)
>>>>>> BNZ x, lbl
>>>>>> if(!x)
>>>>>> BZ x, lbl
>>>>>> if(x&mask)
>>>>>> AND x, mask, t
>>>>>> BNZ t, lbl
>>>>>> if(!(x&mask))
>>>>>> AND x, mask, t
>>>>>> BZ t, lbl
>>>>>> if(x==y)
>>>>>> SUB x, y, t
>>>>>> BZ t, lbl
>>>>>> if(x!=y)
>>>>>> SUB x, y, t
>>>>>> BNZ t, lbl
>>>>>> if(x<y)
>>>>>> SUB x, y, t
>>>>>> BLT t, lbl
>>>>>> if(x>y)
>>>>>> SUB y, x, t
>>>>>> BLT t, lbl
>>>>>> if(x<=y)
>>>>>> SUB y, x, t
>>>>>> BGE t, lbl
>>>>>> if(x>=y)
>>>>>> SUB x, y, t
>>>>>> BGE t, lbl
>>>>>>
>>>>>> Assuming 64-bit, would need dedicated compare ops for 64-bit
>>>>>> comparisons
>>>>>> (for 32-bit, SUB should work assuming 32-bit values are kept sign or
>>>>>> zero extended).
>>>>>>
>>>>>> Constant cases would be similar, except:
>>>>>> if(x>c) ..
>>>>>> if(x<=c) ..
>>>>>>
>>>>>> Can't be directly encoded in 2 ops if we only have:
>>>>>> SUB Rm, imm, Rn // Rn=Rm-Imm
>>>>>> Would likely also need:
>>>>>> RSUB Rm, imm, Rn // Rn=Imm-Rm
>>>>>>
>>>>
>>>> I was initially looking at stuff, and reverse-subtract cases
>>>> initially seemed rare.
>>>>
>>>> But, I added a mock-up pseudo-instruction (faked by a constant load
>>>> followed by a 3R subtract), and modified the 3AC->ASM code to try to
>>>> use it.
>>>>
>>>> Then suddenly they appeared all over the place, along with a
>>>> noticeable improvement in Doom framerates (and a slight decrease in
>>>> the Load/Store density).
>>>>
>>>> It seems like reverse subtracts weren't quite as rare as I thought,
>>>> and it was also seemingly adversely effecting the register allocator
>>>> (which would handle the constants in these cases by treating them
>>>> like they were variables; albeit ones' without any backing memory;
>>>> so they simply disappear when evicted, and generate a constant-load
>>>> when used again).
>>>>
>>>>
>>>> Goes and adds the actual instruction as a test, seems it is still
>>>> pretty far down the ranking (still nowhere near as common as most of
>>>> the other ALU ops).
>>>>
>>>> It seems like the gains were more likely due to not dealing with
>>>> these constants via the register allocator, than due to any
>>>> particular merit of the instruction itself.
>>>>
>>>>
>>>>> "Breakdown, go ahead and give it to me
>>>>> Breakdown, honey, take me through the night" Tom Petty and the
>>>>> Heartbreakers....
>>>>
>>>> Not really heard much of Tom Petty, I think my parents like his
>>>> music though.
>>>>
>>>> Am personally more into House/Dubstep/EDM/etc.
>>>>
>>>>
>>>> When I was younger, I was kinda into Goth (was mostly Synthpop based
>>>> at the time, I guess vs an older Rock/Metal based style). I guess
>>>> when I got a little older though, I ended up taking issue with the
>>>> genre's almost cult-like obsession with vampires and occult topics.
>>>>
>>>>
>>>> Well, and I guess at some point I went from seeing existence through
>>>> a primarily negative lens, to being more neutral. Say, where in the
>>>> greater scheme of thing, ones' existence is mostly meaningless, but
>>>> like at least one can try to make the best of it; like it doesn't do
>>>> much good to spend all of ones' time being caught up in ones'
>>>> existence being ultimately meaningless, etc.
>>>>
>>>>
>>>> Unlike some people, could really never make the jump to believing
>>>> there is intrinsic value in anything; but will at least to claim
>>>> that a sort of localized value exists (say, things can have value so
>>>> long as there are still people to take value in them).
>>>>
>>>> Well, or, say, value exists for humans in much the same way as
>>>> software exists for computers. If there were no computers, there
>>>> would not be any way for software to exist, but as long as they
>>>> exist, so too does the software they contain.
>>>>
>>>> Well, ignoring any religious / theological arguments; ultimately
>>>> can't take a solid stance on this; nor is it entirely obvious
>>>> whether this is enough to justify a claim that intrinsic value
>>>> exists, or if it merely changes the scope slightly.
>>>>
>>>> I guess I loosely identify with existentialism, but also disagree
>>>> with their tendency to assign emotional/subjective qualities to
>>>> existence being (ultimately) meaningless (basically "smells" too
>>>> much like the same sort of underlying philosophy as the goth
>>>> subculture). Say, the lack of meaning not being any sort of malice,
>>>> but rather, nothing whatsoever (can't assign malice to something
>>>> which doesn't really exist in the first place).
>>>>
>>>>
>>>> Not quite figured out how other people think in these areas.
>>>> Sometimes I am left with some inward facing concerns as to "who I
>>>> am", but am then left to no real way to "fix" them nor with any real
>>>> way that they are "fixable".
>>>>
>>>> Torn between trying to go into this topic, but it is an difficult
>>>> area, and I am kinda really needing to go to sleep...
>>>>
>>>> Kinda really need to sleep, I guess now is probably not the right
>>>> time to go into my thoughts here.
>>>
>>
>> ( Didn't get much sleep, not an ideal scenario... )
>>
>>> There's extrinsic meaning (or lack thereof), or there's intrinsic
>>> meaning, that one asserts. "Yes life has meaning, because I say it
>>> does".
>>
>> Yeah, I can believe in extrinsic meaning at least.
>>
>>
>> I am socially expected to believe in intrinsic meaning, except:
>> There isn't a whole lot of evidence to support it;
>
> It's intrinsic; it needs no evidence. You deem it good because you have
> defined what good is.
>

On 9/9/2022 1:13 PM, MitchAlsup wrote:
> On Friday, September 9, 2022 at 2:21:51 PM UTC-5, Ivan Godard wrote:
> <merciful snip>
>>>
>> The challenge is to define a cosmology in which lameness is possible but
> <
> s/cosmology/ontology/
> <
>> is nevertheless fair. One such is the great judge in the sky that
>> magically retitrates all earthly unfairness back to a neutral moral ph.
>> I happen to find that design unsatisfying for other reasons, but it is
>> at least fair.
> <
> Infinite punishment for finite crimes is "fair" ?!?

Yes, because it applies equally to all. Whether it is just is another
matter.

On 9/9/2022 3:13 PM, MitchAlsup wrote:
> On Friday, September 9, 2022 at 2:21:51 PM UTC-5, Ivan Godard wrote:
> <merciful snip>
>>>
>> The challenge is to define a cosmology in which lameness is possible but
> <
> s/cosmology/ontology/

This would make more sense.

An ontology would mean the intrinsics are themselves an abstraction,
rather than claiming they are somehow anchored to the greater universe.

Many of the people asserting moral philosophies were also trying to
claim that their particular philosophy represented the universe as a
whole, rather than more simply as an organizing construct.

Asserting a non-existence of intrinsics works, as it makes no particular
claim about the greater universe.

One could try to claim it is a form of nihilism, but:
If nihilism were strictly true, one couldn't actually argue about
whether or not nihilism were true, it would exclude the possibility of
even raising the question.

Ultimately, it would itself (seemingly) decay into a form of
existentialism if for no other reason than this is what would be
required to be able to talk about it in the first place.

Though, I suspect in my case it would likely be classified as some sort
of existential utilitarianism. Likely differing from "traditional"
existentialism mainly in that, while I accept moral ethics as a sort of
emergent property, I see little reason to classify "the darkness" or
"the absurd" as inherently negative; rather it more represents the
distillation of "nothingness".

But, rather the more negative aspects would more likely be the result of
trying to face it while still trying to hold onto a belief in intrinsic
value. Say, if one tries to face the essence of nothingness and
meaninglessness while trying to hold on to a belief that their existence
has meaning in its own right, it can be admittedly, "kinda depressing".

I don't usually go that much into philosophy, it often doesn't go over
very well.

People believing in things like intrinsic worth and similar is,
admittedly, a whole lot more popular.

> <
>> is nevertheless fair. One such is the great judge in the sky that
>> magically retitrates all earthly unfairness back to a neutral moral ph.
>> I happen to find that design unsatisfying for other reasons, but it is
>> at least fair.
> <
> Infinite punishment for finite crimes is "fair" ?!?

There are several different ways of interpreting things, with the
different groups each claiming that that their views are "the truth".

Heaven/Hell:
Good people, Heaven;
Bad people, Hell.

Then, say, there are different definitions of what it means to be good
in this context:
Good actions (charitable actions);
Lack of bad actions (avoiding doing stuff that is immoral);
Faith alone.

Definitions differ, often the idea is that it is faith which leads to
the former. The former without the latter will not get one in the door.
Claiming to have faith but not doing the other two is seen as showing
that the persons' faith isn't actually real. Usual idea is that if one
has faith, they will feel a sense of caring towards everyone else, so of
course they would act charitably as a result (but, by themselves,
neither charitable actions, nor avoiding bad actions, is sufficient).

This seems to be the main interpretation in mainline Protestantism.

One has a problem though, if their "faith" is basically nowhere near
good enough to "pass muster" if all this is actually true (...yeah...).

Meanwhile, if the claim is that the way to Heaven involves paying large
sums of money or similar, or subservience to, to some religious leader,
chances are, this is a cult... (If the leaders also claim prophetic
visions or supernatural powers or similar, this is pretty much
guaranteed...).

Heaven/Hell/Purgatory:
Good people, Heaven;
(Really) Bad people, Hell;
(Most everyone else) Purgatory.

Here, most people go to purgatory for a while, where they get punished
for a while, but then still go off to Heaven once their time is served.

The line between purgatory and hell is fuzzy, usual idea I think is that
people who actively break the Ten Commandments rules, and don't repent
of this, are the main ones who go to hell. Getting into heaven directly
(without first going through purgatory) being more the realm of saints.

This seems more to be the general position for Catholics.

Heaven/Hell/Sheol:
Good People, Heaven;
Bad People, Hell;
Others, Sheol.

Differs slightly from Purgatory, in that it is more of a waiting ground
where one can either be eventually sent to Heaven, sent to Hell, or be
erased from existence entirely. This tends to be a little bit more of a
wildcard.

Etc...

On 9/9/2022 10:29 PM, BGB wrote:
> On 9/9/2022 3:13 PM, MitchAlsup wrote:
>> On Friday, September 9, 2022 at 2:21:51 PM UTC-5, Ivan Godard wrote:
>> <merciful snip>
>>>>
>>> The challenge is to define a cosmology in which lameness is possible but
>> <
>> s/cosmology/ontology/
>
> This would make more sense.
>
> An ontology would mean the intrinsics are themselves an abstraction,
> rather than claiming they are somehow anchored to the greater universe.
>
> Many of the people asserting moral philosophies were also trying to
> claim that their particular philosophy represented the universe as a
> whole, rather than more simply as an organizing construct.
>
>
> Asserting a non-existence of intrinsics works, as it makes no particular
> claim about the greater universe.
>
>
> One could try to claim it is a form of nihilism, but:
> If nihilism were strictly true, one couldn't actually argue about
> whether or not nihilism were true, it would exclude the possibility of
> even raising the question.
>
> Ultimately, it would itself (seemingly) decay into a form of
> existentialism if for no other reason than this is what would be
> required to be able to talk about it in the first place.
>
>
> Though, I suspect in my case it would likely be classified as some sort
> of existential utilitarianism. Likely differing from "traditional"
> existentialism mainly in that, while I accept moral ethics as a sort of
> emergent property, I see little reason to classify "the darkness" or
> "the absurd" as inherently negative; rather it more represents the
> distillation of "nothingness".
>
> But, rather the more negative aspects would more likely be the result of
> trying to face it while still trying to hold onto a belief in intrinsic
> value. Say, if one tries to face the essence of nothingness and
> meaninglessness while trying to hold on to a belief that their existence
> has meaning in its own right, it can be admittedly, "kinda depressing".
>
> I don't usually go that much into philosophy, it often doesn't go over
> very well.
>
>
> People believing in things like intrinsic worth and similar is,
> admittedly, a whole lot more popular.
>
>
>
>> <
>>> is nevertheless fair. One such is the great judge in the sky that
>>> magically retitrates all earthly unfairness back to a neutral moral ph.
>>> I happen to find that design unsatisfying for other reasons, but it is
>>> at least fair.
>> <
>> Infinite punishment for finite crimes is "fair" ?!?
>
> There are several different ways of interpreting things, with the
> different groups each claiming that that their views are "the truth".
>
>
> Heaven/Hell:
>   Good people, Heaven;
>   Bad people, Hell.
>
> Then, say, there are different definitions of what it means to be good
> in this context:
>   Good actions (charitable actions);
>   Lack of bad actions (avoiding doing stuff that is immoral);
>   Faith alone.
>
> Definitions differ, often the idea is that it is faith which leads to
> the former. The former without the latter will not get one in the door.
> Claiming to have faith but not doing the other two is seen as showing
> that the persons' faith isn't actually real. Usual idea is that if one
> has faith, they will feel a sense of caring towards everyone else, so of
> course they would act charitably as a result (but, by themselves,
> neither charitable actions, nor avoiding bad actions, is sufficient).
>
> This seems to be the main interpretation in mainline Protestantism.
>
>
> One has a problem though, if their "faith" is basically nowhere near
> good enough to "pass muster" if all this is actually true (...yeah...).
>
>
> Meanwhile, if the claim is that the way to Heaven involves paying large
> sums of money or similar, or subservience to, to some religious leader,
> chances are, this is a cult... (If the leaders also claim prophetic
> visions or supernatural powers or similar, this is pretty much
> guaranteed...).
>
>
> Heaven/Hell/Purgatory:
>   Good people, Heaven;
>   (Really) Bad people, Hell;
>   (Most everyone else) Purgatory.
>
> Here, most people go to purgatory for a while, where they get punished
> for a while, but then still go off to Heaven once their time is served.
>
> The line between purgatory and hell is fuzzy, usual idea I think is that
> people who actively break the Ten Commandments rules, and don't repent
> of this, are the main ones who go to hell. Getting into heaven directly
> (without first going through purgatory) being more the realm of saints.
>
> This seems more to be the general position for Catholics.
>
>
> Heaven/Hell/Sheol:
>   Good People, Heaven;
>   Bad People, Hell;
>   Others, Sheol.
>
> Differs slightly from Purgatory, in that it is more of a waiting ground
> where one can either be eventually sent to Heaven, sent to Hell, or be
> erased from existence entirely. This tends to be a little bit more of a
> wildcard.
>
> Etc...
>

You have a different meaning for "intrinsic" than I do - as discovered,
while I mean as asserted.

Design the universe the way you want it to work, then live as if you
were in that universe.

On 9/10/2022 6:25 AM, Ivan Godard wrote:
> On 9/9/2022 10:29 PM, BGB wrote:
>> On 9/9/2022 3:13 PM, MitchAlsup wrote:
>>> On Friday, September 9, 2022 at 2:21:51 PM UTC-5, Ivan Godard wrote:
>>> <merciful snip>
>>>>>
>>>> The challenge is to define a cosmology in which lameness is possible
>>>> but
>>> <
>>> s/cosmology/ontology/
>>
>> This would make more sense.
>>
>> An ontology would mean the intrinsics are themselves an abstraction,
>> rather than claiming they are somehow anchored to the greater universe.
>>
>> Many of the people asserting moral philosophies were also trying to
>> claim that their particular philosophy represented the universe as a
>> whole, rather than more simply as an organizing construct.
>>
>>
>> Asserting a non-existence of intrinsics works, as it makes no
>> particular claim about the greater universe.
>>
>>
>> One could try to claim it is a form of nihilism, but:
>> If nihilism were strictly true, one couldn't actually argue about
>> whether or not nihilism were true, it would exclude the possibility of
>> even raising the question.
>>
>> Ultimately, it would itself (seemingly) decay into a form of
>> existentialism if for no other reason than this is what would be
>> required to be able to talk about it in the first place.
>>
>>
>> Though, I suspect in my case it would likely be classified as some
>> sort of existential utilitarianism. Likely differing from
>> "traditional" existentialism mainly in that, while I accept moral
>> ethics as a sort of emergent property, I see little reason to classify
>> "the darkness" or "the absurd" as inherently negative; rather it more
>> represents the distillation of "nothingness".
>>
>> But, rather the more negative aspects would more likely be the result
>> of trying to face it while still trying to hold onto a belief in
>> intrinsic value. Say, if one tries to face the essence of nothingness
>> and meaninglessness while trying to hold on to a belief that their
>> existence has meaning in its own right, it can be admittedly, "kinda
>> depressing".
>>
>> I don't usually go that much into philosophy, it often doesn't go over
>> very well.
>>
>>
>> People believing in things like intrinsic worth and similar is,
>> admittedly, a whole lot more popular.
>>
>>
>>
>>> <
>>>> is nevertheless fair. One such is the great judge in the sky that
>>>> magically retitrates all earthly unfairness back to a neutral moral ph.
>>>> I happen to find that design unsatisfying for other reasons, but it is
>>>> at least fair.
>>> <
>>> Infinite punishment for finite crimes is "fair" ?!?
>>
>> There are several different ways of interpreting things, with the
>> different groups each claiming that that their views are "the truth".
>>
>>
>> Heaven/Hell:
>>    Good people, Heaven;
>>    Bad people, Hell.
>>
>> Then, say, there are different definitions of what it means to be good
>> in this context:
>>    Good actions (charitable actions);
>>    Lack of bad actions (avoiding doing stuff that is immoral);
>>    Faith alone.
>>
>> Definitions differ, often the idea is that it is faith which leads to
>> the former. The former without the latter will not get one in the
>> door. Claiming to have faith but not doing the other two is seen as
>> showing that the persons' faith isn't actually real. Usual idea is
>> that if one has faith, they will feel a sense of caring towards
>> everyone else, so of course they would act charitably as a result
>> (but, by themselves, neither charitable actions, nor avoiding bad
>> actions, is sufficient).
>>
>> This seems to be the main interpretation in mainline Protestantism.
>>
>>
>> One has a problem though, if their "faith" is basically nowhere near
>> good enough to "pass muster" if all this is actually true (...yeah...).
>>
>>
>> Meanwhile, if the claim is that the way to Heaven involves paying
>> large sums of money or similar, or subservience to, to some religious
>> leader, chances are, this is a cult... (If the leaders also claim
>> prophetic visions or supernatural powers or similar, this is pretty
>> much guaranteed...).
>>
>>
>> Heaven/Hell/Purgatory:
>>    Good people, Heaven;
>>    (Really) Bad people, Hell;
>>    (Most everyone else) Purgatory.
>>
>> Here, most people go to purgatory for a while, where they get punished
>> for a while, but then still go off to Heaven once their time is served.
>>
>> The line between purgatory and hell is fuzzy, usual idea I think is
>> that people who actively break the Ten Commandments rules, and don't
>> repent of this, are the main ones who go to hell. Getting into heaven
>> directly (without first going through purgatory) being more the realm
>> of saints.
>>
>> This seems more to be the general position for Catholics.
>>
>>
>> Heaven/Hell/Sheol:
>>    Good People, Heaven;
>>    Bad People, Hell;
>>    Others, Sheol.
>>
>> Differs slightly from Purgatory, in that it is more of a waiting
>> ground where one can either be eventually sent to Heaven, sent to
>> Hell, or be erased from existence entirely. This tends to be a little
>> bit more of a wildcard.
>>
>> Etc...
>>
>
> You have a different meaning for "intrinsic" than I do - as discovered,
> while I mean as asserted.
>
> Design the universe the way you want it to work, then live as if you
> were in that universe.

AFAIK, the way I am using it is consistent with how it is usually used
in deontology style systems, where usually the assumption isn't just "A
is good because we assert it is good", but rather they assume that
either the universe or itself mandates that A is good or B is bad.

Something like Asimov's Three Laws being an example of a ridiculously
simplified version of such a system (and I also suspect its instability
likely being intentional part of its design; say, to make for more
interesting plot scenarios than one that "actually works as intended").

From what I can tell, most people seem to believe in this approach.

And, some people take it a little too far:
Hassidic Judaism, the Amish, etc, being examples of what can happen;
Fundamentalist Christianity also seems headed down this road;
Well, also Islamic Sharia law, etc;
...

One also doesn't necessarily want these sorts of systems to be put into
a place of authority over a society, as the results are usually not ideal.

Note though, that the problem is not necessarily due to people taking
the Bible too seriously, and (if anything) it on multiple occasions
basically says not to do this (warnings against "building a hedge around
the law", etc), but people ignore this part and do it anyways (and often
seemingly missing the point of the original rule in the first place).

The specifics differ, but still have the same underlying sorts of
issues. Everyone then takes it for granted that "morals just work that
way", never questioning that maybe some of their underlying assumptions
are broken.

Meanwhile, while secular law tends to follow a similar structure, people
are at least more open to acknowledge that it is a social construct and
are more willing to accept changes (laws get passed, something is now
legal or now illegal as a result, ...). Then there are legislative
structures, court of law, etc, for this purpose.

This tolerance to change is typically much less so with moral ethics.

For example, I can predict that there is (quite likely) to be a
religious/cultural opposition to things like cultured meat products,
once they become more widespread, because (in most ways of growing them)
they are a non-trivial violation of the Noahide laws, etc.

Similar issues would likely also apply to things like external
gestation, etc, as well.

My own views took a different approach, assuming not so much that the
values are handed down from "on high", but rather are themselves
emergent properties, based on the properties and constraints of humanity
as seen within the context of a hierarchical social structure.

In this case, the traditional rules make sense (significant deviation
being detrimental to the common good, etc).

BGB wrote:
> I was initially looking at stuff, and reverse-subtract cases initially
> seemed rare.

They are not!
>
> But, I added a mock-up pseudo-instruction (faked by a constant load
> followed by a 3R subtract), and modified the 3AC->ASM code to try to use
> it.
>
> Then suddenly they appeared all over the place, along with a noticeable
> improvement in Doom framerates (and a slight decrease in the Load/Store
> density).
>
> It seems like reverse subtracts weren't quite as rare as I thought, and
> it was also seemingly adversely effecting the register allocator (which
> would handle the constants in these cases by treating them like they
> were variables; albeit ones' without any backing memory; so they simply
> disappear when evicted, and generate a constant-load when used again).

I have desired reverse subtract quite often in inner loops, anywhere I'm
calculating the remaining space (bits/bytes) in a buffer: This is of
course exacerbated by x86 having only 2-reg instructions, but it also
comes into play when the value to be subtracted from is a constant.

Mitch's sign control is a beautiful solution, particularly since it
unlike the "free shift" in the original ARM doesn't actually add any
clock cycle time pressure.

Terje

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

On 9/12/2022 1:00 AM, Terje Mathisen wrote:
> BGB wrote:
>> I was initially looking at stuff, and reverse-subtract cases initially
>> seemed rare.
>
> They are not!

They seem to be in a gray area of neither particularly rare nor
particularly common.

Compared with normal ADD/SUB (in "Reg,Imm,Reg" form), they are rare.

If compared with a lot of more obscure operations, they are pretty common.

They seem to have a similar usage frequency to the 64-bit CMPQxx
operations and similar; when enabled, hanging around at around 0.1 to
0.3% of the cycle budget.

Added FPGA cost from decoding them is pretty small, but in this case it
is more a question of if they justify spending one of the last few Imm9
spots (or if in the future, another instruction might come along that
has a stronger need of an Imm9 spot).

While it would be cheaper to add it as an Imm5 encoding, due to encoding
reasons and a lot of the constants I was seeing, this would have made it
much less useful. Similar also applies to 2RI.

Where it looked like only spending an Imm9 spot on it would give it a
significant encoding advantage over faking it with a 2 instruction sequence.

Though, ironically, faking it via a pseudo instruction still seems to
offer a performance advantage over using the register allocator to treat
the constant like it was a variable.

>>
>> But, I added a mock-up pseudo-instruction (faked by a constant load
>> followed by a 3R subtract), and modified the 3AC->ASM code to try to
>> use it.
>>
>> Then suddenly they appeared all over the place, along with a
>> noticeable improvement in Doom framerates (and a slight decrease in
>> the Load/Store density).
>>
>> It seems like reverse subtracts weren't quite as rare as I thought,
>> and it was also seemingly adversely effecting the register allocator
>> (which would handle the constants in these cases by treating them like
>> they were variables; albeit ones' without any backing memory; so they
>> simply disappear when evicted, and generate a constant-load when used
>> again).
>
> I have desired reverse subtract quite often in inner loops, anywhere I'm
> calculating the remaining space (bits/bytes) in a buffer: This is of
> course exacerbated by x86 having only 2-reg instructions, but it also
> comes into play when the value to be subtracted from is a constant.
>
> Mitch's sign control is a beautiful solution, particularly since it
> unlike the "free shift" in the original ARM doesn't actually add any
> clock cycle time pressure.
>

OK, I don't have anything similar in my case.

Was also recently able to get another speedup by adding
loop-nesting-depth handling to the logic for tracing out and ranking
global variables (vs ranking them more simply by the number of times
they are referenced in the program being compiled).

This seems better able to consolidate commonly-accessed global variables
in a smaller area of memory, and seems to somewhat improve L1 hit rates
in Doom and similar.

Quake: Doesn't care about this.

Dhrystone: Doesn't care (already nearly 100% hit rate as-is).

Have noticed that it is a little faster if I turn on some aliasing
related optimizations, though BGBCC is still fairly conservative in this
area (this was mostly enabling struct-field caching and similar, vs the
"always do every load every time" semantics).

Recently was generally getting around 73k at 50MHz (not exactly great,
would need to get it up to ~ 115k at 50MHz to match RISC-V numbers here).

Could maybe be better if BGBCC didn't need to evict all the global
variables and similar at the end of every basic-block; but this is
easier said than done.

Unlike local variables, the "static assign variable to a CPU register"
trick doesn't work.

Have also noted that there seem to be edge cases where constant
expressions are leaking into the generated machine code, which ideally
shouldn't happen.

Well, and there are likewise scenarios where expression association
fails to evaluate (potential) constant cases:
y=x+3-5;
Could in theory be turned into:
y=x-2;
Except that the parser uses left-to-right associativity and thus the
constant parts of the expression don't get evaluated in the same way
that "y=x+(3-5);" would have been.

....

> Terje
>

On 2022-09-08, Stefan Monnier wrote:
>> Most ISAs (ignoring those with implicit CCs) have a bunch of compare ops and
>> one- or two-way branches. Mitch has one compare op and a multi-test
>> branch. ISTM that there's no gain in entropy either way, although one or the
>> other may pack better if the ISA is stuck with fixed size instructions. Yes?
>
> A difference I can see is:
> - with the test encoded together with the compare operation, you have
> N possible tests to encode.
> - with the test encoded as a bit-select in the branch, you have
> M possible bits to select.
> Say you only support 8 different tests, but your words are 64bits,
> that's a difference of 3bit vs 6bits.
>
> Then another difference is when a single compare's results are used in
> N subsequent branches, in which case you save the repetition of
> the operands compared to the scheme where you need to perform
> N different comparisons.
>
> I don't think either factor will make much difference in real life, tho.
>

In MRISC32 I went with many tests (signed/unsigned integer EQ, LT, LE,
floating-point EQ, LT, ORDERED, ...), along with a bunch of different
branches (test SET/NOT-SET, signed integer ZERO, NOT-ZERO, LTZ, GTEZ,
etc).

That way I have the classical two-instruction sequence for most
conditional branches (TEST + BRANCH-IF-(NOT)-SET), which yields
equivalent instruction count as for most machines with a CC register.

The extra COMPARE-TO-ZERO-AND-BRANCH branch variants allows many
conditional branches to be done in a single instruction (e.g.
loop-downto-zero or skip-if-empty-array), which is an improvement
over CMP+Bcc.

The one thing that I'm not sure about, but that you are getting at, is
whether 1xCMP + NxBcc is common enough to warrant encoding multiple
comparison results in a single CMP instruction, rather than requiring
multiple SETcc instructions. In my experience it's not common enough to
make a difference - but that's just my gut feeling.

The main reason that I went with multiple SETcc instructions is that I
use the exact same instructions for Vector/SIMD comparisons, where you
typically want masks (per element true/false).

/Marcus

On 2022-09-09, BGB wrote:
> On 9/8/2022 4:39 PM, MitchAlsup wrote:
>> On Thursday, September 8, 2022 at 1:30:22 PM UTC-5, BGB wrote:
>>> On 9/8/2022 9:14 AM, MitchAlsup wrote:
>>>> On Wednesday, September 7, 2022 at 9:39:06 PM UTC-5, Ivan Godard wrote:
>> <snip>

<snip>

>
>> "Breakdown, go ahead and give it to me
>> Breakdown, honey, take me through the night" Tom Petty and the
>> Heartbreakers....
>
> Not really heard much of Tom Petty, I think my parents like his music
> though.
>
> Am personally more into House/Dubstep/EDM/etc.
>
>
> When I was younger, I was kinda into Goth (was mostly Synthpop based at
> the time, I guess vs an older Rock/Metal based style). I guess when I
> got a little older though, I ended up taking issue with the genre's
> almost cult-like obsession with vampires and occult topics.
>

If you like modern retro Synthwave/Chip/Dubstep you might enjoy this
Polish guy, LukHash, that never seems to run out of energy (I recently
found the music via my fancy for Commodore 64 music covers, of which he
has made a few):

https://youtu.be/o54xftPSwmA

On another topic, did you include an instruction for integer-subtract-
immediate-from-register-value, and if so, why? I only have
integer-subtract-register-value-from-immediate (a.k.a RSB in the ARM
world). I figured that integer-add-immediate-to-register-value works
just as well for subtracting immediates (just add a negative immediate
value).

/Marcus