On Tuesday, June 13, 2023 at 9:50:10 AM UTC+3, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > On Monday, June 12, 2023 at 4:05:16 PM UTC-5, Thomas Koenig wrote:
> >> Hmm.. a couple of thoughts.
> >>
> >> Assumme we have the three-operand instructions
> >>
> >> MIN Rt,Ra,Rb,Rc
> >> MID Rt,Ra,Rb,Rc
> >> MAX Rt,Ra,Rb,Rc
> ><
> > In the 1980s and very early '90s, some designers thought about using
> > CAM sort arrays* in hardware. Software would load up a number of
> > values and write them into the "sorter", after loading all values, soft-
> > ware would read out all the value in order. No instruction was needed
> > to cause the sorter to sort, the writing of values in performed sorting..
> ><
> > These never went anywhere--draw your own conclusions.
> The pendulum of reintegration swung the other way, quickly.
>
> Although there appears to be a SORTL instruction on zSystem, according to
> https://blog.share.org/Article/peeking-under-the-hood-of-sort-acceleration-on-z15
> which appears to bring some improvement, so...
> ><
> > (*) CAMs can be made to do things other than exact match detection.
> Interesting.
>
> MIN and MAX of three registers is straightforward two instructions,
> but MID is more challenging. It could be something like
>
> MIN Rtmp1,Ra,Rb
> MIN Rtmp2,Ra,Rc
> MIN Rtmp3,Rb,Rc
> MAX Rtmp1,Rt1,Rt2
> MAX Rtmp1,Rt1,Rt3
>
> with (assuming single-cycle latency) anything between three
> (for a sufficiently wide OoO machine) and five cycles of latency.
>
> The last two instructions would be a three-way MAX, so this
> could be shortened to
>
> MIN Rtmp1,Ra,Rb
> MIN Rtmp2,Ra,Rc
> MIN Rtmp3,Rb,Rc
> MAX Rtmp1,Rtmp1,Rtmp2,Rttmp3
>
> in that case, for between two and four cycles (assuming that
> three-way MAX is a single cycle). For OoO, MID is then probably
> not worth it, especially if it is can not be done in a single
> cycle.
>
> Three-way sort could then be
>
> MIN Rmin,Ra,Rb,Rc
> MAX Rmax,Ra,Rb,Rc
> MIN Rtmp1,Ra,Rb
> MIN Rtmp2,Ra,Rc
> MIN Rtmp3,Rb,Rc
> MAX Rmid,Rtmp1,Rtmp2,Rttmp3
>
> so between two and six cycles.

The key question is: how often do people sort arrays of numbers?
My guess is, in fields of signal and image processing they do it not very
rarely, but also not often. And typical size here is from 2-3 to low hundreds.

In other fields of computing, like commercial, scientific, data analytics,
sorting arrays of numbers is *extremely* rare.

What is not rare is sorting arrays of records by numeric key.
Of which most important case is sorting small records consisting of
numeric key and pointer-or-index.

Max and min instruction are probably far less useful in this mighty
important case then they are in less important case of sorting arrays of number.

MitchAlsup <MitchAlsup@aol.com> writes:
>On Monday, June 12, 2023 at 4:05:16=E2=80=AFPM UTC-5, Thomas Koenig wrote:
>> Hmm.. a couple of thoughts.=20
>>=20
>> Assumme we have the three-operand instructions=20
>>=20
>> MIN Rt,Ra,Rb,Rc=20
>> MID Rt,Ra,Rb,Rc=20
>> MAX Rt,Ra,Rb,Rc=20
><
>In the 1980s and very early '90s, some designers thought about using=20
>CAM sort arrays* in hardware. Software would load up a number of=20
>values and write them into the "sorter", after loading all values, soft-
>ware would read out all the value in order. No instruction was needed
>to cause the sorter to sort, the writing of values in performed sorting.
><
>These never went anywhere--draw your own conclusions.
><
>(*) CAMs can be made to do things other than exact match detection.
>>=20
>> which would, as the name suggests, select the minimum, the mitpoint=20
>> and the maximum of three values. Are these instructions which=20
>> could reasonably be done in a single cycle, and issued in parallel=20
>> on an OoO machine? That should certainly speed up three-way=20
>> sorting, if this is reasonable.=20
><
>Yours is only the 3-operand version, the array I mentioned above=20
>was 32 entry or 64 entry (its been too long).
>>=20
>> Another idea, potentially even wilder (and probably worse :-)=20
>> A "load double and sort" instruction, so=20
>>=20
>> LS Rmin,Rmax,[Rs]=20
>>=20
>> would load the maximum of [Rs] and [Rs+offs] into Rmax and the=20
>> minimum of [Rs] and [Rs+offs], with offs being the size of the=20
>> data loaded.=20
>>=20
>> Comments? Too horrible even to think about? Has been tried and=20
>> does not work because...?
><
>I, personally, do not think it a good idea to add a comparison stage=20
>to the already difficult AGEN-CACHE-ALIGN portion of the memory
>pipeline.

Well, does it have to done in the pipeline? Or at the memory
controller.

For instance, ARM64 has STSMAX (Atomic store signed maximum):

Atomic signed maximum on word in memory, without return,
atomically loads an 64-bit byte from memory, compares
it against the value held in a register, and stores the
larger value back to memory, treating the values as signed
numbers.

Granted, not particulary performant in a tight integer sort
loop.

On Tuesday, June 13, 2023 at 8:30:27 AM UTC-4, Michael S wrote:
> On Tuesday, June 13, 2023 at 9:50:10 AM UTC+3, Thomas Koenig wrote:
> > MitchAlsup <Mitch...@aol.com> schrieb:
> > > On Monday, June 12, 2023 at 4:05:16 PM UTC-5, Thomas Koenig wrote:
> > >> Hmm.. a couple of thoughts.
> > >>
> > >> Assumme we have the three-operand instructions
> > >>
> > >> MIN Rt,Ra,Rb,Rc
> > >> MID Rt,Ra,Rb,Rc
> > >> MAX Rt,Ra,Rb,Rc
> > ><
> > > In the 1980s and very early '90s, some designers thought about using
> > > CAM sort arrays* in hardware. Software would load up a number of
> > > values and write them into the "sorter", after loading all values, soft-
> > > ware would read out all the value in order. No instruction was needed
> > > to cause the sorter to sort, the writing of values in performed sorting.
> > ><
> > > These never went anywhere--draw your own conclusions.
> > The pendulum of reintegration swung the other way, quickly.
> >
> > Although there appears to be a SORTL instruction on zSystem, according to
> > https://blog.share.org/Article/peeking-under-the-hood-of-sort-acceleration-on-z15
> > which appears to bring some improvement, so...
> > ><
> > > (*) CAMs can be made to do things other than exact match detection.
> > Interesting.
> >
> > MIN and MAX of three registers is straightforward two instructions,
> > but MID is more challenging. It could be something like
> >
> > MIN Rtmp1,Ra,Rb
> > MIN Rtmp2,Ra,Rc
> > MIN Rtmp3,Rb,Rc
> > MAX Rtmp1,Rt1,Rt2
> > MAX Rtmp1,Rt1,Rt3
> >
> > with (assuming single-cycle latency) anything between three
> > (for a sufficiently wide OoO machine) and five cycles of latency.
> >
> > The last two instructions would be a three-way MAX, so this
> > could be shortened to
> >
> > MIN Rtmp1,Ra,Rb
> > MIN Rtmp2,Ra,Rc
> > MIN Rtmp3,Rb,Rc
> > MAX Rtmp1,Rtmp1,Rtmp2,Rttmp3
> >
> > in that case, for between two and four cycles (assuming that
> > three-way MAX is a single cycle). For OoO, MID is then probably
> > not worth it, especially if it is can not be done in a single
> > cycle.
> >
> > Three-way sort could then be
> >
> > MIN Rmin,Ra,Rb,Rc
> > MAX Rmax,Ra,Rb,Rc
> > MIN Rtmp1,Ra,Rb
> > MIN Rtmp2,Ra,Rc
> > MIN Rtmp3,Rb,Rc
> > MAX Rmid,Rtmp1,Rtmp2,Rttmp3
> >
> > so between two and six cycles.
> The key question is: how often do people sort arrays of numbers?
> My guess is, in fields of signal and image processing they do it not very
> rarely, but also not often. And typical size here is from 2-3 to low hundreds.
>
> In other fields of computing, like commercial, scientific, data analytics,
> sorting arrays of numbers is *extremely* rare.
>
> What is not rare is sorting arrays of records by numeric key.
> Of which most important case is sorting small records consisting of
> numeric key and pointer-or-index.
>
> Max and min instruction are probably far less useful in this mighty
> important case then they are in less important case of sorting arrays of number.

How about double-wide min and max? 1/2 key and 1/2 pointer?

On Tuesday, June 13, 2023 at 6:26:55 AM UTC-4, Thomas Koenig wrote:
> robf...@gmail.com <robf...@gmail.com> schrieb:
> > I have been considering using 128-bit bundles containing three
> > 40-bit instructions in fixed locations. That would get back some of the
> > benefits of the 4-byte aligned instructions, but it wastes 6% of memory..
> > The I$ could be made 120-bits wide so no wastage there.
> We previously discussed 128-bit bundles with instructions being
> a multiple of 20 bits, with stop bits in the header.
>
I tried 120-bit bundles, but it makes things more complex than byte
alignment. The bundle must be found on the cache-line, then high order
PC bits used to select the bundle and low order PC bits used to select
the word. There are two multiplies by 120/40 involved. For byte alignment
the low order PC bits can be multiplied by eight. Computing the branch
displacements was a headache when modifying the assembler an extra
byte needed to be inserted every 15 bytes. The bundles also make moving
code around for PIC more challenging.

> Frequent instructions like "add ra,rb,rb" or "add ra,rb,#1" could
> then fall in the 20-bit category.
>
> If you manage 40% of your instructions to use 20 bits and 60% to use
> 40 bits, you break even in code density with a 32-bit encoding.
> But 40 bits are a better fit if you have more than 32 registers.

I think it would be difficult to make good use of 20-bit instructions as
there are 64 GPRs. Most instructions also have predicates and format
fields for vector operations. The 40-bit instruction is packed. I ran out of
registers in the ABI even with 64, as some are used for micro-code. I think
the code density may be less than 20% larger than a 32-bit code as
sometimes 32-bit code needs extra instructions to encode an operation.

> Putting 32-bit or 64-bit constants into the stream is less
> convenient, and will lead to losses in code density vs.,
> for example, Mitch's constant encoding.

Yea, about 20% is lost in code density. Constants are encoded as NOPs
following the instruction. The NOP opcode takes up some space.
>
> You'll need to run a frequency analysis on instructions to see
> if it makes sense for you or not.

With byte aligned code it may be possible to use 24 bit instructions. I had
variable instruction lengths in a previous iteration and it did improve code
density significantly. I guess I am after a faster clock cycle time and less
hardware with this machine.

On Tuesday, June 13, 2023 at 1:50:10 AM UTC-5, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > On Monday, June 12, 2023 at 4:05:16 PM UTC-5, Thomas Koenig wrote:
> >> Hmm.. a couple of thoughts.
> >>
> >> Assumme we have the three-operand instructions
> >>
> >> MIN Rt,Ra,Rb,Rc
> >> MID Rt,Ra,Rb,Rc
> >> MAX Rt,Ra,Rb,Rc
> ><
> > In the 1980s and very early '90s, some designers thought about using
> > CAM sort arrays* in hardware. Software would load up a number of
> > values and write them into the "sorter", after loading all values, soft-
> > ware would read out all the value in order. No instruction was needed
> > to cause the sorter to sort, the writing of values in performed sorting..
> ><
> > These never went anywhere--draw your own conclusions.
> The pendulum of reintegration swung the other way, quickly.
>
> Although there appears to be a SORTL instruction on zSystem, according to
> https://blog.share.org/Article/peeking-under-the-hood-of-sort-acceleration-on-z15
> which appears to bring some improvement, so...
> ><
> > (*) CAMs can be made to do things other than exact match detection.
> Interesting.
>
> MIN and MAX of three registers is straightforward two instructions,
> but MID is more challenging. It could be something like
>
> MIN Rtmp1,Ra,Rb
> MIN Rtmp2,Ra,Rc
> MIN Rtmp3,Rb,Rc
> MAX Rtmp1,Rt1,Rt2
> MAX Rtmp1,Rt1,Rt3
<
Hardware could perform 3 comparisons in parallel A CMP B, A CMP C,
and B CMP C. Then using the > and < indications from the 3 comparisons
perform::
<
SRT3 {Ra, Rb, Rc} > {Ra, Rb, Rc}
<
In one pass through a 2 cycle pipeline. Latency = 2 throughput = 1.
By reusing the register names fewer fields are required in the instruction.
>
> with (assuming single-cycle latency) anything between three
> (for a sufficiently wide OoO machine) and five cycles of latency.
>
> The last two instructions would be a three-way MAX, so this
> could be shortened to
>
> MIN Rtmp1,Ra,Rb
> MIN Rtmp2,Ra,Rc
> MIN Rtmp3,Rb,Rc
> MAX Rtmp1,Rtmp1,Rtmp2,Rttmp3
>
> in that case, for between two and four cycles (assuming that
> three-way MAX is a single cycle). For OoO, MID is then probably
> not worth it, especially if it is can not be done in a single
> cycle.
>
> Three-way sort could then be
>
> MIN Rmin,Ra,Rb,Rc
> MAX Rmax,Ra,Rb,Rc
> MIN Rtmp1,Ra,Rb
> MIN Rtmp2,Ra,Rc
> MIN Rtmp3,Rb,Rc
> MAX Rmid,Rtmp1,Rtmp2,Rttmp3
>
> so between two and six cycles.

On Tuesday, June 13, 2023 at 5:15:20 AM UTC-5, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > Many sort algorithms allow the user to supply the subroutine that determines
> > the sort order::
> ><
> > SORT( A, length, comparison )
> > {
> > for( j = 0; j < length-1; j++ )
> > for( i = 0; I < length; i++ )
> > if( comparison( A[i], A[j] )
> > SWAP( A[i], A[j] );
> > }
> An argument for either templates or LTO if there ever was one.
> Making a function call to compare two integers or floats sounds
> wrong, however low the overhead may be.
<
What about EBCIDIC strings ??
What about ASCII strings ??
What about UTF8 strings ??

MitchAlsup wrote:
> On Tuesday, June 13, 2023 at 5:15:20 AM UTC-5, Thomas Koenig wrote:
>> MitchAlsup <Mitch...@aol.com> schrieb:
>>> Many sort algorithms allow the user to supply the subroutine that determines
>>> the sort order::
>>> <
>>> SORT( A, length, comparison )
>>> {
>>> for( j = 0; j < length-1; j++ )
>>> for( i = 0; I < length; i++ )
>>> if( comparison( A[i], A[j] )
>>> SWAP( A[i], A[j] );
>>> }
>> An argument for either templates or LTO if there ever was one.
>> Making a function call to compare two integers or floats sounds
>> wrong, however low the overhead may be.
> <
> What about EBCIDIC strings ??
> What about ASCII strings ??
> What about UTF8 strings ??

I am guessing that the fastest approach might be similar to the C
single-byte file read call, which is actually a macro that picks the
next byte from the file buffer, only falling back to an actual function
call when the buffer is empty.

You probably need some C++ template magic to make this all work
semi-portably across multiple record key types?

I remember writing sort code 35+ years ago that would extract and
serialize all the keys, together with a record index, so that the
comparison function could always use an inline REPE CMPSB. This meant
that some types of sub-key parts needed to be inverted or negated in
order to get the desired sort direction, but this way I only did all
this once per record instead of twice for every pair comparison.

Terje

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

On Tuesday, June 13, 2023 at 6:10:13 PM UTC+3, robf...@gmail.com wrote:
> On Tuesday, June 13, 2023 at 8:30:27 AM UTC-4, Michael S wrote:
> > On Tuesday, June 13, 2023 at 9:50:10 AM UTC+3, Thomas Koenig wrote:
> > > MitchAlsup <Mitch...@aol.com> schrieb:
> > > > On Monday, June 12, 2023 at 4:05:16 PM UTC-5, Thomas Koenig wrote:
> > > >> Hmm.. a couple of thoughts.
> > > >>
> > > >> Assumme we have the three-operand instructions
> > > >>
> > > >> MIN Rt,Ra,Rb,Rc
> > > >> MID Rt,Ra,Rb,Rc
> > > >> MAX Rt,Ra,Rb,Rc
> > > ><
> > > > In the 1980s and very early '90s, some designers thought about using
> > > > CAM sort arrays* in hardware. Software would load up a number of
> > > > values and write them into the "sorter", after loading all values, soft-
> > > > ware would read out all the value in order. No instruction was needed
> > > > to cause the sorter to sort, the writing of values in performed sorting.
> > > ><
> > > > These never went anywhere--draw your own conclusions.
> > > The pendulum of reintegration swung the other way, quickly.
> > >
> > > Although there appears to be a SORTL instruction on zSystem, according to
> > > https://blog.share.org/Article/peeking-under-the-hood-of-sort-acceleration-on-z15
> > > which appears to bring some improvement, so...
> > > ><
> > > > (*) CAMs can be made to do things other than exact match detection.
> > > Interesting.
> > >
> > > MIN and MAX of three registers is straightforward two instructions,
> > > but MID is more challenging. It could be something like
> > >
> > > MIN Rtmp1,Ra,Rb
> > > MIN Rtmp2,Ra,Rc
> > > MIN Rtmp3,Rb,Rc
> > > MAX Rtmp1,Rt1,Rt2
> > > MAX Rtmp1,Rt1,Rt3
> > >
> > > with (assuming single-cycle latency) anything between three
> > > (for a sufficiently wide OoO machine) and five cycles of latency.
> > >
> > > The last two instructions would be a three-way MAX, so this
> > > could be shortened to
> > >
> > > MIN Rtmp1,Ra,Rb
> > > MIN Rtmp2,Ra,Rc
> > > MIN Rtmp3,Rb,Rc
> > > MAX Rtmp1,Rtmp1,Rtmp2,Rttmp3
> > >
> > > in that case, for between two and four cycles (assuming that
> > > three-way MAX is a single cycle). For OoO, MID is then probably
> > > not worth it, especially if it is can not be done in a single
> > > cycle.
> > >
> > > Three-way sort could then be
> > >
> > > MIN Rmin,Ra,Rb,Rc
> > > MAX Rmax,Ra,Rb,Rc
> > > MIN Rtmp1,Ra,Rb
> > > MIN Rtmp2,Ra,Rc
> > > MIN Rtmp3,Rb,Rc
> > > MAX Rmid,Rtmp1,Rtmp2,Rttmp3
> > >
> > > so between two and six cycles.
> > The key question is: how often do people sort arrays of numbers?
> > My guess is, in fields of signal and image processing they do it not very
> > rarely, but also not often. And typical size here is from 2-3 to low hundreds.
> >
> > In other fields of computing, like commercial, scientific, data analytics,
> > sorting arrays of numbers is *extremely* rare.
> >
> > What is not rare is sorting arrays of records by numeric key.
> > Of which most important case is sorting small records consisting of
> > numeric key and pointer-or-index.
> >
> > Max and min instruction are probably far less useful in this mighty
> > important case then they are in less important case of sorting arrays of number.
> How about double-wide min and max? 1/2 key and 1/2 pointer?

On the GPR side or on the SIMD side, assuming that your machine has SIMD side
in the first place.

On GPR side:
Such instruction, apart from complexity of implementation, is going to require twice
as many rename resources vs "normal" instruction, so good implementation will likely
make it half the throughout of "normal" instructions. So, the whole enterprise of replacing
1 compare + 4 conditional moves with Min2 + Max2 will improve performance by 20%.
I don't find it very attractive.

On SIMD side.
For 128-bit SIMD - great idea. Very easy to implement. Flexible and useful.

For wider SIMD - how do you define it? There are two options:

A. Keys are in lower 64 bits (or 32 bits). The rest of register is payload..

B. Each 128-bit superlane has the key of its own, so for 512b register you do
4 independent Min2 or Max2 operations at once.

I don't know which option is more useful in practice. I do know however that
option A is much harder to implement in hardware than optiion B.

According to MitchAlsup <MitchAlsup@aol.com>:
>On Tuesday, June 13, 2023 at 5:15:20 AM UTC-5, Thomas Koenig wrote:
>> MitchAlsup <Mitch...@aol.com> schrieb:
>> > Many sort algorithms allow the user to supply the subroutine that determines
>> > the sort order::
>> ><
>> > SORT( A, length, comparison )
>> > {
>> > for( j = 0; j < length-1; j++ )
>> > for( i = 0; I < length; i++ )
>> > if( comparison( A[i], A[j] )
>> > SWAP( A[i], A[j] );
>> > }
>> An argument for either templates or LTO if there ever was one.
>> Making a function call to compare two integers or floats sounds
>> wrong, however low the overhead may be.
><
>What about EBCIDIC strings ??
>What about ASCII strings ??
>What about UTF8 strings ??

On the systems I know, the sort routine treats the data as a set of
byte strings, and the default comparison is a string compare.

Not entirely by accident, this gives a reasonable answer if the string
is EBCDIC, ASCII, or UTF-8. Digits sort in 0-9 order and alphabetics
sort reasonably. Sorting UTF-8 gives the same order as if you decoded
them to code points and sorted them.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

John Levine <johnl@taugh.com> writes:
>According to MitchAlsup <MitchAlsup@aol.com>:
>>On Tuesday, June 13, 2023 at 5:15:20 AM UTC-5, Thomas Koenig wrote:
>>> MitchAlsup <Mitch...@aol.com> schrieb:
>>> > Many sort algorithms allow the user to supply the subroutine that determines
>>> > the sort order::
>>> ><
>>> > SORT( A, length, comparison )
>>> > {
>>> > for( j = 0; j < length-1; j++ )
>>> > for( i = 0; I < length; i++ )
>>> > if( comparison( A[i], A[j] )
>>> > SWAP( A[i], A[j] );
>>> > }
>>> An argument for either templates or LTO if there ever was one.
>>> Making a function call to compare two integers or floats sounds
>>> wrong, however low the overhead may be.
>><
>>What about EBCIDIC strings ??
>>What about ASCII strings ??
>>What about UTF8 strings ??
>
>On the systems I know, the sort routine treats the data as a set of
>byte strings, and the default comparison is a string compare.
>
>Not entirely by accident, this gives a reasonable answer if the string
>is EBCDIC, ASCII, or UTF-8. Digits sort in 0-9 order and alphabetics
>sort reasonably. Sorting UTF-8 gives the same order as if you decoded
>them to code points and sorted them.

One key difference - in ASCII digits collate before all alpha characters;
the reverse is true for EBCDIC causing a different sort order for
alphanumeric keys.

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Tuesday, June 13, 2023 at 1:50:10 AM UTC-5, Thomas Koenig wrote:
>> MitchAlsup <Mitch...@aol.com> schrieb:
>> > On Monday, June 12, 2023 at 4:05:16 PM UTC-5, Thomas Koenig wrote:
>> >> Hmm.. a couple of thoughts.
>> >>
>> >> Assumme we have the three-operand instructions
>> >>
>> >> MIN Rt,Ra,Rb,Rc
>> >> MID Rt,Ra,Rb,Rc
>> >> MAX Rt,Ra,Rb,Rc
>> ><
>> > In the 1980s and very early '90s, some designers thought about using
>> > CAM sort arrays* in hardware. Software would load up a number of
>> > values and write them into the "sorter", after loading all values, soft-
>> > ware would read out all the value in order. No instruction was needed
>> > to cause the sorter to sort, the writing of values in performed sorting.
>> ><
>> > These never went anywhere--draw your own conclusions.
>> The pendulum of reintegration swung the other way, quickly.
>>
>> Although there appears to be a SORTL instruction on zSystem, according to
>> https://blog.share.org/Article/peeking-under-the-hood-of-sort-acceleration-on-z15
>> which appears to bring some improvement, so...
>> ><
>> > (*) CAMs can be made to do things other than exact match detection.
>> Interesting.
>>
>> MIN and MAX of three registers is straightforward two instructions,
>> but MID is more challenging. It could be something like
>>
>> MIN Rtmp1,Ra,Rb
>> MIN Rtmp2,Ra,Rc
>> MIN Rtmp3,Rb,Rc
>> MAX Rtmp1,Rt1,Rt2
>> MAX Rtmp1,Rt1,Rt3
><
> Hardware could perform 3 comparisons in parallel A CMP B, A CMP C,
> and B CMP C. Then using the > and < indications from the 3 comparisons
> perform::
><
> SRT3 {Ra, Rb, Rc} > {Ra, Rb, Rc}
><
> In one pass through a 2 cycle pipeline. Latency = 2 throughput = 1.
> By reusing the register names fewer fields are required in the instruction.

To do this in two cyles would this require writing three registers
at the same time (so at least a 3R3W register file), correct?
Or is there some way of making this less expensive?

It might actually make sense to split this into two instructions for
more flexibility, to make both direct and index sort possible.

So something like

CMP3GT Rt,Rs1,Rs2,Rs3
SRT3 Rt,Ra,Rb,Rc

where CMP3GT could generate a bit pattern indicating which way
the target registers of SRT3 should be swapped (for example 010
001 100 if the value of Ra should be moved into Rb, the value of
Rb into Ra and the value of Rc should be left unchanged).

On Saturday, June 17, 2023 at 1:45:51 PM UTC-5, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > On Tuesday, June 13, 2023 at 1:50:10 AM UTC-5, Thomas Koenig wrote:
> >> MitchAlsup <Mitch...@aol.com> schrieb:
> >> > On Monday, June 12, 2023 at 4:05:16 PM UTC-5, Thomas Koenig wrote:
> >> >> Hmm.. a couple of thoughts.
> >> >>
> >> >> Assumme we have the three-operand instructions
> >> >>
> >> >> MIN Rt,Ra,Rb,Rc
> >> >> MID Rt,Ra,Rb,Rc
> >> >> MAX Rt,Ra,Rb,Rc
> >> ><
> >> > In the 1980s and very early '90s, some designers thought about using
> >> > CAM sort arrays* in hardware. Software would load up a number of
> >> > values and write them into the "sorter", after loading all values, soft-
> >> > ware would read out all the value in order. No instruction was needed
> >> > to cause the sorter to sort, the writing of values in performed sorting.
> >> ><
> >> > These never went anywhere--draw your own conclusions.
> >> The pendulum of reintegration swung the other way, quickly.
> >>
> >> Although there appears to be a SORTL instruction on zSystem, according to
> >> https://blog.share.org/Article/peeking-under-the-hood-of-sort-acceleration-on-z15
> >> which appears to bring some improvement, so...
> >> ><
> >> > (*) CAMs can be made to do things other than exact match detection.
> >> Interesting.
> >>
> >> MIN and MAX of three registers is straightforward two instructions,
> >> but MID is more challenging. It could be something like
> >>
> >> MIN Rtmp1,Ra,Rb
> >> MIN Rtmp2,Ra,Rc
> >> MIN Rtmp3,Rb,Rc
> >> MAX Rtmp1,Rt1,Rt2
> >> MAX Rtmp1,Rt1,Rt3
> ><
> > Hardware could perform 3 comparisons in parallel A CMP B, A CMP C,
> > and B CMP C. Then using the > and < indications from the 3 comparisons
> > perform::
> ><
> > SRT3 {Ra, Rb, Rc} > {Ra, Rb, Rc}
> ><
> > In one pass through a 2 cycle pipeline. Latency = 2 throughput = 1.
> > By reusing the register names fewer fields are required in the instruction.
> To do this in two cyles would this require writing three registers
> at the same time (so at least a 3R3W register file), correct?
<
Yes, that is the implication of throughput = 1
<
> Or is there some way of making this less expensive?
<
There are ways if you have access to raw transistors and wires. It gets
expensive fast if you only have access to gates from a library.
>
> It might actually make sense to split this into two instructions for
> more flexibility, to make both direct and index sort possible.
>
> So something like
>
> CMP3GT Rt,Rs1,Rs2,Rs3
> SRT3 Rt,Ra,Rb,Rc
>
> where CMP3GT could generate a bit pattern indicating which way
> the target registers of SRT3 should be swapped (for example 010
> 001 100 if the value of Ra should be moved into Rb, the value of
> Rb into Ra and the value of Rc should be left unchanged).

On Tuesday, June 13, 2023 at 3:46:04 PM UTC-5, Scott Lurndal wrote:
> John Levine <jo...@taugh.com> writes:
> >According to MitchAlsup <Mitch...@aol.com>:
> >>On Tuesday, June 13, 2023 at 5:15:20 AM UTC-5, Thomas Koenig wrote:
> >>> MitchAlsup <Mitch...@aol.com> schrieb:
> >>> > Many sort algorithms allow the user to supply the subroutine that determines
> >>> > the sort order::
> >>> ><
> >>> > SORT( A, length, comparison )
> >>> > {
> >>> > for( j = 0; j < length-1; j++ )
> >>> > for( i = 0; I < length; i++ )
> >>> > if( comparison( A[i], A[j] )
> >>> > SWAP( A[i], A[j] );
> >>> > }
> >>> An argument for either templates or LTO if there ever was one.
> >>> Making a function call to compare two integers or floats sounds
> >>> wrong, however low the overhead may be.
> >><
> >>What about EBCIDIC strings ??
> >>What about ASCII strings ??
> >>What about UTF8 strings ??
> >
> >On the systems I know, the sort routine treats the data as a set of
> >byte strings, and the default comparison is a string compare.
> >
> >Not entirely by accident, this gives a reasonable answer if the string
> >is EBCDIC, ASCII, or UTF-8. Digits sort in 0-9 order and alphabetics
> >sort reasonably. Sorting UTF-8 gives the same order as if you decoded
> >them to code points and sorted them.
> One key difference - in ASCII digits collate before all alpha characters;
> the reverse is true for EBCDIC causing a different sort order for
> alphanumeric keys.

Though, stricmp/strnicmp is more of a problem:
ASCII: Easy enough.
1252: Also works, just needs more rules.
UTF-8: Simple case: ASCII only. Non-simple case, "Oh No".

Woud need different implementations to support both 1252 and UTF-8 and give sensible results...

But, any progress on my projects is currently stalled at the moment due to being in the middle of a multi-day blackout... (posting from phone, with an intermittent connection).

According to BGB <cr88192@gmail.com>:
>> >sort reasonably. Sorting UTF-8 gives the same order as if you decoded
>> >them to code points and sorted them.

>Though, stricmp/strnicmp is more of a problem:
>ASCII: Easy enough.
>1252: Also works, just needs more rules.
>UTF-8: Simple case: ASCII only. Non-simple case, "Oh No".
>
>Woud need different implementations to support both 1252 and UTF-8 and give sensible results...

What's not sensible about sorting UTF-8 into code point order?

If you want a sort order that matches a language's dictionary order,
that's much harder, but it's not trivial in ASCII, either.

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

On Monday, June 19, 2023 at 1:25:43 PM UTC-5, John Levine wrote:
> According to BGB <cr8...@gmail.com>:
> >> >sort reasonably. Sorting UTF-8 gives the same order as if you decoded
> >> >them to code points and sorted them.
> >Though, stricmp/strnicmp is more of a problem:
> >ASCII: Easy enough.
> >1252: Also works, just needs more rules.
> >UTF-8: Simple case: ASCII only. Non-simple case, "Oh No".
> >
> >Woud need different implementations to support both 1252 and UTF-8 and give sensible results...
> What's not sensible about sorting UTF-8 into code point order?
>

The stricmp/strnicmp (AKA: strcasecmp/strncasecmp or _stricmp/_strnicmp) functions do a case-insensitive compare.

This requires internally normalizing the case, which requires knowing the character encoding (if, say, the Latin1 characters are also intended to be case-insensitive).

I am not sure what the "standard" solution is though (the descriptions I had found make no reference to locale or character encoding).

Or, one could make a case that these functions only apply to ASCII (and/or 1252) and have separate "_stricmp_u8" functions and similar?...

> If you want a sort order that matches a language's dictionary order,
> that's much harder, but it's not trivial in ASCII, either.

Granted, but easy enough to define 'A' == 'a' for sake of case-insensitive compare, and ignore others.

Then there are the accented characters, which are mostly a matter of mapping.

The German "hard S" character has no obvious case mapping, and making it compare equal to 'ss'/'SS' seems like too much of a hack...

Can ignore most of the rest of the Unicode space as (aside from Greek and Cyrillic and similar) most other alphabets do not have case.

Status:
Still in blackout, but parents have went and got a generator. Mostly using it to try to keep the refrigerator cold... Apparently the utility company estimates about a week to get power back online (Tulsa's grid kinda got wrecked by 100mph winds...).

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

On Monday, June 19, 2023 at 2:55:35 PM UTC-5, BGB wrote:
> On Monday, June 19, 2023 at 1:25:43 PM UTC-5, John Levine wrote:
> > According to BGB <cr8...@gmail.com>:
> > >> >sort reasonably. Sorting UTF-8 gives the same order as if you decoded
> > >> >them to code points and sorted them.
> > >Though, stricmp/strnicmp is more of a problem:
> > >ASCII: Easy enough.
> > >1252: Also works, just needs more rules.
> > >UTF-8: Simple case: ASCII only. Non-simple case, "Oh No".
> > >
> > >Woud need different implementations to support both 1252 and UTF-8 and give sensible results...
> > What's not sensible about sorting UTF-8 into code point order?
> >
> The stricmp/strnicmp (AKA: strcasecmp/strncasecmp or _stricmp/_strnicmp) functions do a case-insensitive compare.
>
> This requires internally normalizing the case, which requires knowing the character encoding (if, say, the Latin1 characters are also intended to be case-insensitive).
>
{Beginning to text to be commented}
> I am not sure what the "standard" solution is though (the descriptions I had found make no reference to locale or character encoding).
>
> Or, one could make a case that these functions only apply to ASCII (and/or 1252) and have separate "_stricmp_u8" functions and similar?...
> > If you want a sort order that matches a language's dictionary order,
> > that's much harder, but it's not trivial in ASCII, either.
> Granted, but easy enough to define 'A' == 'a' for sake of case-insensitive compare, and ignore others.
>
> Then there are the accented characters, which are mostly a matter of mapping.
>
> The German "hard S" character has no obvious case mapping, and making it compare equal to 'ss'/'SS' seems like too much of a hack...
>
> Can ignore most of the rest of the Unicode space as (aside from Greek and Cyrillic and similar) most other alphabets do not have case.
{End of text being commented}
<
A perfect case illustrating "another layer of indirection" saves the day::
<
if( table[string1[i]] == table[string2[i]] ) continue;
<
The table solves the ASCII versus EBCIDIC versus field-data,
and solves the {German, Greek, Cyrillic,...} problems.
>
>
> Status:
> Still in blackout, but parents have went and got a generator. Mostly using it to try to keep the refrigerator cold... Apparently the utility company estimates about a week to get power back online (Tulsa's grid kinda got wrecked by 100mph winds...).
<
Makes me wonder about what electricity would cost if the transmission lines were able to withstand 100 MPH winds.....
<
> > --
> > Regards,
> > John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> > Please consider the environment before reading this e-mail. https://jl.ly

On Monday, June 19, 2023 at 4:47:39 PM UTC-5, MitchAlsup wrote:
> On Monday, June 19, 2023 at 2:55:35 PM UTC-5, BGB wrote:
> > On Monday, June 19, 2023 at 1:25:43 PM UTC-5, John Levine wrote:
> > > According to BGB <cr8...@gmail.com>:
> > > >> >sort reasonably. Sorting UTF-8 gives the same order as if you decoded
> > > >> >them to code points and sorted them.
> > > >Though, stricmp/strnicmp is more of a problem:
> > > >ASCII: Easy enough.
> > > >1252: Also works, just needs more rules.
> > > >UTF-8: Simple case: ASCII only. Non-simple case, "Oh No".
> > > >
> > > >Woud need different implementations to support both 1252 and UTF-8 and give sensible results...
> > > What's not sensible about sorting UTF-8 into code point order?
> > >
> > The stricmp/strnicmp (AKA: strcasecmp/strncasecmp or _stricmp/_strnicmp) functions do a case-insensitive compare.
> >
> > This requires internally normalizing the case, which requires knowing the character encoding (if, say, the Latin1 characters are also intended to be case-insensitive).
> >
> {Beginning to text to be commented}
> > I am not sure what the "standard" solution is though (the descriptions I had found make no reference to locale or character encoding).
> >
> > Or, one could make a case that these functions only apply to ASCII (and/or 1252) and have separate "_stricmp_u8" functions and similar?...
> > > If you want a sort order that matches a language's dictionary order,
> > > that's much harder, but it's not trivial in ASCII, either.
> > Granted, but easy enough to define 'A' == 'a' for sake of case-insensitive compare, and ignore others.
> >
> > Then there are the accented characters, which are mostly a matter of mapping.
> >
> > The German "hard S" character has no obvious case mapping, and making it compare equal to 'ss'/'SS' seems like too much of a hack...
> >
> > Can ignore most of the rest of the Unicode space as (aside from Greek and Cyrillic and similar) most other alphabets do not have case.
> {End of text being commented}
> <
> A perfect case illustrating "another layer of indirection" saves the day::
> <
> if( table[string1[i]] == table[string2[i]] ) continue;
> <
> The table solves the ASCII versus EBCIDIC versus field-data,
> and solves the {German, Greek, Cyrillic,...} problems.

Yeah, NTFS sorta used this approach IIRC, and embedded the tables into the filesystem.

Looking around more, I found out:
Conventionally, it is based on locale settings (which in my case, likely means "Assume 1252 by default unless locale is set to 'C.UTF-8' or similar").

Apparently, the more standard behavior is to normalize to lower case before the compare, but the C library I am using normalizes to upper case. If I remember, may need to fix this once power is back...

Before power went out, had worked some on speeding up these functions, as it turns out they were eating a lot of CPU time in some programs (had reworked them some to work on blocks of 8 chars at a time, but this would only work for
ASCII/1252).

Some of this is related to trying to hunt down remaining cases where programs behave differently when built on BJX2 than on native x86 targets...

> >
> >
> > Status:
> > Still in blackout, but parents have went and got a generator. Mostly using it to try to keep the refrigerator cold... Apparently the utility company estimates about a week to get power back online (Tulsa's grid kinda got wrecked by 100mph winds...).
> <
> Makes me wonder about what electricity would cost if the transmission lines were able to withstand 100 MPH winds.....

Dunno. Could bury the lines, but this probably wouldn't work well for high voltage transmission lines. Buried lines aren't really a thing here, mostly just wooden utility poles.

Like, say, if 100kV lines required, say, 8-10" of fiberglass and silicone insulation or similar, this would likely be impractical.

Would likely be easier for 960V and 30kV lines though (eg, "most of them"), leaving mostly 100kV to 500kV on the big pylons... IIRC, for 30kV it is something like 2 inch silicone or similar.

Wind knocked over a bunch of trees and also a bunch of the utility poles, .... Most of the Tulsa metropolitan area was knocked out.

I guess during the storm in some places, there was a lot of flying trees and other debris that had took flight, ... Lots of flashes where the grid was getting torn up, and a whole lot of lightning as well.

Storm was relatively short, but was enough to make the whole house rumble at one point as it passed over. I guess in some places, buildings got damaged and windows blown-in, ...

According to MitchAlsup <MitchAlsup@aol.com>:
>> > If you want a sort order that matches a language's dictionary order,
>> > that's much harder, but it's not trivial in ASCII, either.
>> Granted, but easy enough to define 'A' == 'a' for sake of case-insensitive compare, and ignore others.

If you just want English case folding it's easy. If you want dictionary order, or any other
language, it's much harder.

>> The German "hard S" character has no obvious case mapping, and making it compare equal to 'ss'/'SS' seems like too much of a hack...

This sort of stuff is very lanuage specific. In German, ö is usually
equivalent to oe, but in Scandanavian languages it is not. Even worse,
in Unicode there are two ways to represent ö, a single composed
character or a combining diaresis followed by a plain "o". People spend
years trying to get this right.

>> Can ignore most of the rest of the Unicode space as (aside from Greek and Cyrillic and similar) most other alphabets do not have case.

Yeah, but they have variants. Are the traditional and simplified
versions of Chinese characters equivalent or not? The answer is "it depends".

>A perfect case illustrating "another layer of indirection" saves the day::
><
> if( table[string1[i]] == table[string2[i]] ) continue;

That is so very, very, not adequate.

>Makes me wonder about what electricity would cost if the transmission lines were able to withstand 100 MPH winds.....

Well, you could visit New York City where they're all underground so it's not a problem.

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

On Monday, June 19, 2023 at 6:02:41 PM UTC-5, John Levine wrote:
> According to MitchAlsup <Mitch...@aol.com>:
> >> > If you want a sort order that matches a language's dictionary order,
> >> > that's much harder, but it's not trivial in ASCII, either.
> >> Granted, but easy enough to define 'A' == 'a' for sake of case-insensitive compare, and ignore others.
> If you just want English case folding it's easy. If you want dictionary order, or any other
> language, it's much harder.
> >> The German "hard S" character has no obvious case mapping, and making it compare equal to 'ss'/'SS' seems like too much of a hack...
> This sort of stuff is very lanuage specific. In German, ö is usually
> equivalent to oe, but in Scandanavian languages it is not. Even worse,
> in Unicode there are two ways to represent ö, a single composed
> character or a combining diaresis followed by a plain "o". People spend
> years trying to get this right.

I am probably going to take the simpler route and assume that 'O'=='o' (assume accent/umlaut, not sure how to type these on Android with a bluetooth keyboard). But, matching them with oe, probably not.

In this case, "hard S" would not have any case translation.

Probably, toupper/tolower will assume the existing "ambiguous 1252/unicode hybrid" space.

Will ignore collating rules, since those are strcoll's business; and seemingly the rules for "minimal valid implementation" allow treating strcoll as an alias to strcmp...

> >> Can ignore most of the rest of the Unicode space as (aside from Greek and Cyrillic and similar) most other alphabets do not have case.
> Yeah, but they have variants. Are the traditional and simplified
> versions of Chinese characters equivalent or not? The answer is "it depends".

I am probably going to conveniently ignore all this.

Probably Latin, Greek, Cyrillic, then call it done.
Probably also the existing practice of assuming 1252 and UTF-8, ignoring the existence of all the other codepages.

> >A perfect case illustrating "another layer of indirection" saves the day::
> ><
> > if( table[string1[i]] == table[string2[i]] ) continue;
> That is so very, very, not adequate.
> >Makes me wonder about what electricity would cost if the transmission lines were able to withstand 100 MPH winds.....
> Well, you could visit New York City where they're all underground so it's not a problem.

They could do this, and probably then avoid needing to repair the grid every "Tornado season", maybe also have fewer power bumps and short blackouts (common annoyance, power going out for 1-2 hours every 1 or 2 months or so, and short bumps maybe a few times per week, ...).

But, if you reduce maintenance work, then one risks people complaining about the loss of jobs, ...

OTOH, it would add cost.

It is sort of like how people go and say that things like public mass transit are a socialist pipe dream...

Like, theoretically, there are busses, but if the busses only have a limited number of stops and have a 2 hour wait time on most routes, not very useful...

Like, a common argument being that the only "safe" and "viable" form of transportation is to get an overly large pickup truck, ... Roads mostly full of large pickups and SUVs (and the occasional person driving a sedan style car).

John Levine wrote:
> According to BGB <cr88192@gmail.com>:
>>>> sort reasonably. Sorting UTF-8 gives the same order as if you decoded
>>>> them to code points and sorted them.
>
>> Though, stricmp/strnicmp is more of a problem:
>> ASCII: Easy enough.
>> 1252: Also works, just needs more rules.
>> UTF-8: Simple case: ASCII only. Non-simple case, "Oh No".
>>
>> Woud need different implementations to support both 1252 and UTF-8 and give sensible results...
>
> What's not sensible about sorting UTF-8 into code point order?
>
> If you want a sort order that matches a language's dictionary order,
> that's much harder, but it's not trivial in ASCII, either.

Much, much harder: A is first, Å (Aring) is last in Norway and Denmark.

AA sorts the same as Å. I.e. you need to look for letter combinations
and sort them as a totally different code point.

Many years ago I hamdled this by creating sort keys which were
pre-digested into collating order, i.e. so that they could be sorted
with a pure binary byte array compare (like strcmp()).

Terje

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

MitchAlsup wrote:
> On Monday, June 19, 2023 at 2:55:35 PM UTC-5, BGB wrote:
>> On Monday, June 19, 2023 at 1:25:43 PM UTC-5, John Levine wrote:
>>> According to BGB <cr8...@gmail.com>:
>>>>>> sort reasonably. Sorting UTF-8 gives the same order as if you decoded
>>>>>> them to code points and sorted them.
>>>> Though, stricmp/strnicmp is more of a problem:
>>>> ASCII: Easy enough.
>>>> 1252: Also works, just needs more rules.
>>>> UTF-8: Simple case: ASCII only. Non-simple case, "Oh No".
>>>>
>>>> Woud need different implementations to support both 1252 and UTF-8 and give sensible results...
>>> What's not sensible about sorting UTF-8 into code point order?
>>>
>> The stricmp/strnicmp (AKA: strcasecmp/strncasecmp or _stricmp/_strnicmp) functions do a case-insensitive compare.
>>
>> This requires internally normalizing the case, which requires knowing the character encoding (if, say, the Latin1 characters are also intended to be case-insensitive).
>>
> {Beginning to text to be commented}
>> I am not sure what the "standard" solution is though (the descriptions I had found make no reference to locale or character encoding).
>>
>> Or, one could make a case that these functions only apply to ASCII (and/or 1252) and have separate "_stricmp_u8" functions and similar?...
>>> If you want a sort order that matches a language's dictionary order,
>>> that's much harder, but it's not trivial in ASCII, either.
>> Granted, but easy enough to define 'A' == 'a' for sake of case-insensitive compare, and ignore others.
>>
>> Then there are the accented characters, which are mostly a matter of mapping.
>>
>> The German "hard S" character has no obvious case mapping, and making it compare equal to 'ss'/'SS' seems like too much of a hack...
>>
>> Can ignore most of the rest of the Unicode space as (aside from Greek and Cyrillic and similar) most other alphabets do not have case.
> {End of text being commented}
> <
> A perfect case illustrating "another layer of indirection" saves the day::
> <
> if( table[string1[i]] == table[string2[i]] ) continue;
> <
> The table solves the ASCII versus EBCIDIC versus field-data,
> and solves the {German, Greek, Cyrillic,...} problems.

For speed you really want to do that lookup just once per key, instead
of twice per comparison. The only possible excpetion would be when the
keys are so long that storing a second copy runs out of memoery (or $L2
cache working set).

>>
>>
>> Status:
>> Still in blackout, but parents have went and got a generator. Mostly using it to try to keep the refrigerator cold... Apparently the utility company estimates about a week to get power back online (Tulsa's grid kinda got wrecked by 100mph winds...).
> <
> Makes me wonder about what electricity would cost if the transmission lines were able to withstand 100 MPH winds.....

Digging 400KV cables into the ground is about 3X more costly than
overhead power lines, but that does of course not translate into a 3X
cost for electricity, just for that specific part of the long distance
transmission. You could maybe add 3-10 cent/kWh?

Terje

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

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

On Tuesday, June 20, 2023 at 12:57:14 AM UTC-5, Terje Mathisen wrote:
> MitchAlsup wrote:
> > On Monday, June 19, 2023 at 2:55:35 PM UTC-5, BGB wrote:
> >> On Monday, June 19, 2023 at 1:25:43 PM UTC-5, John Levine wrote:
> >>> According to BGB <cr8...@gmail.com>:
> >>>>>> sort reasonably. Sorting UTF-8 gives the same order as if you decoded
> >>>>>> them to code points and sorted them.
> >>>> Though, stricmp/strnicmp is more of a problem:
> >>>> ASCII: Easy enough.
> >>>> 1252: Also works, just needs more rules.
> >>>> UTF-8: Simple case: ASCII only. Non-simple case, "Oh No".
> >>>>
> >>>> Woud need different implementations to support both 1252 and UTF-8 and give sensible results...
> >>> What's not sensible about sorting UTF-8 into code point order?
> >>>
> >> The stricmp/strnicmp (AKA: strcasecmp/strncasecmp or _stricmp/_strnicmp) functions do a case-insensitive compare.
> >>
> >> This requires internally normalizing the case, which requires knowing the character encoding (if, say, the Latin1 characters are also intended to be case-insensitive).
> >>
> > {Beginning to text to be commented}
> >> I am not sure what the "standard" solution is though (the descriptions I had found make no reference to locale or character encoding).
> >>
> >> Or, one could make a case that these functions only apply to ASCII (and/or 1252) and have separate "_stricmp_u8" functions and similar?...
> >>> If you want a sort order that matches a language's dictionary order,
> >>> that's much harder, but it's not trivial in ASCII, either.
> >> Granted, but easy enough to define 'A' == 'a' for sake of case-insensitive compare, and ignore others.
> >>
> >> Then there are the accented characters, which are mostly a matter of mapping.
> >>
> >> The German "hard S" character has no obvious case mapping, and making it compare equal to 'ss'/'SS' seems like too much of a hack...
> >>
> >> Can ignore most of the rest of the Unicode space as (aside from Greek and Cyrillic and similar) most other alphabets do not have case.
> > {End of text being commented}
> > <
> > A perfect case illustrating "another layer of indirection" saves the day::
> > <
> > if( table[string1[i]] == table[string2[i]] ) continue;
> > <
> > The table solves the ASCII versus EBCIDIC versus field-data,
> > and solves the {German, Greek, Cyrillic,...} problems.
> For speed you really want to do that lookup just once per key, instead
> of twice per comparison. The only possible excpetion would be when the
> keys are so long that storing a second copy runs out of memoery (or $L2
> cache working set).

Lookup table versus rules is a tradeoff. Early on, rules-based logic was the winner here, but in a more recent test, lookup tables were faster, at least for ASCII/1252 range. For the rest of the BMP space, a lookup table would be too large. Also, for UTF-8, the logic for decoding codepoints would probably be a bigger issue than the logic for case-conversion.

Did read somewhere that for case insensitive compare with Unicode, the rule is more "case normalization" rather than simply converting to lower or upper case, though for the Latin alphabet and similar, the rule is lower case. IIRC, the idea was that Cyrillic (IIRC, not sure) and a few other alphabets normalized to upper case instead for the case-insensitive compare.

> >>
> >>
> >> Status:
> >> Still in blackout, but parents have went and got a generator. Mostly using it to try to keep the refrigerator cold... Apparently the utility company estimates about a week to get power back online (Tulsa's grid kinda got wrecked by 100mph winds...).
> > <
> > Makes me wonder about what electricity would cost if the transmission lines were able to withstand 100 MPH winds.....
> Digging 400KV cables into the ground is about 3X more costly than
> overhead power lines, but that does of course not translate into a 3X
> cost for electricity, just for that specific part of the long distance
> transmission. You could maybe add 3-10 cent/kWh?
>

Yeah, not sure what you would do for 400kV.

One possible guess for insulating the wire would be, say: Central conductor wrapped with fiberglass and silicone; thick layer of silica sand with some fiberglass and silicone (to add stability and keep water out), outer layer likely more fiberglass and silicone (to add durability). Solid rubber insulation would likely be cost prohibitive I think.

Insulating the wire would likely cost more than the conductor in this case. Would almost make sense to use thicker conductors operating at lower voltages to reduce the cost of the insulation (say, using a lot more 30kV or 50kV lines).

Otherwise, still blackout.
Did read that apparently they are sending over a bunch of utility trucks from Texas and similar to help out...

BGB wrote:
> On Tuesday, June 20, 2023 at 12:57:14 AM UTC-5, Terje Mathisen
>>> transmission lines were able to withstand 100 MPH winds.....
>> Digging 400KV cables into the ground is about 3X more costly than
>> overhead power lines, but that does of course not translate into a
>> 3X cost for electricity, just for that specific part of the long
>> distance transmission. You could maybe add 3-10 cent/kWh?
>>
>
> Yeah, not sure what you would do for 400kV.
>
> One possible guess for insulating the wire would be, say: Central
> conductor wrapped with fiberglass and silicone; thick layer of silica
> sand with some fiberglass and silicone (to add stability and keep
> water out), outer layer likely more fiberglass and silicone (to add
> durability). Solid rubber insulation would likely be cost prohibitive
> I think.
>
> Insulating the wire would likely cost more than the conductor in this
> case. Would almost make sense to use thicker conductors operating at
> lower voltages to reduce the cost of the insulation (say, using a lot
> more 30kV or 50kV lines).

Below-ground cables, either directly deposited with a sand/gravel
wrapping, or inside a concrete culvert is well known technology. The
cables are interesting, with a lot of layers for electrical
conductivity, pulling strength and insulation.

Up in Rauland/Telemark the local power company is proactively digging
trenches and laying cables to replace overhead conductors in all the
places where history have shown ice buildup and/or heavy storm trefall
to be a problem.

Terje

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

On 6/21/2023 7:54 AM, Terje Mathisen wrote:
> BGB wrote:
>> On Tuesday, June 20, 2023 at 12:57:14 AM UTC-5, Terje Mathisen
>>>> transmission lines were able to withstand 100 MPH winds.....
>>> Digging 400KV cables into the ground is about 3X more costly than
>>> overhead power lines, but that does of course not translate into a
>>> 3X cost for electricity, just for that specific part of the long
>>> distance transmission. You could maybe add 3-10 cent/kWh?
>>>
>>
>> Yeah, not sure what you would do for 400kV.
>>
>> One possible guess for insulating the wire would be, say: Central
>> conductor wrapped with fiberglass and silicone; thick layer of silica
>> sand with some fiberglass and silicone (to add stability and keep
>> water out), outer layer likely more fiberglass and silicone (to add
>> durability). Solid rubber insulation would likely be cost prohibitive
>> I think.
>>
>> Insulating the wire would likely cost more than the conductor in this
>> case. Would almost make sense to use thicker conductors operating at
>> lower voltages to reduce the cost of the insulation (say, using a lot
>> more 30kV or 50kV lines).
>
> Below-ground cables, either directly deposited with a sand/gravel
> wrapping, or inside a concrete culvert is well known technology. The
> cables are interesting, with a lot of layers for electrical
> conductivity, pulling strength and insulation.
>
> Up in Rauland/Telemark the local power company is proactively digging
> trenches and laying cables to replace overhead conductors in all the
> places where history have shown ice buildup and/or heavy storm trefall
> to be a problem.
>

Makes sense.

Had looked, and it seems that insulating the cables for these voltages
doesn't require quite as much insulation as I had thought previously.

But, here, after a number of days (3 full days, Saturday and today being
partial days), power is now back on...

Though, there is a partial story for this:
Before this, I was off searching for my Arty-S7 board, but wasn't having
much luck finding it in my room, eventually I got partly frustrated, and
was sort of like "G-d, if you can point out where it is at, this would
be convenient." (Though, this was a sort of selfish request, which is
not necessarily a good thing; was half hoping for a sign to be like
"Yeah, it is over there"...).

A short time later, there was the weather alert for the approaching
storm. I posted a message about it on Twitter, then ended up putting PC
into hibernate mode. Maybe a few minutes later, the storm hit and
knocked out power.

It kinda sucked, but did on-off continue the search for the Arty-S7
board. Pretty much as soon as I found it, the power came back on...

Though, granted, the storm would have happened either way (not like
anything I am doing would matter enough to warrant something like this),
but like, weird stuff like this does happen sometimes (though usually on
a much smaller scale).

Like, I don't really see or hear anything directly. But, if I consider
doing something He wouldn't necessarily approve of, then everything
starts going to crap.

Almost sort of like in the "Book of Jonah" in this sense, just without
any obvious "mission" (or "message") in this case (nor any sort of
direct/tangible confirmation of His presence...).

Well, other examples were cases like, say, at one point I was going to
try to express interest in a female (who I possibly had a chance with),
but before I could give her a note doing so, a gas line exploded and
everyone had to be evacuated from the building. But, yeah, just a long
stream of seemingly random events sort of like this.

Did sort of barter that if He showed me where it was at, I would give
some sort of public acknowledgement of this. Though not exactly what I
had in mind, but I guess I am still under some obligation to give it
mention...

People can think what they will...
Not sure this would accomplish anything, in any case.

Not sure if there is anything else I should mention here.
Will not try to claim to be exactly a model example of piety though, in
any case...

I guess presumably now I can get back to "business as usual" (working on
my projects and similar; and then needing to divide my time with
machining parts out of metal, ...).

On Tue, 20 Jun 2023 07:57:09 +0200, Terje Mathisen
<terje.mathisen@tmsw.no> wrote:

>Digging 400KV cables into the ground is about 3X more costly than
>overhead power lines, but that does of course not translate into a 3X
>cost for electricity, just for that specific part of the long distance
>transmission. You could maybe add 3-10 cent/kWh?

That's just simple installation ... in the US at least you would have
to add in the costs of obtaining permission to dig: state, local, and
maybe federal also depending on where. Then there would be endless
lawsuits from environmentalists worried about ground squirrels (or
whatever) being displaced by digging, and from neighbors (if there are
any) concerned about how the digging would be disruptive to their
lives, or how the buried lines might be dangerous to them.

The higher the line voltage, the more opposition you would face. In
many places local 10..20 KV lines do get buried [they are in my
community], but people regularly see those same voltage wires on poles
so they aren't terribly afraid of them. However, start talking about
burying 100+KV lines that normally are strung on /towers/ protected by
fences ... then people start to freak out.

By the time you started digging, you would already have spent 10..15
times the simple installation cost just getting permission to do it.

And note that you would face exactly the same obstacles trying to put
up a line of transmission towers - however the line of towers would be
far less costly than digging a ditch of the same length. You can guess
what happens.

>Terje

YMMV,
George