Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb:
> On 12/31/2021 6:44 AM, David Brown wrote:
>> Sometimes you want sparse arrays, or arrays with flexible sizes in one
>> or more dimensions. Maybe you want range checking on access. That's
>> all possible, but comes at a cost (sometimes a significant cost)
>> compared to a simpler fixed-size array.
>
> I may be wrong, but I think most of these are provided in, for example,
> Julia. And others should provide more definitive knowledge, but I think
> at least some of these are in the newer versions of Fortran.

Fortran has had pointer arrays since Fortran 90 and allocatable
arrays since a TR specifying them came out sometime before
Fortran 2003.

Pointer arrays can be allocated, or they can point at some
existing array. The programmer has to make sure that memory
gets freed.

Allocatable arrays can be allocated explicitly, or implicitly by
an assignment statement. For example,

program x
real, dimension(10) :: a
real, dimension(:), allocatable :: b
call random_number(a)
b = pack(a,a>0.5)
print *,b
print *,size(b)
end program x

just printed

0.547889769 0.603673220 0.927133501 0.767404437
4

on my machine.

>> Perhaps you want mixed array/scaler operations - such as making "A = x;"
>> initialise every element of array "A" with the value "x". That does not
>> cause additional run-time costs for those that don't want the operation,
>> but it reduces the compile-time error checking and safety of the type
>> for those that would prefer it to be an error.

Fortran will let you do that. It will also allow element-wise
arithmetic where scalars and arrays are mixed, so

a = b + 0.5

is fine where a and b have the same shape.

I think a major influence on Fortran was Matlab.

On 02/01/2022 18:24, Stephen Fuld wrote:
> On 12/31/2021 6:44 AM, David Brown wrote:
>> On 30/12/2021 20:47, Stephen Fuld wrote:
>>> On 12/30/2021 11:11 AM, David Brown wrote:
>>
>>>> I suspect that good native (i.e., part of the core language rather than
>>>> libraries or classes) multi-dimensional array support is not as much
>>>> needed as it would appear.  It is not hard to think of features that
>>>> seem obviously essential in a language, and yet are missing in many
>>>> languages.
>>>
>>> Probably itself a good topic for discussion, though perhaps off topic
>>> for comp.arch.  But I am willing if others are.  So can you provide some
>>> examples?
>>>
>>
>> One example that comes to mind is that neither C nor C++ has a "power"
>> operator.  But usually you think of things that you use regularly in one
>> language, but are missing when you move to another language.  Good
>> string support, sized integer types, strong enumerators, classes,
>> multi-threading and atomics - there are all kinds of things that are
>> heavily used in some languages yet missing entirely in others.
>
> Thank you.  Some of these are missing in some languages due to the long
> language history and lots of existing code, and the difficulty of adding
> a useful feature without breaking compatibility.  I totally understand
> that.  I think most of these are included in most new languages (Is that
> enough weasel words????).
>
> I also do like, what apparently others don't, is a spec that says
> essentially, this is an optional feature, but if you implement it, it
> should work like this.  (This goes back at least as far as COBOL.) This
> is a compromise between creeping "featureitis" and slow death by
> ossification.  It also gives some time to see if a feature is really
> needed and find any issues with it.
>

I think optional features can be fine in a language if there are good
reasons for making them optional. For example, it makes sense to have
features that require significant library code or run-time overhead be
optional when the target is a small microcontroller.

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. 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.

> What I don't like is saying a popular feature should be implemented by
> the individual programmer or team, as that leads to fracturing,
> increased learning and debugging time when you "switch teams", etc.
>

Yes, the more popular a feature is, the more standardised it should be.

>
>
>>>> A challenge with multi-dimensional array support beyond the simple and
>>>> limited version in C is that people want different things from it.
>>>
>>> Can you elaborate on this?  Are there features that some want that are
>>> hard to provide, or where different people want conflicting features?
>>>
>>
>> If you implement a two-dimensional array as an array of arrays, then
>> it's easy to get sub-arrays in one direction, but difficult in the other
>> direction.  If you want to support that efficiently, you need your
>> one-dimensional arrays to be characterised by stride size as well as
>> element count and element size/type.  That makes your one-dimensional
>> arrays less efficient.
>
> I am not sure I agree that is needed, but even if it is, I think the
> overhead is pretty minimal.
>

Basically, if you have a 10 by 20 array then accessing element (x, y)
means calculating index (10 * x + y). If you take a 1-D slice in one
dimension, accessing element (y) is index (y) from the start of the
slice, just like a normal 1-D array. But if you take a 1-D slice in the
other dimension, accessing element (x) is index (x * 10). Now you have
a 1-D array but the stride is no longer a single element. That means
you have to have support for arrays in which the element stride is
bigger than the size of the element - it is quite a significant overhead.

>
>> Sometimes you want sparse arrays, or arrays with flexible sizes in one
>> or more dimensions.  Maybe you want range checking on access.  That's
>> all possible, but comes at a cost (sometimes a significant cost)
>> compared to a simpler fixed-size array.
>
> I may be wrong, but I think most of these are provided in, for example,
> Julia.  And others should provide more definitive knowledge, but I think
> at least some of these are in the newer versions of Fortran.
>

I can't really comment, as my knowledge of these two languages is very
minimal.

>
>> Perhaps you want mixed array/scaler operations - such as making "A = x;"
>> initialise every element of array "A" with the value "x".  That does not
>> cause additional run-time costs for those that don't want the operation,
>> but it reduces the compile-time error checking and safety of the type
>> for those that would prefer it to be an error.
>
> Again, I think that is allowed in Julia (though perhaps with different
> syntax).
>
>

On Monday, January 3, 2022 at 3:10:24 AM UTC-6, David Brown wrote:
> On 02/01/2022 18:24, Stephen Fuld wrote:
> > On 12/31/2021 6:44 AM, David Brown wrote:
> >> On 30/12/2021 20:47, Stephen Fuld wrote:
> >>> On 12/30/2021 11:11 AM, David Brown wrote:
> >>
> >>>> I suspect that good native (i.e., part of the core language rather than
> >>>> libraries or classes) multi-dimensional array support is not as much
> >>>> needed as it would appear. It is not hard to think of features that
> >>>> seem obviously essential in a language, and yet are missing in many
> >>>> languages.
> >>>
> >>> Probably itself a good topic for discussion, though perhaps off topic
> >>> for comp.arch. But I am willing if others are. So can you provide some
> >>> examples?
> >>>
> >>
> >> One example that comes to mind is that neither C nor C++ has a "power"
> >> operator. But usually you think of things that you use regularly in one
> >> language, but are missing when you move to another language. Good
> >> string support, sized integer types, strong enumerators, classes,
> >> multi-threading and atomics - there are all kinds of things that are
> >> heavily used in some languages yet missing entirely in others.
> >
> > Thank you. Some of these are missing in some languages due to the long
> > language history and lots of existing code, and the difficulty of adding
> > a useful feature without breaking compatibility. I totally understand
> > that. I think most of these are included in most new languages (Is that
> > enough weasel words????).
> >
> > I also do like, what apparently others don't, is a spec that says
> > essentially, this is an optional feature, but if you implement it, it
> > should work like this. (This goes back at least as far as COBOL.) This
> > is a compromise between creeping "featureitis" and slow death by
> > ossification. It also gives some time to see if a feature is really
> > needed and find any issues with it.
> >
> I think optional features can be fine in a language if there are good
> reasons for making them optional. For example, it makes sense to have
> features that require significant library code or run-time overhead be
> optional when the target is a small microcontroller.
>
> 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. 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.
> > What I don't like is saying a popular feature should be implemented by
> > the individual programmer or team, as that leads to fracturing,
> > increased learning and debugging time when you "switch teams", etc.
> >
> Yes, the more popular a feature is, the more standardised it should be.
> >
> >
> >>>> A challenge with multi-dimensional array support beyond the simple and
> >>>> limited version in C is that people want different things from it.
> >>>
> >>> Can you elaborate on this? Are there features that some want that are
> >>> hard to provide, or where different people want conflicting features?
> >>>
> >>
> >> If you implement a two-dimensional array as an array of arrays, then
> >> it's easy to get sub-arrays in one direction, but difficult in the other
> >> direction. If you want to support that efficiently, you need your
> >> one-dimensional arrays to be characterised by stride size as well as
> >> element count and element size/type. That makes your one-dimensional
> >> arrays less efficient.
> >
> > I am not sure I agree that is needed, but even if it is, I think the
> > overhead is pretty minimal.
> >
> Basically, if you have a 10 by 20 array then accessing element (x, y)
> means calculating index (10 * x + y). If you take a 1-D slice in one
> dimension, accessing element (y) is index (y) from the start of the
> slice, just like a normal 1-D array. But if you take a 1-D slice in the
> other dimension, accessing element (x) is index (x * 10). Now you have
> a 1-D array but the stride is no longer a single element. That means
> you have to have support for arrays in which the element stride is
> bigger than the size of the element - it is quite a significant overhead.
<
This is what Dope Vectors are for. You can even make diagonal slices:
index(x × 11).
> >
> >> Sometimes you want sparse arrays, or arrays with flexible sizes in one
> >> or more dimensions. Maybe you want range checking on access. That's
> >> all possible, but comes at a cost (sometimes a significant cost)
> >> compared to a simpler fixed-size array.
> >
> > I may be wrong, but I think most of these are provided in, for example,
> > Julia. And others should provide more definitive knowledge, but I think
> > at least some of these are in the newer versions of Fortran.
> >
> I can't really comment, as my knowledge of these two languages is very
> minimal.
> >
> >> Perhaps you want mixed array/scaler operations - such as making "A = x;"
> >> initialise every element of array "A" with the value "x". That does not
> >> cause additional run-time costs for those that don't want the operation,
> >> but it reduces the compile-time error checking and safety of the type
> >> for those that would prefer it to be an error.
> >
> > Again, I think that is allowed in Julia (though perhaps with different
> > syntax).
> >
> >

David Brown <david.brown@hesbynett.no> schrieb:

> I think optional features can be fine in a language if there are good
> reasons for making them optional. For example, it makes sense to have
> features that require significant library code or run-time overhead be
> optional when the target is a small microcontroller.

The user can always not use features. A semi-intelligent
compiler and linker should be able to not include unneeded
features, especially on embedded systems with static linking.
(This excludes glibc with static linking, unfortunately).

> 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.

This would point towards some sort of template library with
overloading of operators - C++ light, more or less.

Or do you mean actual external libraries?

> 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.
>
>> What I don't like is saying a popular feature should be implemented by
>> the individual programmer or team, as that leads to fracturing,
>> increased learning and debugging time when you "switch teams", etc.
>>
>
> Yes, the more popular a feature is, the more standardised it should be.

It's either standardized or it is not. Standardized means a strong
association with the standard, like the C standard library,
otherwise people would be hitting https://xkcd.com/927/ .

>> I am not sure I agree that is needed, but even if it is, I think the
>> overhead is pretty minimal.
>>
>
> Basically, if you have a 10 by 20 array then accessing element (x, y)
> means calculating index (10 * x + y). If you take a 1-D slice in one
> dimension, accessing element (y) is index (y) from the start of the
> slice, just like a normal 1-D array. But if you take a 1-D slice in the
> other dimension, accessing element (x) is index (x * 10). Now you have
> a 1-D array but the stride is no longer a single element. That means
> you have to have support for arrays in which the element stride is
> bigger than the size of the element - it is quite a significant overhead.

If you need a two-dimensional array, you need it. You can either
roll your own using indexing or a pointer forest, or use something
in the language.

If it is in the language as a first-class citizen and not in a library,
then the compiler is in a much better position to optimize, especially
to optimize away the unneeded parts.

It is interesting to see that full support for multi-dimensional
arrays tends to increase register pressure quite a lot.

I found it instructive to compare a very simple-minded matmul
implementation in Fortran with full innate multi-dimensional
array support. https://godbolt.org/z/Kbxjnxb75 is the version for
x86_64, and https://godbolt.org/z/r8ETP4sjT , a version for POWER.

If you don't read POWER assembly: A load/store like -96(1) is
relative to the stack pointer. You will see these are only in
the function prologue and epiloge, unlike the x64_64 variant.

(Since my favorite language is Fortran, I am always a fan of
more registers, in principle :-)

On Monday, January 3, 2022 at 12:07:10 PM UTC-6, Thomas Koenig wrote:
<
For your enjoyment: I hand wrote My 66000 assembly for the my_matmul routine:
// with annotations of what the Dope Vector contains and how it is used.
<
<
ENTRY my_matmul
my_matmul:
ENTER R23,R29,#0
//
// R1 points at the Dope Vector for a
// R2 points at the Dope Vector for b
// R3 points at the Dope Vector for c
// R4..R15 are free to be used without saving
// R29..R23 were saved and restored.
// neither SP nor FP is touched.
// ----------------------------------
// 2 dimensional Dope Vector
// 0x000 pointer to 2D-matrix[1,1]
// 0x008 row index minimum (typically 1)
// 0x010 row index maximum
// 0x018 row index stride (typiclly 1 element)
// 0x020 col index minimum (typically 1)
// 0x028 col index maximum
// 0x030 col index stride (typiclly 1 element)
//
// Access Dope Vector for c and use it to zero c
LDD Rcp,[R3+0] // R4 = &c[1,1]
LDD Rrmin,[R3+8] // R5 = c[min,*]
LDD Rrmax,[R3+16] // R6 = c[max,*]
LDD Rrows,[R3+24] // R7 = c[stride,*]
LDD Rcmin,[R3+32] // R8 = c[*,min]
LDD Rcmax,[R3+40] // R9 = c[*,max]
LDD Rcols,[R3+48] // R10 = c[*,stride]
//
MOV Ri,Rrmin // R11
zero_c_outer:
MUL Rj,Rcmin,Rccols // R12
zero_c_inner:
//
ADD Rij,Ri,Rj // R13
// zero_c
STD #0,[Rcp+Rij<<3]
// inner loop continuance
ADD Rj,Rj,Rccols
CMP Rt,Rj,Rcmax // R14
BLT Rt,zero_c_inner
// outer loop continuance
ADD Ri,Ri,Rcrows
CMP Rt,Ri,Rrmax
BLT Rt,zero_c_outer
//
// Access Dope Vectors for a and b setting up for the calculation loop
//
// Column of b
LDD Rbp,[R2+0] // R5
LDD Rbcmin,[R2+32] // R6
LDD Rbcmax,[R2+40] // R7
LDD Rbcols,[R2+48] // R8
// both row and col of a (dropping row and col of c)
LDD Rap,[R1+0] // R9
LDD Rarmin,[R1+8] // R10
LDD Rarmax,[R1+16] // R11
LDD Rarows,[R1+24] // R12
LDD Racmin,[R1+32] // R13
LDD Racmax,[R1+40] // R14
LDD Racols,[R1+48] // R15
//
ADD Rbcmax,Rbcmax,-Rbcmin // size(b,2)
ADD Racmax,Racmax,-Racmin // size(a,2)
ADD Rarmax,Rarmax,-Rarmin // size(a,1)
//
MOV Rj,Rbcmin // R29
MUL Rt,Rj,Rbcols
ADD Rkj,Rj,Rt
Outer_loop_top:
MOV Rk,Rarmin // R28
Middle_loop_top:
MOV Ri,Rarmin // R27
//
MUL Rt,Rk,Racols
ADD Rik,Ri,Rt // R26
//
LDD Rb,[Rbp+Rkj<<3] // R25 constant over inner loop
//
Inner_loop_top:
// arithmetic
LDD Ra,[Rap+Rik<<3] // R24
LDD Rc,[Rcp+Rij<<3] // R23
FMAC Rc,Ra,Rb,Rc
STD Rc,[Rcp+Rij<<3]
// loop indexing
ADD Rik,Rik,Rarows
ADD Rij,Rij,Rbrows
// inner loop continuance
ADD Ri,Ri,#1
CMP Rt,Ri,Rarmax
BLE Rt,Inner_loop_top
// middle loop continuance
ADD Rk,Rk,#1
CMP Rt,Rk,Racmax
BLE Rt,Middle_loop_top
// outer loop continuance
ADD Rj,Rj,#1
CMP Rt,Rj,Rbcmax
BLE Rt,Outer_loop_top
//
EXIT R23,R29,#0

<
Enjoy........

On 1/3/2022 1:10 AM, David Brown wrote:
> On 02/01/2022 18:24, Stephen Fuld wrote:
>> On 12/31/2021 6:44 AM, David Brown wrote:
>>> On 30/12/2021 20:47, Stephen Fuld wrote:
>>>> On 12/30/2021 11:11 AM, David Brown wrote:
>>>
>>>>> I suspect that good native (i.e., part of the core language rather than
>>>>> libraries or classes) multi-dimensional array support is not as much
>>>>> needed as it would appear.  It is not hard to think of features that
>>>>> seem obviously essential in a language, and yet are missing in many
>>>>> languages.
>>>>
>>>> Probably itself a good topic for discussion, though perhaps off topic
>>>> for comp.arch.  But I am willing if others are.  So can you provide some
>>>> examples?
>>>>
>>>
>>> One example that comes to mind is that neither C nor C++ has a "power"
>>> operator.  But usually you think of things that you use regularly in one
>>> language, but are missing when you move to another language.  Good
>>> string support, sized integer types, strong enumerators, classes,
>>> multi-threading and atomics - there are all kinds of things that are
>>> heavily used in some languages yet missing entirely in others.
>>
>> Thank you.  Some of these are missing in some languages due to the long
>> language history and lots of existing code, and the difficulty of adding
>> a useful feature without breaking compatibility.  I totally understand
>> that.  I think most of these are included in most new languages (Is that
>> enough weasel words????).
>>
>> I also do like, what apparently others don't, is a spec that says
>> essentially, this is an optional feature, but if you implement it, it
>> should work like this.  (This goes back at least as far as COBOL.) This
>> is a compromise between creeping "featureitis" and slow death by
>> ossification.  It also gives some time to see if a feature is really
>> needed and find any issues with it.
>>
>
> I think optional features can be fine in a language if there are good
> reasons for making them optional. For example, it makes sense to have
> features that require significant library code or run-time overhead be
> optional when the target is a small microcontroller.

Sure.

> 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

Which seems, at least to me, to be much more "natural". And since you
want the compiler to be able to inline such code, the compiler has to be
aware of the library function, which, ISTM sort of defeats the purpose
of having it in the library in the first place.

Similar arguments would apply to say 128 bit floating point, or packed
decimal data types, etc.

> 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.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

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:
>>> On 12/31/2021 6:44 AM, David Brown wrote:
>>>> On 30/12/2021 20:47, Stephen Fuld wrote:
>>>>> On 12/30/2021 11:11 AM, David Brown wrote:
>>>>
>>>>>> I suspect that good native (i.e., part of the core language rather
>>>>>> than
>>>>>> libraries or classes) multi-dimensional array support is not as much
>>>>>> needed as it would appear.  It is not hard to think of features that
>>>>>> seem obviously essential in a language, and yet are missing in many
>>>>>> languages.
>>>>>
>>>>> Probably itself a good topic for discussion, though perhaps off topic
>>>>> for comp.arch.  But I am willing if others are.  So can you provide
>>>>> some
>>>>> examples?
>>>>>
>>>>
>>>> One example that comes to mind is that neither C nor C++ has a "power"
>>>> operator.  But usually you think of things that you use regularly in
>>>> one
>>>> language, but are missing when you move to another language.  Good
>>>> string support, sized integer types, strong enumerators, classes,
>>>> multi-threading and atomics - there are all kinds of things that are
>>>> heavily used in some languages yet missing entirely in others.
>>>
>>> Thank you.  Some of these are missing in some languages due to the long
>>> language history and lots of existing code, and the difficulty of adding
>>> a useful feature without breaking compatibility.  I totally understand
>>> that.  I think most of these are included in most new languages (Is that
>>> enough weasel words????).
>>>
>>> I also do like, what apparently others don't, is a spec that says
>>> essentially, this is an optional feature, but if you implement it, it
>>> should work like this.  (This goes back at least as far as COBOL.) This
>>> is a compromise between creeping "featureitis" and slow death by
>>> ossification.  It also gives some time to see if a feature is really
>>> needed and find any issues with it.
>>>
>>
>> I think optional features can be fine in a language if there are good
>> reasons for making them optional.  For example, it makes sense to have
>> features that require significant library code or run-time overhead be
>> optional when the target is a small microcontroller.
>
> Sure.
>
>
>> 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
>
> Which seems, at least to me, to be much more "natural".  And since you
> want the compiler to be able to inline such code, the compiler has to be
> aware of the library function, which, ISTM sort of defeats the purpose
> of having it in the library in the first place.

In C++ you could happily make a function that worked like that. (Okay,
you might not be happy about having to make it, as it would involve some
odd classes with overloaded assignment operators, but it is entirely
possible with C++ today, and compilers should be able to fully optimise
the results.)

>
> Similar arguments would apply to say 128 bit floating point, or packed
> decimal data types, etc.
>

Yes. Make them classes - user-defined types (though by "user-defined"
here, it would be reasonable to make them standard-library classes). A
good library version might have a general, portable implementation
combined with target and compiler-specific versions that are more
efficient for particular targets.

>
>> 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.)

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Monday, January 3, 2022 at 12:07:10 PM UTC-6, Thomas Koenig wrote:
><
> For your enjoyment: I hand wrote My 66000 assembly for the my_matmul routine:
> // with annotations of what the Dope Vector contains and how it is used.

Thanks, interesing (and a very clean implementation).

A couple of remarks:

I still do not have a script ready which translates GENERIC as
exposed by -fdump-tree-original by gfortran into compilable C.
If I have it, I will post the code, so we can see what the
My 66000 compiler makes of it.

Second,

> Inner_loop_top:
> // arithmetic
> LDD Ra,[Rap+Rik<<3] // R24
> LDD Rc,[Rcp+Rij<<3] // R23
> FMAC Rc,Ra,Rb,Rc
> STD Rc,[Rcp+Rij<<3]
> // loop indexing
> ADD Rik,Rik,Rarows
> ADD Rij,Rij,Rbrows
> // inner loop continuance
> ADD Ri,Ri,#1
> CMP Rt,Ri,Rarmax
> BLE Rt,Inner_loop_top

Is there a particular reason why you chose not to use
VVM here?

On Monday, January 3, 2022 at 4:47:41 PM UTC-6, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > On Monday, January 3, 2022 at 12:07:10 PM UTC-6, Thomas Koenig wrote:
> ><
> > For your enjoyment: I hand wrote My 66000 assembly for the my_matmul routine:
> > // with annotations of what the Dope Vector contains and how it is used.
> Thanks, interesing (and a very clean implementation).
>
> A couple of remarks:
>
> I still do not have a script ready which translates GENERIC as
> exposed by -fdump-tree-original by gfortran into compilable C.
> If I have it, I will post the code, so we can see what the
> My 66000 compiler makes of it.
>
> Second,
> > Inner_loop_top:
> > // arithmetic
> > LDD Ra,[Rap+Rik<<3] // R24
> > LDD Rc,[Rcp+Rij<<3] // R23
> > FMAC Rc,Ra,Rb,Rc
> > STD Rc,[Rcp+Rij<<3]
> > // loop indexing
> > ADD Rik,Rik,Rarows
> > ADD Rij,Rij,Rbrows
> > // inner loop continuance
> > ADD Ri,Ri,#1
> > CMP Rt,Ri,Rarmax
> > BLE Rt,Inner_loop_top
<
> Is there a particular reason why you chose not to use
> VVM here?
<
It is easier to compare with lesser ISAs without using VVM, and more particularly
it saves only 1 word in the size of the function.
<
The thing I found interesting was that here is a function that can be compiled to
a "one 32-entry RF contains everything" and only uses 6-preserved registers, and
needs no local stack space (other than the registers being preserved.)

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:
>>>> On 12/31/2021 6:44 AM, David Brown wrote:
>>>>> On 30/12/2021 20:47, Stephen Fuld wrote:
>>>>>> On 12/30/2021 11:11 AM, David Brown wrote:
>>>>>
>>>>>>> I suspect that good native (i.e., part of the core language rather
>>>>>>> than
>>>>>>> libraries or classes) multi-dimensional array support is not as much
>>>>>>> needed as it would appear.  It is not hard to think of features that
>>>>>>> seem obviously essential in a language, and yet are missing in many
>>>>>>> languages.
>>>>>>
>>>>>> Probably itself a good topic for discussion, though perhaps off topic
>>>>>> for comp.arch.  But I am willing if others are.  So can you provide
>>>>>> some
>>>>>> examples?
>>>>>>
>>>>>
>>>>> One example that comes to mind is that neither C nor C++ has a "power"
>>>>> operator.  But usually you think of things that you use regularly in
>>>>> one
>>>>> language, but are missing when you move to another language.  Good
>>>>> string support, sized integer types, strong enumerators, classes,
>>>>> multi-threading and atomics - there are all kinds of things that are
>>>>> heavily used in some languages yet missing entirely in others.
>>>>
>>>> Thank you.  Some of these are missing in some languages due to the long
>>>> language history and lots of existing code, and the difficulty of adding
>>>> a useful feature without breaking compatibility.  I totally understand
>>>> that.  I think most of these are included in most new languages (Is that
>>>> enough weasel words????).
>>>>
>>>> I also do like, what apparently others don't, is a spec that says
>>>> essentially, this is an optional feature, but if you implement it, it
>>>> should work like this.  (This goes back at least as far as COBOL.) This
>>>> is a compromise between creeping "featureitis" and slow death by
>>>> ossification.  It also gives some time to see if a feature is really
>>>> needed and find any issues with it.
>>>>
>>>
>>> I think optional features can be fine in a language if there are good
>>> reasons for making them optional.  For example, it makes sense to have
>>> features that require significant library code or run-time overhead be
>>> optional when the target is a small microcontroller.
>>
>> Sure.
>>
>>
>>> 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
>>
>> Which seems, at least to me, to be much more "natural".  And since you
>> want the compiler to be able to inline such code, the compiler has to be
>> aware of the library function, which, ISTM sort of defeats the purpose
>> of having it in the library in the first place.
>
> In C++ you could happily make a function that worked like that. (Okay,
> you might not be happy about having to make it, as it would involve some
> odd classes with overloaded assignment operators, but it is entirely
> possible with C++ today, and compilers should be able to fully optimise
> the results.)

But because it isn't standardized, different people will make different
syntax, which defeats the purpose of standardizing it. And could you
make a function that applied to the left hand side of the equal sign?

>> Similar arguments would apply to say 128 bit floating point, or packed
>> decimal data types, etc.
>>
>
> Yes. Make them classes - user-defined types (though by "user-defined"
> here, it would be reasonable to make them standard-library classes). A
> good library version might have a general, portable implementation
> combined with target and compiler-specific versions that are more
> efficient for particular targets.

Agreed

>>> 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?

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

> 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
>
> Which seems, at least to me, to be much more "natural".

The other way to look at it is that the language should be flexible
enough that a library should be able to define new "lvalues" (or
new assignment syntaxes).

> And since you want the compiler to be able to inline such code, the
> compiler has to be aware of the library function, which, ISTM sort of
> defeats the purpose of having it in the library in the first place.

As you say, all it takes is "inlining" here, which can be done by the
compiler without the compiler having to be aware of the library (beside
having access to it, that is).

Stefan

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:
> > On 02/01/2022 18:24, Stephen Fuld wrote:
> >> On 12/31/2021 6:44 AM, David Brown wrote:
> >>> On 30/12/2021 20:47, Stephen Fuld wrote:
> >>>> On 12/30/2021 11:11 AM, David Brown wrote:
> >>>
> >>>>> I suspect that good native (i.e., part of the core language rather than
> >>>>> libraries or classes) multi-dimensional array support is not as much
> >>>>> needed as it would appear. It is not hard to think of features that
> >>>>> seem obviously essential in a language, and yet are missing in many
> >>>>> languages.
> >>>>
> >>>> Probably itself a good topic for discussion, though perhaps off topic
> >>>> for comp.arch. But I am willing if others are. So can you provide some
> >>>> examples?
> >>>>
> >>>
> >>> One example that comes to mind is that neither C nor C++ has a "power"
> >>> operator. But usually you think of things that you use regularly in one
> >>> language, but are missing when you move to another language. Good
> >>> string support, sized integer types, strong enumerators, classes,
> >>> multi-threading and atomics - there are all kinds of things that are
> >>> heavily used in some languages yet missing entirely in others.
> >>
> >> Thank you. Some of these are missing in some languages due to the long
> >> language history and lots of existing code, and the difficulty of adding
> >> a useful feature without breaking compatibility. I totally understand
> >> that. I think most of these are included in most new languages (Is that
> >> enough weasel words????).
> >>
> >> I also do like, what apparently others don't, is a spec that says
> >> essentially, this is an optional feature, but if you implement it, it
> >> should work like this. (This goes back at least as far as COBOL.) This
> >> is a compromise between creeping "featureitis" and slow death by
> >> ossification. It also gives some time to see if a feature is really
> >> needed and find any issues with it.
> >>
> >
> > I think optional features can be fine in a language if there are good
> > reasons for making them optional. For example, it makes sense to have
> > features that require significant library code or run-time overhead be
> > optional when the target is a small microcontroller.
> Sure.
> > 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 ?
>
> Which seems, at least to me, to be much more "natural". And since you
> want the compiler to be able to inline such code, the compiler has to be
> aware of the library function, which, ISTM sort of defeats the purpose
> of having it in the library in the first place.
>
> Similar arguments would apply to say 128 bit floating point, or packed
> decimal data types, etc.
> > 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.
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

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.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

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.
<
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 ?
<
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

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. :-(

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Monday, January 3, 2022 at 4:47:41 PM UTC-6, Thomas Koenig wrote:
>> MitchAlsup <Mitch...@aol.com> schrieb:
>> > On Monday, January 3, 2022 at 12:07:10 PM UTC-6, Thomas Koenig wrote:
>> ><
>> > For your enjoyment: I hand wrote My 66000 assembly for the my_matmul routine:
>> > // with annotations of what the Dope Vector contains and how it is used.
>> Thanks, interesing (and a very clean implementation).
>>
>> A couple of remarks:
>>
>> I still do not have a script ready which translates GENERIC as
>> exposed by -fdump-tree-original by gfortran into compilable C.
>> If I have it, I will post the code, so we can see what the
>> My 66000 compiler makes of it.
>>
>> Second,
>> > Inner_loop_top:
>> > // arithmetic
>> > LDD Ra,[Rap+Rik<<3] // R24
>> > LDD Rc,[Rcp+Rij<<3] // R23
>> > FMAC Rc,Ra,Rb,Rc
>> > STD Rc,[Rcp+Rij<<3]
>> > // loop indexing
>> > ADD Rik,Rik,Rarows
>> > ADD Rij,Rij,Rbrows
>> > // inner loop continuance
>> > ADD Ri,Ri,#1
>> > CMP Rt,Ri,Rarmax
>> > BLE Rt,Inner_loop_top
><
>> Is there a particular reason why you chose not to use
>> VVM here?
><
> It is easier to compare with lesser ISAs without using VVM, and more particularly
> it saves only 1 word in the size of the function.

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?

(Regarding the code, you will see that array descriptors are being
filled out regardless if one needs them or not. The expectation
is that all of these will be removed by an optimizing copiler).

><
> The thing I found interesting was that here is a function that can be compiled to
> a "one 32-entry RF contains everything" and only uses 6-preserved registers, and
> needs no local stack space (other than the registers being preserved.)

What you compiled was functionally equivalent (I trust you on that,
I didn't debug your code), but I am not sure that the dope vectors
you used are in fact the same ones, or that the logic is the same.

On 04/01/2022 00:44, Stephen Fuld wrote:
> On 1/3/2022 2:32 PM, David Brown wrote:
>> On 03/01/2022 23:12, Stephen Fuld wrote:

>>> 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
>>>
>>> Which seems, at least to me, to be much more "natural".  And since you
>>> want the compiler to be able to inline such code, the compiler has to be
>>> aware of the library function, which, ISTM sort of defeats the purpose
>>> of having it in the library in the first place.
>>
>> In C++ you could happily make a function that worked like that.  (Okay,
>> you might not be happy about having to make it, as it would involve some
>> odd classes with overloaded assignment operators, but it is entirely
>> possible with C++ today, and compilers should be able to fully optimise
>> the results.)
>
> But because it isn't standardized, different people will make different
> syntax, which defeats the purpose of standardizing it. 

If such a function were made, and put in the standard library, then by
definition it would be standardised. If not, then it is not standard.

If this is a feature that a lot of people might want to use, and where a
standard interface would be of significant aid to interoperability, code
sharing, etc., then it would be best to put it in the standard library.
If it is something that would be expected to be rarely used, then
adding it to the standard library would make that library bigger for no
good value to most of its users. It is impractical and unhelpful to add
support for /everything/ that some people think would be useful.

Either way, IMHO it is better that a language supports the ability to
write such functions within the language, than adding them to the core
language itself. The result is much more flexible, with implementations
easier to develop and maintain, and users less dependent on the language
standards and tools vendors since they can make such functions
themselves if need be.

> And could you
> make a function that applied to the left hand side of the equal sign?
>

Yes, that was my point. (I haven't actually made one, merely thought
out how it could be done.)

>
>>> Similar arguments would apply to say 128 bit floating point, or packed
>>> decimal data types, etc.
>>>
>>
>> Yes.  Make them classes - user-defined types (though by "user-defined"
>> here, it would be reasonable to make them standard-library classes).  A
>> good library version might have a general, portable implementation
>> combined with target and compiler-specific versions that are more
>> efficient for particular targets.
>
> Agreed
>
>
>>>> 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?

Yes, inlining requires that the compiler knows the definition of the
function at compilation time. The current trend in C++ is header-only
libraries, where the header contains everything about the templates,
classes, functions and data - several changes in the core language have
been designed to support that style more easily. (C++20 introduced
modules, though it will take a while for tool vendors, library writers
and users to get up to speed on them - these will effectively give the
compiler and code the same benefit as source headers while being more
efficient and reducing long compile times.)

> 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?
>

Having functions in a library can make things a little easier for the
programmer - if "Bits" was a standard library function then they could
use that directly and know that the implementation was written in a way
that the compiler would recognize and optimise, as the details of which
patterns are optimised varies from compiler to compiler.

David Brown <david.brown@hesbynett.no> schrieb:
> (C++20 introduced
> modules, though it will take a while for tool vendors, library writers
> and users to get up to speed on them - these will effectively give the
> compiler and code the same benefit as source headers while being more
> efficient and reducing long compile times.)

Ever since I heard a talk on C++ modules given by a senior gcc
developer (working for Facebook) and C++ comittee member, I fear
that these are not very well thought out. Caveat: I did not read
the standard to see if there were any deviations.

#defines outside of the inclusion of the module are supposed to
affect the module itself. Urgh.

Modules and namespaces are orthogonal. Urgh.

The main problem appears to be how to find the file to compile for
a given module. The solution was to introduce an oracle which
the compiler then queries via http to see which is which. When I
asked at the talk how the oracle was supposed to know that, the
answer was basically "not my department". Urgh.

Maybe they sanitized the proposal since the talk, maybe not.
It is at https://www.youtube.com/watch?v=4yOZ8Zp_Zfk .

On 04/01/2022 09:52, David Brown wrote:
> On 04/01/2022 00:44, Stephen Fuld wrote:
>> On 1/3/2022 2:32 PM, David Brown wrote:
>>> On 03/01/2022 23:12, Stephen Fuld wrote:
>
>>>> 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
>>>>

>> And could you
>> make a function that applied to the left hand side of the equal sign?
>>
>
> Yes, that was my point. (I haven't actually made one, merely thought
> out how it could be done.)
>
<https://godbolt.org/z/43hvTn3jh>

I think it would make sense to pick one style - either "Bits(x, 4, 3) =
0b010;" or "Bits<4, 3>(x) = 0b010;", but I've included both here. My
x86 assembly is not good enough to tell if the generated code is optimal
in the general case, but the example tests show that the values are correct.

A more complete implementation would do static error checking on ranges
when they are known at compile-time, and perhaps optional run-time
checks according to preference. The "Bits_imp" class would be local to
the "Bits" function if there was only one such function, and could be
locked down more by disabling other operations that should not be used.
There's scope for more enhancements here such as other bit-slice
operations (|=, &=, extraction).

#include <stdint.h>
#include <concepts>
#include <bit>
#include <type_traits>

template<std::unsigned_integral T, std::integral U>
T insertbits(T x, int start, int len, U y)
{ constexpr T all_ones = (T) -1;
constexpr int bit_width = std::bit_width(all_ones);
const T len_ones = all_ones >> (bit_width - len);
const T mask = len_ones << start;

return (x & ~mask) | ((T) y << start);
}

template<int start, int len, std::unsigned_integral T, std::integral U>
T insertbits(T x, U y)
{ return insertbits(x, start, len, y);
}

bool test1() {
uint32_t x = 0x01234567;
uint32_t y = insertbits(x, 8, 4, 0b1101); // 0b1101 = 0xd
return y == 0x01234d67;
}

bool test2() {
uint64_t x = 0x0123456789abcdef;
uint64_t y = insertbits(x, 24, 12, 0x123);
return y == 0x0123456123abcdef;
}

bool test3() {
uint64_t x = 0x0123456789abcdef;
uint64_t y = insertbits<24, 12>(x, 0x123);
return y == 0x0123456123abcdef;
}

uint64_t test4(uint64_t x, uint64_t y) {
return insertbits<16, 8>(x, y);
}

uint64_t test5(uint64_t x, int start, int len, uint64_t y) {
return insertbits(x, start, len, y);
}

template <std::unsigned_integral T>
class Bits_imp {
T& x_;
int start_;
int len_;
public:
Bits_imp(T& x, int start, int len) : x_(x), start_(start), len_(len) {}
T operator=(T y) {
x_ = insertbits(x_, start_, len_, y);
return x_;
}
};

template <std::unsigned_integral T>
auto Bits(T& x, int start, int len) {
return Bits_imp(x, start, len);
}

template <int start, int len, std::unsigned_integral T>
auto Bits(T& x) {
return Bits_imp(x, start, len);
}

bool btest1() {
uint32_t x = 0x01234567;
Bits(x, 8, 4) = 0b1101; // 0b1101 = 0xd
return x == 0x01234d67;
}

bool btest2() {
uint64_t x = 0x0123456789abcdef;
Bits(x, 24, 12) = 0x123;
return x == 0x0123456123abcdef;
}

bool btest3() {
uint64_t x = 0x0123456789abcdef;
Bits<24, 12>(x) = 0x123;
return x == 0x0123456123abcdef;
}

uint64_t btest4(uint64_t x, uint64_t y) {
return Bits<16, 8>(x) = y;
}

uint64_t btest5(uint64_t x, int start, int len, uint64_t y) {
Bits(x, start, len) = y;
return x;
}

On 04/01/2022 10:47, Thomas Koenig wrote:
> David Brown <david.brown@hesbynett.no> schrieb:
>> (C++20 introduced
>> modules, though it will take a while for tool vendors, library writers
>> and users to get up to speed on them - these will effectively give the
>> compiler and code the same benefit as source headers while being more
>> efficient and reducing long compile times.)
>
> Ever since I heard a talk on C++ modules given by a senior gcc
> developer (working for Facebook) and C++ comittee member, I fear
> that these are not very well thought out. Caveat: I did not read
> the standard to see if there were any deviations.
>

Certainly adding modules to a language like C++ is no easy task. It is
a lot simpler to put in more rigidly structured modules (units, or
whatever you want to call them) at the start of designing a language
than to add them later in place of unrestricted and unstructured textual
inclusion.

> #defines outside of the inclusion of the module are supposed to
> affect the module itself. Urgh.
>

I think that is no longer the case. (I am waiting until implementations
are stabilised and in common use before I start learning the details - I
think in the long run, modules will be good for C++ but they are not
something I need in my own work at the moment.)

> Modules and namespaces are orthogonal. Urgh.

That decision has its pros and cons, as does the distinction of module
names and filenames. In C and C++ today, you often see files paired up
as a "file.c" (or "file.cpp") implementation and "file.h" interface
header - it's a convention that works well for a lot of things. But it
is not ideal for all cases. Similarly, I expect you'll see a lot of
cases where "file.cpp" has a module and a namespace of the same name,
but there will be situations where it is best to split things up
differently. Remember, having these concepts orthogonal in the language
does not mean they have to be kept orthogonal by code that uses them.

>
> The main problem appears to be how to find the file to compile for
> a given module. The solution was to introduce an oracle which
> the compiler then queries via http to see which is which. When I
> asked at the talk how the oracle was supposed to know that, the
> answer was basically "not my department". Urgh.
>

I'm not keen on the "oracle" solution either. But I'm optimistic that
there will be a reasonable working system in the end.

> Maybe they sanitized the proposal since the talk, maybe not.
> It is at https://www.youtube.com/watch?v=4yOZ8Zp_Zfk .
>

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.
One first compiles the header producing a compiled summary file
and possibly an OBJ too. The summary file is what is read
when you 'import' a package, similar to C/C++ compiled headers.

When one compiles the body it updates the compiled header summary
including possibly attaching the Intermediate Representation in an
IR language called DIANA I believe for any inlinable routines.
Routines can be inlinable because they are declared as such,
or because the IR turned out to be smaller than some limit.

The code management system tracks the module dependencies.
A source that imports a package is dependent on the package header source.
A compilation can be for no-optimize debug and so would not make
use of inlining. However if it was compiled optimize and it
subsequently inlines that IR then it becomes dependent
on the source code body that created the IR.

On 1/4/2022 5:44 AM, David Brown wrote:
> On 04/01/2022 09:52, David Brown wrote:
>> On 04/01/2022 00:44, Stephen Fuld wrote:
>>> On 1/3/2022 2:32 PM, David Brown wrote:
>>>> On 03/01/2022 23:12, Stephen Fuld wrote:
>>
>>>>> 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
>>>>>
>
>>> And could you
>>> make a function that applied to the left hand side of the equal sign?
>>>
>>
>> Yes, that was my point. (I haven't actually made one, merely thought
>> out how it could be done.)
>>
> <https://godbolt.org/z/43hvTn3jh>
>
>
> I think it would make sense to pick one style - either "Bits(x, 4, 3) =
> 0b010;" or "Bits<4, 3>(x) = 0b010;", but I've included both here.

I think Mitch was proposing x<4,3> = 0b010. This has the advantage of
concision, and if you squint, it sort of looks like a kind of subscript
if the variable is treated as an array of bits. As I replied, I have no
problem with this, but others might.

My
> x86 assembly is not good enough to tell if the generated code is optimal
> in the general case, but the example tests show that the values are correct.

Good. I am glad to know it is possible. But my point about
standardization still stands.

> A more complete implementation would do static error checking on ranges
> when they are known at compile-time, and perhaps optional run-time
> checks according to preference.

Absolutely. This is done in Fortran.

snipped code

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

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?

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

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.

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.

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 am not saying this is the definitive answer - just more thoughts.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)