On Tuesday, January 4, 2022 at 11:49:54 AM UTC-6, Stephen Fuld wrote:
> On 1/3/2022 6:56 PM, Stephen Fuld wrote:
> > On 1/3/2022 5:59 PM, MitchAlsup wrote:
> >> On Monday, January 3, 2022 at 7:31:39 PM UTC-6, Stephen Fuld wrote:
> >>> On 1/3/2022 5:04 PM, MitchAlsup wrote:
> >>>> On Monday, January 3, 2022 at 4:12:44 PM UTC-6, Stephen Fuld wrote:
> >>>>> On 1/3/2022 1:10 AM, David Brown wrote:
> >>> snip
> >>>>>> I think the best organisation for a language is to have as much as
> >>>>>> possible be part of the standard library (or libraries), with core
> >>>>>> language features aimed primarily at making it practical to implement
> >>>>>> such libraries efficiently and use them conveniently and safely.
> >>>>> I am not sure I agree with that. For some features, having them in the
> >>>>> library leads to harder to comprehend code. Going back to my old
> >>>>> example, inserting a bit field into a variable, if implemented as
> >>>>> purely
> >>>>> a library function might look something like
> >>>>>
> >>>>> X = insertbits(X,4,3,0x010b)
> >>>>>
> >>>>> Whereas if it was a pseudo function in the language (such as it is in
> >>>>> Fortran), it is more like
> >>>>>
> >>>>> Bits (X,4,3) = 0x010b
> >>>> <
> >>>> Wouldn't something like:
> >>>> <
> >>>> x<3:4> = 0x01b;
> >>>> or
> >>>> x[3:4] = 0x01b;
> >>>> or in Ada fashion
> >>>> x'bits<3:4> = 0x01b;
> >>>> <
> >>>> be even MORE natural ?
> >>> Sure. As I said before, I have no problems with that. But I don't see
> >>> how that syntax can be accommodated via function call syntax either.
> >> <
> >> Perhaps it should NOT be accommodated via function call syntax.
> >
> > That is the point I was trying to make arguing against every optional
> > feature being in the library. I absolutely agree with you.
> >
> >
> >> <
> >> But this leads to problems where one is allowed to modify some bits of
> >> a struct
> >> and not others--can one use the word const on the structure member
> >> elements
> >> that are not written, allowing (by default) those without to be
> >> written ? That is
> >> we have a partial l-value ?
> >
> > Good questions. Obviously, this needs to all be worked out, hopefully
> > in some sort of standard. :-(
> After thinking about this some more -
>
> This seems similar to allowing modification of one element of a struct
> and not another, even without bit field operations. So perhaps the same
> rules should apply.
<
Yes, indeed, the same rules apply for all containers (even those which are not
necessarily the bit-width of native containers).
>
> And, I think that to minimize coding errors, perhaps one should not
> allow bit field modification on structs, only on the elements of a
> struct. If you wanted a modification to span two adjacent elements of a
> struct, you would have to code two assignment statements, but the
> compiler would be free to optimize this into a single set of operations.
<
I, personally, think that vector of bit fields, each having a given width,
is the proper abstraction. If these things cross natural container boundaries
the compiler has to emit code to "do the right thing".
<
struct { unsigned long int a : 13[42]; }
<
This creates a structure (with struct alignment) containing 42 containers
each container having 13-bits. You can get at each container using array
notation a[i] as either an r-value or as an l-value.
<
But this is just sufficient for static field definitions. And static bit-fields
is all I have ever used, so my knowledge base takes a hard stop on dynamic
bit fields.
>
> I am not saying this is the definitive answer - just more thoughts.
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

On 1/4/2022 10:29 AM, MitchAlsup wrote:
> On Tuesday, January 4, 2022 at 11:49:54 AM UTC-6, Stephen Fuld wrote:
>> On 1/3/2022 6:56 PM, Stephen Fuld wrote:
>>> On 1/3/2022 5:59 PM, MitchAlsup wrote:
>>>> On Monday, January 3, 2022 at 7:31:39 PM UTC-6, Stephen Fuld wrote:
>>>>> On 1/3/2022 5:04 PM, MitchAlsup wrote:
>>>>>> On Monday, January 3, 2022 at 4:12:44 PM UTC-6, Stephen Fuld wrote:
>>>>>>> On 1/3/2022 1:10 AM, David Brown wrote:
>>>>> snip
>>>>>>>> I think the best organisation for a language is to have as much as
>>>>>>>> possible be part of the standard library (or libraries), with core
>>>>>>>> language features aimed primarily at making it practical to implement
>>>>>>>> such libraries efficiently and use them conveniently and safely.
>>>>>>> I am not sure I agree with that. For some features, having them in the
>>>>>>> library leads to harder to comprehend code. Going back to my old
>>>>>>> example, inserting a bit field into a variable, if implemented as
>>>>>>> purely
>>>>>>> a library function might look something like
>>>>>>>
>>>>>>> X = insertbits(X,4,3,0x010b)
>>>>>>>
>>>>>>> Whereas if it was a pseudo function in the language (such as it is in
>>>>>>> Fortran), it is more like
>>>>>>>
>>>>>>> Bits (X,4,3) = 0x010b
>>>>>> <
>>>>>> Wouldn't something like:
>>>>>> <
>>>>>> x<3:4> = 0x01b;
>>>>>> or
>>>>>> x[3:4] = 0x01b;
>>>>>> or in Ada fashion
>>>>>> x'bits<3:4> = 0x01b;
>>>>>> <
>>>>>> be even MORE natural ?
>>>>> Sure. As I said before, I have no problems with that. But I don't see
>>>>> how that syntax can be accommodated via function call syntax either.
>>>> <
>>>> Perhaps it should NOT be accommodated via function call syntax.
>>>
>>> That is the point I was trying to make arguing against every optional
>>> feature being in the library. I absolutely agree with you.
>>>
>>>
>>>> <
>>>> But this leads to problems where one is allowed to modify some bits of
>>>> a struct
>>>> and not others--can one use the word const on the structure member
>>>> elements
>>>> that are not written, allowing (by default) those without to be
>>>> written ? That is
>>>> we have a partial l-value ?
>>>
>>> Good questions. Obviously, this needs to all be worked out, hopefully
>>> in some sort of standard. :-(
>> After thinking about this some more -
>>
>> This seems similar to allowing modification of one element of a struct
>> and not another, even without bit field operations. So perhaps the same
>> rules should apply.
> <
> Yes, indeed, the same rules apply for all containers (even those which are not
> necessarily the bit-width of native containers).
>>
>> And, I think that to minimize coding errors, perhaps one should not
>> allow bit field modification on structs, only on the elements of a
>> struct. If you wanted a modification to span two adjacent elements of a
>> struct, you would have to code two assignment statements, but the
>> compiler would be free to optimize this into a single set of operations.
> <
> I, personally, think that vector of bit fields, each having a given width,
> is the proper abstraction. If these things cross natural container boundaries
> the compiler has to emit code to "do the right thing".
> <
> struct { unsigned long int a : 13[42]; }
> <
> This creates a structure (with struct alignment) containing 42 containers
> each container having 13-bits. You can get at each container using array
> notation a[i] as either an r-value or as an l-value.
> <
> But this is just sufficient for static field definitions. And static bit-fields
> is all I have ever used, so my knowledge base takes a hard stop on dynamic
> bit fields.

Looks like you have invented a possible new ISA. Perhaps we should call
it "432"?

On Tuesday, January 4, 2022 at 3:29:18 PM UTC-6, Ivan Godard wrote:
> On 1/4/2022 10:29 AM, MitchAlsup wrote:
> > On Tuesday, January 4, 2022 at 11:49:54 AM UTC-6, Stephen Fuld wrote:
> >> On 1/3/2022 6:56 PM, Stephen Fuld wrote:
> >>> On 1/3/2022 5:59 PM, MitchAlsup wrote:
> >>>> On Monday, January 3, 2022 at 7:31:39 PM UTC-6, Stephen Fuld wrote:
> >>>>> On 1/3/2022 5:04 PM, MitchAlsup wrote:
> >>>>>> On Monday, January 3, 2022 at 4:12:44 PM UTC-6, Stephen Fuld wrote:
> >>>>>>> On 1/3/2022 1:10 AM, David Brown wrote:
> >>>>> snip
> >>>>>>>> I think the best organisation for a language is to have as much as
> >>>>>>>> possible be part of the standard library (or libraries), with core
> >>>>>>>> language features aimed primarily at making it practical to implement
> >>>>>>>> such libraries efficiently and use them conveniently and safely.
> >>>>>>> I am not sure I agree with that. For some features, having them in the
> >>>>>>> library leads to harder to comprehend code. Going back to my old
> >>>>>>> example, inserting a bit field into a variable, if implemented as
> >>>>>>> purely
> >>>>>>> a library function might look something like
> >>>>>>>
> >>>>>>> X = insertbits(X,4,3,0x010b)
> >>>>>>>
> >>>>>>> Whereas if it was a pseudo function in the language (such as it is in
> >>>>>>> Fortran), it is more like
> >>>>>>>
> >>>>>>> Bits (X,4,3) = 0x010b
> >>>>>> <
> >>>>>> Wouldn't something like:
> >>>>>> <
> >>>>>> x<3:4> = 0x01b;
> >>>>>> or
> >>>>>> x[3:4] = 0x01b;
> >>>>>> or in Ada fashion
> >>>>>> x'bits<3:4> = 0x01b;
> >>>>>> <
> >>>>>> be even MORE natural ?
> >>>>> Sure. As I said before, I have no problems with that. But I don't see
> >>>>> how that syntax can be accommodated via function call syntax either.
> >>>> <
> >>>> Perhaps it should NOT be accommodated via function call syntax.
> >>>
> >>> That is the point I was trying to make arguing against every optional
> >>> feature being in the library. I absolutely agree with you.
> >>>
> >>>
> >>>> <
> >>>> But this leads to problems where one is allowed to modify some bits of
> >>>> a struct
> >>>> and not others--can one use the word const on the structure member
> >>>> elements
> >>>> that are not written, allowing (by default) those without to be
> >>>> written ? That is
> >>>> we have a partial l-value ?
> >>>
> >>> Good questions. Obviously, this needs to all be worked out, hopefully
> >>> in some sort of standard. :-(
> >> After thinking about this some more -
> >>
> >> This seems similar to allowing modification of one element of a struct
> >> and not another, even without bit field operations. So perhaps the same
> >> rules should apply.
> > <
> > Yes, indeed, the same rules apply for all containers (even those which are not
> > necessarily the bit-width of native containers).
> >>
> >> And, I think that to minimize coding errors, perhaps one should not
> >> allow bit field modification on structs, only on the elements of a
> >> struct. If you wanted a modification to span two adjacent elements of a
> >> struct, you would have to code two assignment statements, but the
> >> compiler would be free to optimize this into a single set of operations.
> > <
> > I, personally, think that vector of bit fields, each having a given width,
> > is the proper abstraction. If these things cross natural container boundaries
> > the compiler has to emit code to "do the right thing".
> > <
> > struct { unsigned long int a : 13[42]; }
> > <
> > This creates a structure (with struct alignment) containing 42 containers
> > each container having 13-bits. You can get at each container using array
> > notation a[i] as either an r-value or as an l-value.
> > <
> > But this is just sufficient for static field definitions. And static bit-fields
> > is all I have ever used, so my knowledge base takes a hard stop on dynamic
> > bit fields.
<
> Looks like you have invented a possible new ISA. Perhaps we should call
> it "432"?
<
Off your meds ?

On Tuesday, 4 January 2022 at 20:29:51 UTC+2, MitchAlsup wrote:
> On Tuesday, January 4, 2022 at 11:49:54 AM UTC-6, Stephen Fuld wrote:
> > On 1/3/2022 6:56 PM, Stephen Fuld wrote:
> > > On 1/3/2022 5:59 PM, MitchAlsup wrote:
> > >> On Monday, January 3, 2022 at 7:31:39 PM UTC-6, Stephen Fuld wrote:
> > >>> On 1/3/2022 5:04 PM, MitchAlsup wrote:
> > >>>> On Monday, January 3, 2022 at 4:12:44 PM UTC-6, Stephen Fuld wrote:
> > >>>>> On 1/3/2022 1:10 AM, David Brown wrote:
> > >>> snip
> > >>>>>> I think the best organisation for a language is to have as much as
> > >>>>>> possible be part of the standard library (or libraries), with core
> > >>>>>> language features aimed primarily at making it practical to implement
> > >>>>>> such libraries efficiently and use them conveniently and safely.
> > >>>>> I am not sure I agree with that. For some features, having them in the
> > >>>>> library leads to harder to comprehend code. Going back to my old
> > >>>>> example, inserting a bit field into a variable, if implemented as
> > >>>>> purely
> > >>>>> a library function might look something like
> > >>>>>
> > >>>>> X = insertbits(X,4,3,0x010b)
> > >>>>>
> > >>>>> Whereas if it was a pseudo function in the language (such as it is in
> > >>>>> Fortran), it is more like
> > >>>>>
> > >>>>> Bits (X,4,3) = 0x010b
> > >>>> <
> > >>>> Wouldn't something like:
> > >>>> <
> > >>>> x<3:4> = 0x01b;
> > >>>> or
> > >>>> x[3:4] = 0x01b;
> > >>>> or in Ada fashion
> > >>>> x'bits<3:4> = 0x01b;
> > >>>> <
> > >>>> be even MORE natural ?
> > >>> Sure. As I said before, I have no problems with that. But I don't see
> > >>> how that syntax can be accommodated via function call syntax either.
> > >> <
> > >> Perhaps it should NOT be accommodated via function call syntax.
> > >
> > > That is the point I was trying to make arguing against every optional
> > > feature being in the library. I absolutely agree with you.
> > >
> > >
> > >> <
> > >> But this leads to problems where one is allowed to modify some bits of
> > >> a struct
> > >> and not others--can one use the word const on the structure member
> > >> elements
> > >> that are not written, allowing (by default) those without to be
> > >> written ? That is
> > >> we have a partial l-value ?
> > >
> > > Good questions. Obviously, this needs to all be worked out, hopefully
> > > in some sort of standard. :-(
> > After thinking about this some more -
> >
> > This seems similar to allowing modification of one element of a struct
> > and not another, even without bit field operations. So perhaps the same
> > rules should apply.
> <
> Yes, indeed, the same rules apply for all containers (even those which are not
> necessarily the bit-width of native containers).
> >
> > And, I think that to minimize coding errors, perhaps one should not
> > allow bit field modification on structs, only on the elements of a
> > struct. If you wanted a modification to span two adjacent elements of a
> > struct, you would have to code two assignment statements, but the
> > compiler would be free to optimize this into a single set of operations.
> <
> I, personally, think that vector of bit fields, each having a given width,
> is the proper abstraction. If these things cross natural container boundaries
> the compiler has to emit code to "do the right thing".
> <
> struct { unsigned long int a : 13[42]; }
> <
Interesting idea! Were the "long" and "int" keywords used there
"just because" ... or for some meaning?
> This creates a structure (with struct alignment) containing 42 containers
> each container having 13-bits. You can get at each container using array
> notation a[i] as either an r-value or as an l-value.
> <
Why only in struct? If to think ... then 64 bit pointers and sizes could
operate in exabyte with bit-by-bit precision.

> But this is just sufficient for static field definitions. And static bit-fields
> is all I have ever used, so my knowledge base takes a hard stop on dynamic
> bit fields.

That might be perhaps like with most compression algorithms (that operate
usually at one bit granularity with varying bit width values). It is rather tricky
to organize random access passably enough or to prevent few bit errors
from corrupting whole data ... but that does not make these useless.

On Tuesday, January 4, 2022 at 7:29:25 PM UTC-6, oot...@hot.ee wrote:
> On Tuesday, 4 January 2022 at 20:29:51 UTC+2, MitchAlsup wrote:

> > > And, I think that to minimize coding errors, perhaps one should not
> > > allow bit field modification on structs, only on the elements of a
> > > struct. If you wanted a modification to span two adjacent elements of a
> > > struct, you would have to code two assignment statements, but the
> > > compiler would be free to optimize this into a single set of operations.
> > <
> > I, personally, think that vector of bit fields, each having a given width,
> > is the proper abstraction. If these things cross natural container boundaries
> > the compiler has to emit code to "do the right thing".
> > <
> > struct { unsigned long int a : 13[42]; }
> > <
> Interesting idea! Were the "long" and "int" keywords used there
> "just because" ... or for some meaning?
<
Technically, unsigned is an int, long is an int in most contexts (but not long double)
so, I just use them all for clarity.
<
> > This creates a structure (with struct alignment) containing 42 containers
> > each container having 13-bits. You can get at each container using array
> > notation a[i] as either an r-value or as an l-value.
> > <
> Why only in struct? If to think ... then 64 bit pointers and sizes could
> operate in exabyte with bit-by-bit precision.
<
C only <currently> has bit fields inside of structs (¿and unions?) and this is
the context in which the : operator denotes bit field length.
<
Also notice I did not enable the taking of a bit-field's address (&) nor did I
allow for dereferencing of a bit-fields container--except through array indexing.
<
> > But this is just sufficient for static field definitions. And static bit-fields
> > is all I have ever used, so my knowledge base takes a hard stop on dynamic
> > bit fields.
<
> That might be perhaps like with most compression algorithms (that operate
> usually at one bit granularity with varying bit width values). It is rather tricky
> to organize random access passably enough or to prevent few bit errors
> from corrupting whole data ... but that does not make these useless.

On 2022-01-04, Thomas Koenig wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb:
>> On 1/4/2022 9:29 AM, EricP wrote:
>>> Stephen Fuld wrote:
>>>> On 1/3/2022 2:32 PM, David Brown wrote:
>>>>> On 03/01/2022 23:12, Stephen Fuld wrote:
>>>>>> On 1/3/2022 1:10 AM, David Brown wrote:
>>>>>>> On 02/01/2022 18:24, Stephen Fuld wrote:
>>>>>>> And if
>>>>>>> you can make the library modular, then having an "optional feature"
>>>>>>> simply becomes a choice of including the library
>>>>>>> header/module/unit/whatever in your program.
>>>>>>
>>>>>> Yes.  Optional library functions are fine for many things things
>>>>>> that do
>>>>>> a lot of work per call, but ISTM are not appropriate for some other
>>>>>> types of things.
>>>>>>
>>>>>
>>>>> They are absolutely fine for small things too.  However, you want inline
>>>>> definitions to avoid function call overhead and hugely improve the
>>>>> optimisation opportunities.  (And ideally you want a language to have a
>>>>> good system of pre-compiled or pre-analysed modules, rather than pure
>>>>> textual inclusion like C++ prior to C++20.)
>>>>
>>>>
>>>> I am in regard to C++ where you are in regard to Fortran, so I can't
>>>> really comment, but if the compiler knows that a particular function
>>>> can be inlined, doesn't it mean the compiler knows what the function
>>>> does? And if that is true, then ISTM that it is a matter of syntax
>>>> preference, i.e. ease of user comprehension, whether to have the
>>>> compiler recognize the function or some equivalent syntax?
>>>
>>> The VAX Ada85 compiler supported modular separate compilation and inlining.
>>
>> snipped description
>>
>> Interesting. Do current C compilers do something equivalent?
>
> Link-time optimization might come closest >
> gcc with the -flto option, for example, generates a special object
> code which contains GIMPLE (its SSA intermediate representation)
> which is then optimized together, including inlining, cloning,
> constant propagation and all the rest of the fun stuff.
>
> This is especially valuable for a language which has a large
> potential overhead in procedure calls, like Fortran's assumed-shape
> arrays have.
>

I think LTO is more powerful than what Eric described, which I think
requires that the "header file" (interface definition) contains enough
information to tell how functions are called etc. C/C++ has no such
mechanism (header files are just preprocessor text, with no guarantee of
what is contained within them).

/Marcus

Thomas Koenig <tkoenig@netcologne.de> schrieb:

> Maybe here's a better version:
>
> https://godbolt.org/z/9xKcfaezM
>
> This is a version tranlsated from what gfortran hands to gcc's
> middle end into C, for those who do not have a Fortran compiler :-)
>
> What does your compiler make of that function?

So I finally installed the My 66000 compiler. For anybody who,
like me, is unfamiliar with LLVM: It took me a bit to find the
-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=My66000 option.

I did remove the superflous (long int)(int) casts, which were
introduced by a minor bug in the original Fortran code.

The inner loop of the code for zeroing the array is

{
long S_19;
long D_3939;

D_3939 = S_18 * stride_15 + D_3933;
S_19 = 1;
while (1)
{
if (S_19 > D_3934)
goto L_1;
c_0[S_19 * D_3937 + D_3939] = 0.0;
S_19 = S_19 + 1;
}
L_1:;
}

where the inner loop is translated with "clang -O3 --target=my66000
-S mm.c" to

..LBB0_4: ; %if.end96
; Parent Loop BB0_3 Depth=1
; => This Inner Loop Header: Depth=2
std #0,[r24]
add r23,r23,#-1
add r24,r24,r27
bne0 r23,.LBB0_4
; %bb.5:

so no LOOP statement. Would this not be beneficial, or is it
simply a pattern that is currently not yet recognized?

On 1/5/22 07:13, Thomas Koenig wrote:
....

> where the inner loop is translated with "clang -O3 --target=my66000
> -S mm.c" to
>
> .LBB0_4: ; %if.end96
> ; Parent Loop BB0_3 Depth=1
> ; => This Inner Loop Header: Depth=2
> std #0,[r24]
> add r23,r23,#-1
> add r24,r24,r27
> bne0 r23,.LBB0_4
> ; %bb.5:
>
> so no LOOP statement. Would this not be beneficial, or is it
> simply a pattern that is currently not yet recognized?
>

The LOOP optimization is off by default. Add "-enable-vvm" to flags
passed to the LLVM My66000 backend. I don't know how to pass that via Clang,
I just get the *.ll IR and run the backend separately.

Brian

Thomas Koenig <tkoenig@netcologne.de> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> schrieb:
>
>> Maybe here's a better version:
>>
>> https://godbolt.org/z/9xKcfaezM
>>
>> This is a version tranlsated from what gfortran hands to gcc's
>> middle end into C, for those who do not have a Fortran compiler :-)
>>
>> What does your compiler make of that function?
>
> So I finally installed the My 66000 compiler. For anybody who,
> like me, is unfamiliar with LLVM: It took me a bit to find the
> -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=My66000 option.
>
> I did remove the superflous (long int)(int) casts, which were
> introduced by a minor bug in the original Fortran code.
>
> The inner loop of the code for zeroing the array is
>
> {
> long S_19;
> long D_3939;
>
> D_3939 = S_18 * stride_15 + D_3933;
> S_19 = 1;
> while (1)
> {
> if (S_19 > D_3934)
> goto L_1;
> c_0[S_19 * D_3937 + D_3939] = 0.0;
> S_19 = S_19 + 1;
> }
> L_1:;
> }
>
> where the inner loop is translated with "clang -O3 --target=my66000
> -S mm.c" to
>
> .LBB0_4: ; %if.end96
> ; Parent Loop BB0_3 Depth=1
> ; => This Inner Loop Header: Depth=2
> std #0,[r24]
> add r23,r23,#-1
> add r24,r24,r27
> bne0 r23,.LBB0_4
> ; %bb.5:
>
> so no LOOP statement. Would this not be beneficial, or is it
> simply a pattern that is currently not yet recognized?

.... or did I miss an option I should have specified?

Brian G. Lucas <bagel99@gmail.com> schrieb:
> On 1/5/22 07:13, Thomas Koenig wrote:
> ...
>
>> where the inner loop is translated with "clang -O3 --target=my66000
>> -S mm.c" to
>>
>> .LBB0_4: ; %if.end96
>> ; Parent Loop BB0_3 Depth=1
>> ; => This Inner Loop Header: Depth=2
>> std #0,[r24]
>> add r23,r23,#-1
>> add r24,r24,r27
>> bne0 r23,.LBB0_4
>> ; %bb.5:
>>
>> so no LOOP statement. Would this not be beneficial, or is it
>> simply a pattern that is currently not yet recognized?
>>
>
> The LOOP optimization is off by default. Add "-enable-vvm" to flags
> passed to the LLVM My66000 backend. I don't know how to pass that via Clang,
> I just get the *.ll IR and run the backend separately.

Got it, thanks.

Just getting through things. One thing struck me at first glance:
Is the ISA not well suited to tail-call optimization?

I ran a gfortran library file (preprocessed) and got code like

(condition branches here)

mov r1,r26
mov r2,r28
mov r3,r30
call _gfortran_maxloc0_8_r8
..Ltmp96:
br .LBB1_45

(where the last branch is to an EXIT) for a tail call:

if (mask ==
((void *)0)
|| *mask)
{
maxloc0_8_r8 (retarray, array, back);
return;
}

or is this simply something that is not yet on the agenda because
100 things have a higher coolness factor and a higher need?

On Wednesday, 5 January 2022 at 03:55:44 UTC+2, MitchAlsup wrote:
> On Tuesday, January 4, 2022 at 7:29:25 PM UTC-6, oot...@hot.ee wrote:

> > > This creates a structure (with struct alignment) containing 42 containers
> > > each container having 13-bits. You can get at each container using array
> > > notation a[i] as either an r-value or as an l-value.
> > > <
> > Why only in struct? If to think ... then 64 bit pointers and sizes could
> > operate in exabyte with bit-by-bit precision.
> <
> C only <currently> has bit fields inside of structs (¿and unions?) and this is
> the context in which the : operator denotes bit field length.
> <
> Also notice I did not enable the taking of a bit-field's address (&) nor did I
> allow for dereferencing of a bit-fields container--except through array indexing.
> <
OK, I suspect I see. Array indexing of C is defined as array to pointer
decay, pointer and integer addition and then dereference of result. So
a[i] (or i[a]) must work same as *(a + i). Your operator [] has meaning
that does not involve special bit-pointers. That kind of pointers however
might be fun to have.

MitchAlsup wrote:
> On Tuesday, January 4, 2022 at 11:49:54 AM UTC-6, Stephen Fuld wrote:
> I, personally, think that vector of bit fields, each having a given width,
> is the proper abstraction. If these things cross natural container boundaries
> the compiler has to emit code to "do the right thing".
> <
> struct { unsigned long int a : 13[42]; }
> <
> This creates a structure (with struct alignment) containing 42 containers
> each container having 13-bits. You can get at each container using array
> notation a[i] as either an r-value or as an l-value.
> <
> But this is just sufficient for static field definitions. And static bit-fields
> is all I have ever used, so my knowledge base takes a hard stop on dynamic
> bit fields.

I like your syntax, but as you say, it only works for static setups.

In reality, I'd estimate 90-99% of all bitfield operations today are in
the form of decompressing data, be it from zip/gz/etc, or h.264/ogg
vorbis or other codecs, and these are all dynamic.

Terje

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

On Thursday, January 6, 2022 at 2:20:08 AM UTC-6, Terje Mathisen wrote:
> MitchAlsup wrote:
> > On Tuesday, January 4, 2022 at 11:49:54 AM UTC-6, Stephen Fuld wrote:
> > I, personally, think that vector of bit fields, each having a given width,
> > is the proper abstraction. If these things cross natural container boundaries
> > the compiler has to emit code to "do the right thing".
> > <
> > struct { unsigned long int a : 13[42]; }
> > <
> > This creates a structure (with struct alignment) containing 42 containers
> > each container having 13-bits. You can get at each container using array
> > notation a[i] as either an r-value or as an l-value.
> > <
> > But this is just sufficient for static field definitions. And static bit-fields
> > is all I have ever used, so my knowledge base takes a hard stop on dynamic
> > bit fields.
> I like your syntax, but as you say, it only works for static setups.
>
> In reality, I'd estimate 90-99% of all bitfield operations today are in
> the form of decompressing data, be it from zip/gz/etc, or h.264/ogg
> vorbis or other codecs, and these are all dynamic.
<
The bit field INSTRUCTIONs can be worked dynamically,
The bit field SYNTAX in C war not so enabled.
>
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

On Thursday, January 6, 2022 at 1:17:21 AM UTC-6, oot...@hot.ee wrote:
> On Wednesday, 5 January 2022 at 03:55:44 UTC+2, MitchAlsup wrote:
> > On Tuesday, January 4, 2022 at 7:29:25 PM UTC-6, oot...@hot.ee wrote:
>
> > > > This creates a structure (with struct alignment) containing 42 containers
> > > > each container having 13-bits. You can get at each container using array
> > > > notation a[i] as either an r-value or as an l-value.
> > > > <
> > > Why only in struct? If to think ... then 64 bit pointers and sizes could
> > > operate in exabyte with bit-by-bit precision.
> > <
> > C only <currently> has bit fields inside of structs (¿and unions?) and this is
> > the context in which the : operator denotes bit field length.
> > <
> > Also notice I did not enable the taking of a bit-field's address (&) nor did I
> > allow for dereferencing of a bit-fields container--except through array indexing.
> > <
> OK, I suspect I see. Array indexing of C is defined as array to pointer
> decay, pointer and integer addition and then dereference of result. So
> a[i] (or i[a]) must work same as *(a + i). Your operator [] has meaning
> that does not involve special bit-pointers. That kind of pointers however
> might be fun to have.
<
I am suggesting the the [] operator in the context of bit-fields does not have
the pointer+integer arithmetics that the <open> [] operator has. This is the
same as the , operator operating in <open> context simply throws the
left hand side away, while in argument context it provides separators for
individual definitions on the entry point definition, and acts like a list
creator on the calling side.

On 1/5/22 15:42, Thomas Koenig wrote:
....
>
> Just getting through things. One thing struck me at first glance:
> Is the ISA not well suited to tail-call optimization?
>
> I ran a gfortran library file (preprocessed) and got code like
>
> (condition branches here)
>
> mov r1,r26
> mov r2,r28
> mov r3,r30
> call _gfortran_maxloc0_8_r8
> .Ltmp96:
> br .LBB1_45
>
> (where the last branch is to an EXIT) for a tail call:
>
> if (mask ==
> ((void *)0)
> || *mask)
> {
> maxloc0_8_r8 (retarray, array, back);
> return;
> }
>
> or is this simply something that is not yet on the agenda because
> 100 things have a higher coolness factor and a higher need?
>
Some tail calls should work, but yes, this was low on the priority list.

Brian

Thomas Koenig <tkoenig@netcologne.de> writes:

> George Neuner <gneuner2@comcast.net> schrieb:
>
>> On Sat, 25 Dec 2021 16:53:06 -0800 (PST), Othman Ahmad
>> <othmana@gmail.com> wrote:
>>
>>> vectors are arrays. define arrays and operators to for these
>>> arrays
>>
>> You need to be careful with that analogy: a vector and a 1D array
>> look very similar, but a vector of vectors is not the same as a 2D
>> array.
>
> Very much so.
>
> It is one of the weaknesses of C that a multi-dimensional array
> is not very well supported. You either have the pointer forest,
> or you have to roll your own indexing manually.

C does have multidimensional arrays (ie, not just pointer forests
or indexing done manually). It may not have the kind of such
arrays that you are used to using, but it does have arrays that
have more than one dimension.

MitchAlsup <MitchAlsup@aol.com> writes:

[ on using [] to index arrays of chosen-width bit values ]

> I am suggesting the the [] operator in the context of bit-fields
> does not have the pointer+integer arithmetics that the <open> []
> operator has. This is the same as the , operator operating in
> <open> context simply throws the left hand side away, while in
> argument context it provides separators for individual definitions
> on the entry point definition, and acts like a list creator on the
> calling side.

This analogy doesn't quite hold up. The commas in a function
call expression are not comma operators, ie, the distinction
is syntactic, not semantic. Presumably using [] to access
arrays of chosen-width bit values would hinge on a semantic
distinction, not a syntactic one.

George Neuner <gneuner2@comcast.net> writes:

> C supports 'vectors of vectors' ... not multi-dimensional arrays.
>
> E.g., suppose you define 'int arr[2][10]'.
>
> In C you will get a block of memory that can hold 20 contiguous ints
> ... but that block has no internal structure: nothing but compiler
> warnings prevent you from referencing arr[1][2] as arr[-1][22], or
> as arr[0][12], or as arr[2][-8], etc. Or referencing outside the
> array's memory block entirely.

That has nothing to do with dimensionality. The array bounds
are there, even if there is no guarantee that C will check them,
for multidimensional arrays as well as for one-dimensional arrays.

> In a language with true arrays, [...]

Plenty of languages have arrays without bounds checking.
And everyone calls them arrays, despite what you may think.

Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>
>> George Neuner <gneuner2@comcast.net> schrieb:
>>
>>> On Sat, 25 Dec 2021 16:53:06 -0800 (PST), Othman Ahmad
>>> <othmana@gmail.com> wrote:
>>>
>>>> vectors are arrays. define arrays and operators to for these
>>>> arrays
>>>
>>> You need to be careful with that analogy: a vector and a 1D array
>>> look very similar, but a vector of vectors is not the same as a 2D
>>> array.
>>
>> Very much so.
>>
>> It is one of the weaknesses of C that a multi-dimensional array
>> is not very well supported. You either have the pointer forest,
>> or you have to roll your own indexing manually.
>
> C does have multidimensional arrays (ie, not just pointer forests
> or indexing done manually). It may not have the kind of such
> arrays that you are used to using,

I should have qualified my statement with "In order to do useful
things, you either have...".

>but it does have arrays that
> have more than one dimension.

In order to be useful, such an array should

- have a size that can be determined at run-time

- have no artificial limitations in size imposed, for example,
by the stack

- be able to be passed to a function, in which it should be
accessed the same way that it was accessed in the calling
function

If I have missed such a feature in C, please provide a short example
program which reads an integer n, generates an n*n integer array
and passes it to a function which fills it with the absolute
difference between the indices, and then the calling function
prints out the array. In order to be useful, the program should
work with moderate n (let's say n=10000) on a Linux system with
default stack size, which is 8 MB.

Terje Mathisen <terje.mathisen@tmsw.no> writes:

[ concerning "static" versus "dynamic" bitfield access ]

> In reality, I'd estimate 90-99% of all bitfield operations today

Presumably you mean by cycles used, not by lines of code written to
perform the accesses. Yes? Or if the kinds of applications listed
below are the only ones needing dynamic bitfield access, then
clearly the demand is not large enough to add dynamic bitfield
operations to the C language.

> are in the form of decompressing data, be it from zip/gz/etc, or
> h.264/ogg vorbis or other codecs, and these are all dynamic.

My impression is this kind of application takes input in the form
of a "stream" of bits, more or less like an entire input (or
perhaps major pieces of the input) makes up an enormous shift
register. Parcels of varying widths are conceptually taken from
the "top" of the shift register, which is then (conceptually)
shifted so the next parcel is at the top. This kind of operation
is not like bitfields in the usual sense of the term (and
certainly not like the suggested forms that started this
discussion). What they are is more like bit-level addressing of
varying bit-width parcels, which may cross arbitrary memory
boundaries. That model is not, I think, a good fit for the
architectures and memory systems used in most processors
today, which means it is also not a good fit for adding to C.

On 2022-01-07, Tim Rentsch wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>
> [ concerning "static" versus "dynamic" bitfield access ]
>
>> In reality, I'd estimate 90-99% of all bitfield operations today
>
> Presumably you mean by cycles used, not by lines of code written to
> perform the accesses. Yes? Or if the kinds of applications listed
> below are the only ones needing dynamic bitfield access, then
> clearly the demand is not large enough to add dynamic bitfield
> operations to the C language.
>
>> are in the form of decompressing data, be it from zip/gz/etc, or
>> h.264/ogg vorbis or other codecs, and these are all dynamic.
>
> My impression is this kind of application takes input in the form
> of a "stream" of bits, more or less like an entire input (or
> perhaps major pieces of the input) makes up an enormous shift
> register. Parcels of varying widths are conceptually taken from
> the "top" of the shift register, which is then (conceptually)
> shifted so the next parcel is at the top. This kind of operation
> is not like bitfields in the usual sense of the term (and
> certainly not like the suggested forms that started this
> discussion). What they are is more like bit-level addressing of
> varying bit-width parcels, which may cross arbitrary memory
> boundaries. That model is not, I think, a good fit for the
> architectures and memory systems used in most processors
> today, which means it is also not a good fit for adding to C.
>

Another way of looking at bitfield operations (in a CPU) is that they
optimize certain classes of SHIFT + MASK (optionally + SIGN_EXTEND)
operations. Such sequences can be detected by a good compiler, and no
special language constructs are needed.

However, having language support can greatly help the programmer write
code that will map to optimal machine code.

Tim Rentsch wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>
> [ concerning "static" versus "dynamic" bitfield access ]
>
>> In reality, I'd estimate 90-99% of all bitfield operations today
>
> Presumably you mean by cycles used, not by lines of code written to
> perform the accesses. Yes? Or if the kinds of applications listed

Absolutely so! How many cycles total are users waiting on these
particular operations, not how many hours are developers spending
writing the code. :-)

> below are the only ones needing dynamic bitfield access, then
> clearly the demand is not large enough to add dynamic bitfield
> operations to the C language.
>
>> are in the form of decompressing data, be it from zip/gz/etc, or
>> h.264/ogg vorbis or other codecs, and these are all dynamic.
>
> My impression is this kind of application takes input in the form
> of a "stream" of bits, more or less like an entire input (or
> perhaps major pieces of the input) makes up an enormous shift
> register. Parcels of varying widths are conceptually taken from
> the "top" of the shift register, which is then (conceptually)
> shifted so the next parcel is at the top. This kind of operation

Exactly right, with the additional wrinkle that you usually don't know
how many bits you need until you've processed them.

> is not like bitfields in the usual sense of the term (and
> certainly not like the suggested forms that started this
> discussion). What they are is more like bit-level addressing of
> varying bit-width parcels, which may cross arbitrary memory
> boundaries. That model is not, I think, a good fit for the
> architectures and memory systems used in most processors
> today, which means it is also not a good fit for adding to C.
>
Probably correct.

Codecs get custum VLSI/GPU helpers, compression (zip/gz/etc) tends to be
pure sw, which makes it still very important.

Terje

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

Thomas Koenig <tkoenig@netcologne.de> schrieb:
> Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:

[...]

>> C does have multidimensional arrays (ie, not just pointer forests
>> or indexing done manually). It may not have the kind of such
>> arrays that you are used to using,
>
> I should have qualified my statement with "In order to do useful
> things, you either have...".
>
>>but it does have arrays that
>> have more than one dimension.
>
> In order to be useful, such an array should
>
> - have a size that can be determined at run-time
>
> - have no artificial limitations in size imposed, for example,
> by the stack
>
> - be able to be passed to a function, in which it should be
> accessed the same way that it was accessed in the calling
> function

In case my reference wasn't clear, here is a Fortran implementation
of what I mean.

I am leaving out assumed-shape arrays, I'm not sure everybody
knows the syntax. So, the equivalent of

$ cat a.f90
module x
implicit none
contains
subroutine foo(x,n)
integer :: n
integer, dimension(n,n) :: x
integer :: i,j
do i=1,n
do j=1,n
x(i,j) = abs(i-j)
end do
end do
end subroutine foo
end module x
program main
use x
implicit none
integer, dimension(:,:), allocatable :: f
integer :: n,i,j
read (*,*) n
allocate (f(n,n))
call foo(f,n)
do j=1,n
do i=1,n
write (*,'(G0,X)',advance="no" ) f(i,j)
end do
write (*,'()')
end do
end program main
$ gfortran -O2 a.f90
$ echo 3 | ./a.out
0 1 2
1 0 1
2 1 0
$ echo 10000 | ./a.out | wc -l
10000

(the last command will run a couple of minutes due to I/O overhead).

On 2022-01-07 23:31, Thomas Koenig wrote:
> Thomas Koenig <tkoenig@netcologne.de> schrieb:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
>
> [...]
>
>>> C does have multidimensional arrays (ie, not just pointer forests
>>> or indexing done manually). It may not have the kind of such
>>> arrays that you are used to using,
>>
>> I should have qualified my statement with "In order to do useful
>> things, you either have...".
>>
>>> but it does have arrays that
>>> have more than one dimension.
>>
>> In order to be useful, such an array should
>>
>> - have a size that can be determined at run-time
>>
>> - have no artificial limitations in size imposed, for example,
>> by the stack
>>
>> - be able to be passed to a function, in which it should be
>> accessed the same way that it was accessed in the calling
>> function
>
> In case my reference wasn't clear, here is a Fortran implementation
> of what I mean.
>
> I am leaving out assumed-shape arrays, I'm not sure everybody
> knows the syntax. So, the equivalent of
>
> $ cat a.f90
> module x
> implicit none
> contains
> subroutine foo(x,n)
> integer :: n
> integer, dimension(n,n) :: x
> integer :: i,j
> do i=1,n
> do j=1,n
> x(i,j) = abs(i-j)
> end do
> end do
> end subroutine foo
> end module x
> program main
> use x
> implicit none
> integer, dimension(:,:), allocatable :: f
> integer :: n,i,j
> read (*,*) n
> allocate (f(n,n))
> call foo(f,n)
> do j=1,n
> do i=1,n
> write (*,'(G0,X)',advance="no" ) f(i,j)
> end do
> write (*,'()')
> end do
> end program main
> $ gfortran -O2 a.f90
> $ echo 3 | ./a.out
> 0 1 2
> 1 0 1
> 2 1 0
> $ echo 10000 | ./a.out | wc -l
> 10000
>
> (the last command will run a couple of minutes due to I/O overhead).

The challenge may have been intended specifically for C, but as the
thread has talked about several languages, here is an Ada equivalent.
For simplicity I nested the Foo procedure into the main procedure, but
it could of course be in a separate module (a package) with trivial
syntax changes.

A difference to the Fortran solution is that when the array F is passed
to Foo, the parameter must be written "F.all" instead of plain "F", as
Foo is declared to take a Matrix, while F is a pointer (access) to a
Matrix. I could have avoided that by making Foo take an "access Matrix"
parameter, but then I could not have declared that parameter to be only
an output (result) parameter.

with Ada.Text_IO, Ada.Integer_Text_IO;
procedure Big_Matrix is
use Ada.Text_IO, Ada.Integer_Text_IO;
type Matrix is array (Positive range <>, Positive range <>)
of Integer;

procedure Foo (X : out Matrix) is
begin
for I in X'Range(1) loop
for J in X'Range(2) loop
X(I,J) := abs (I - J);
end loop;
end loop;
end Foo;

N : Natural;

begin
Get (N);
declare
F : access Matrix := new Matrix (1 .. N, 1 .. N);
begin
Foo (F.all);
for J in F'Range(2) loop
for I in F'Range(1) loop
Put (F(I,J), Width => 9);
end loop;
New_Line;
end loop;
end;
end Big_Matrix;

Niklas Holsti <niklas.holsti@tidorum.invalid> schrieb:
> On 2022-01-07 23:31, Thomas Koenig wrote:
>> Thomas Koenig <tkoenig@netcologne.de> schrieb:

> The challenge may have been intended specifically for C,

Definitely.

> but as the
> thread has talked about several languages, here is an Ada equivalent.

Just for the record, I was aware that Ada can do this :-)

> For simplicity I nested the Foo procedure into the main procedure, but
> it could of course be in a separate module (a package) with trivial
> syntax changes.

Actually, I made the Fortran program not use the more advanced
features of passing an assumed-shape array (not that the callee
makes assumptions about the array, but that the shape is assumed
from the caller - I always find that bit of terminolgy a little
confusing), but this sort of feature would definitely not follow
the "small language" philosophy of C.

>
> A difference to the Fortran solution is that when the array F is passed
> to Foo, the parameter must be written "F.all" instead of plain "F", as
> Foo is declared to take a Matrix, while F is a pointer (access) to a
> Matrix. I could have avoided that by making Foo take an "access Matrix"
> parameter, but then I could not have declared that parameter to be only
> an output (result) parameter.
>
>
> with Ada.Text_IO, Ada.Integer_Text_IO;
> procedure Big_Matrix is
> use Ada.Text_IO, Ada.Integer_Text_IO;
> type Matrix is array (Positive range <>, Positive range <>)
> of Integer;
>
> procedure Foo (X : out Matrix) is
> begin
> for I in X'Range(1) loop
> for J in X'Range(2) loop
> X(I,J) := abs (I - J);
> end loop;
> end loop;
> end Foo;

The equivalent of that in Fortran would be

subroutine foo(x)
integer, dimension(:,:), intent(out) :: x
integer :: i,j
do i=1,size(x,1)
do j=1,size(x,2)
x(i,j) = abs(i-j)
end do
end do
end subroutine foo

Someday, somebody maybe write up the history of which language
infuenced which. I believe Fortran modules were strongly influenced
by Ada packages, and the separation between public and private
specifications was only introduced in Fortran with the 2008 standard
with submodules.