After more than 8 years, my patent for a new computer architecture, defined using an instruction set has been approved by UKIPO. I only file it in UKIPO and MYIPO but abandoned in MYIPO.

It is the simplest possible because no opcode decoding using logic gates required. Just straight wires through. Also, it is typeless, so should be able to use operators for multi dimensional data types.

the limitation is the number of operands. Only 3 opeands in the A = B + C type.

Only this instruction is supported and the secret for RISC performance. It is able to use 3-ported memories. More than 3 should be messy but can lead to more performance. someone has to look deeper into this.

Simplest word-size scalable processor, GB1420325.1
https://www.ipo.gov.uk/p-ipsum/Case/ApplicationNumber/GB1420325.1

On Thursday, December 16, 2021 at 4:05:20 PM UTC-6, Ir. Hj. Othman bin Hj. Ahmad wrote:
> After more than 8 years, my patent for a new computer architecture, defined using an instruction set has been approved by UKIPO. I only file it in UKIPO and MYIPO but abandoned in MYIPO.
>
> It is the simplest possible because no opcode decoding using logic gates required. Just straight wires through. Also, it is typeless, so should be able to use operators for multi dimensional data types.
>
> the limitation is the number of operands. Only 3 opeands in the A = B + C type.
>
> Only this instruction is supported and the secret for RISC performance. It is able to use 3-ported memories. More than 3 should be messy but can lead to more performance. someone has to look deeper into this.
>
> Simplest word-size scalable processor, GB1420325.1
> https://www.ipo.gov.uk/p-ipsum/Case/ApplicationNumber/GB1420325.1
<
The front ½ of the patent talks about scalability
a) how do you intend to scale this to 64-bits
b) how do you intend to scale this into multiprocessing
c) how do you intend to scale this into floating point
d) how do you intend to scale this into vector processing
??
<
BTW: congratulations on the patent.

On 2021-12-16, Ir. Hj. Othman bin Hj. Ahmad wrote:
> After more than 8 years, my patent for a new computer architecture, defined using an instruction set has been approved by UKIPO. I only file it in UKIPO and MYIPO but abandoned in MYIPO.

Congratulations!

>
> It is the simplest possible because no opcode decoding using logic gates required. Just straight wires through. Also, it is typeless, so should be able to use operators for multi dimensional data types.
>
> the limitation is the number of operands. Only 3 opeands in the A = B + C type.
>
> Only this instruction is supported and the secret for RISC performance. It is able to use 3-ported memories. More than 3 should be messy but can lead to more performance. someone has to look deeper into this.
>
> Simplest word-size scalable processor, GB1420325.1
> https://www.ipo.gov.uk/p-ipsum/Case/ApplicationNumber/GB1420325.1
>

Interesting! Do you have any more references, like a simulator or
a hardware implementation, running programs, etc?

/Marcus

On Saturday, 18 December 2021 at 03:05:04 UTC+8, Marcus wrote:
> On 2021-12-16, Ir. Hj. Othman bin Hj. Ahmad wrote:
> > After more than 8 years, my patent for a new computer architecture, defined using an instruction set has been approved by UKIPO. I only file it in UKIPO and MYIPO but abandoned in MYIPO.
> Congratulations!
> >
> > It is the simplest possible because no opcode decoding using logic gates required. Just straight wires through. Also, it is typeless, so should be able to use operators for multi dimensional data types.
> >
> > the limitation is the number of operands. Only 3 opeands in the A = B + C type.
> >
> > Only this instruction is supported and the secret for RISC performance. It is able to use 3-ported memories. More than 3 should be messy but can lead to more performance. someone has to look deeper into this.
> >
> > Simplest word-size scalable processor, GB1420325.1
> > https://www.ipo.gov.uk/p-ipsum/Case/ApplicationNumber/GB1420325.1
> >
> Interesting! Do you have any more references, like a simulator or
> a hardware implementation, running programs, etc?
>
> /Marcus
I have checked your work and it is very impressive. You should try to design your own instruction set for commercial use as well.
I only managed to write an assembler based on my simplest assembler.
It was simulated on a third party CPU simulator but not completely.

I stopped this work a few years ago, but would like to continue it later on..
I am currently busy with designing and probably manufacturing my Transparent SUV, if my funding is successful.

I major in Electronic Engineering, especially Microelectronic Design, not Mechanical but all engineers should be more flexible.
My Transparent SUV is more electrical than mechanical with no steering at all. Mechanical Engineers scoff at it but experience can be misleading. We should go back to first principles.

I have another patent: Imperfect Perpetual MOtion Heat Engine, originally called Perpetual MOtion Heat Engine, also granted, after I threate n legal action through the standard UKIPO process. Unlike USPTO PTAB, actual judges are involved in the court proceedings.

USPTO PTAB has rejected my Zero Aerodynamic Vehicles patent based on clarity (interpretation of claims) despite pointing out that patents cannot be rejected based on clarity, because the examiner cannot determine the novelty because he has grossly misterpreted the invention. And worst, clarity issues can be amended at will, as explained by USPTO guidelines published in MPEP.

UKIPO granted my patent and will be used for the Transparent SUV because it is vital that we reduce any energy loss in a solar powered car.

Another patent, Optimum Collision DAmage REduction System, still under process, but it is too late already, so I need to pay huge penalties to continue with it.

When I started patenting about 10 years ago, I suspected something like this should happen but actually the cost is small if we do it ourselves. Engineers should not avoid learning about legal proceedings. I attended lectures from the Law department of City University of London, which was formerly call Inns College, where Mahatma Gandhi graduated. No wonder they were really impressive, although I ended up not answering any law question. Too hard to remember judges, date, courts, apart from the case details. We were not alowed to refer to them during exam.

The cheapest and most professional is UKIPO. My total cost for each patent was 200 pound. 200 pound for court proceeding. AFter they were granted we need to pay yearly fees, which amount to 400 pound for 9 years. Still these are cheaper than even the Microentity patents in USPTO.

I encougrage anyone who has a patentable idea to patent them instead of pubishing them in conference papers. Patents also get reviews from even professionals unlike academic papers, that are reviewed by amateurs and self interested professors. I say amateurs because many reviewers also review papers that are not their major fields. REally frustrating arguing with them. Worst, you cannot challenge them in court.

So what has got to do with comp.arch? Everything. computers are useful for the self-driving technologies. Even Tesla now builds its own computers. However, it relied on ARM architecture.

I designed my SWORD precisely for signal processing based on my Intelligence Theory. I published it in a ISITA/IEEE conference, because it is based on Information Theory. NOt philosophy that is more mumbo jumbo than anything an engineer can use. We cannot patent a scientific principle, so we need to design a CPU to demonstrate it.

Any computer architect should try to understand my Intelligence Theory, but to get over it, you need to master Information Theory first.
In a nutshell, intelligence is just trial and error. But information theory also states that information is just data that cannot be compressed. It is not something useful or anything at all. Scientific theories are just to examine experimental data, not find absolute truth. That is why engineers can use them to design real objects.

I published my work on the simplest assembler and simulator somewhere in groups. Maybe in my blogs also.

On Friday, 17 December 2021 at 07:30:37 UTC+8, MitchAlsup wrote:
> On Thursday, December 16, 2021 at 4:05:20 PM UTC-6, Ir. Hj. Othman bin Hj.. Ahmad wrote:
> > After more than 8 years, my patent for a new computer architecture, defined using an instruction set has been approved by UKIPO. I only file it in UKIPO and MYIPO but abandoned in MYIPO.
> >
> > It is the simplest possible because no opcode decoding using logic gates required. Just straight wires through. Also, it is typeless, so should be able to use operators for multi dimensional data types.
> >
> > the limitation is the number of operands. Only 3 opeands in the A = B + C type.
> >
> > Only this instruction is supported and the secret for RISC performance. It is able to use 3-ported memories. More than 3 should be messy but can lead to more performance. someone has to look deeper into this.
> >
> > Simplest word-size scalable processor, GB1420325.1
> > https://www.ipo.gov.uk/p-ipsum/Case/ApplicationNumber/GB1420325.1
> <
> The front ½ of the patent talks about scalability
> a) how do you intend to scale this to 64-bits
Just extend the least significant bits and tell this information to your assembler or ALU.
> b) how do you intend to scale this into multiprocessing
It is supposed to be only word-size scalable only, but because the data type is not defined, you can use data that utilise multiprocessing, just as operators for arrays.

> c) how do you intend to scale this into floating point
floating point is just a data type, just define an instruction for this data type

> d) how do you intend to scale this into vector processing

vectors are arrays. define arrays and operators to for these arrays
> ??
> <
> BTW: congratulations on the patent.
Thank you but it is just the beginning and I am getting old. 63 already.

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.

YMMV,
George

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.

Thomas Koenig wrote:
> 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.

This, 100%

We have discussed the issue many times here, and the "proper" answer is
of course to have array descriptors, with base, dimensions,[dim x
(count,stride)].

What I don't understand is why this isn't an std default feature in C++.

Terje

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

On 12/28/21 5:22 AM, Terje Mathisen wrote:
> Thomas Koenig wrote:
>> 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.
>
> This, 100%
>
> We have discussed the issue many times here, and the "proper" answer is
> of course to have array descriptors, with base, dimensions,[dim x
> (count,stride)].
>
> What I don't understand is why this isn't an std default feature in C++.

Because they want to keep the language small :-)

On Tuesday, December 28, 2021 at 6:35:25 PM UTC-6, Bakul Shah wrote:
> On 12/28/21 5:22 AM, Terje Mathisen wrote:
> > Thomas Koenig wrote:
> >> George Neuner <gneu...@comcast.net> schrieb:
> >>> On Sat, 25 Dec 2021 16:53:06 -0800 (PST), Othman Ahmad
> >>> <oth...@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.
> >
> > This, 100%
> >
> > We have discussed the issue many times here, and the "proper" answer is
> > of course to have array descriptors, with base, dimensions,[dim x
> > (count,stride)].
> >
> > What I don't understand is why this isn't an std default feature in C++.
> Because they want to keep the language small :-)
<
Lol, LoL, LOL, lOl,.......

On 28/12/2021 14:22, Terje Mathisen wrote:
> Thomas Koenig wrote:
>> 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.
>
> This, 100%
>
> We have discussed the issue many times here, and the "proper" answer is
> of course to have array descriptors, with base, dimensions,[dim x
> (count,stride)].
>
> What I don't understand is why this isn't an std default feature in C++.
>
> Terje
>
>

C++ at least has std::array, which gives you a fixed (at compile-time)
sized array that acts like a "normal" type - you can pass it by value,
the type knows its size and number of elements, etc. But it is only one
dimensional. You can of course have arrays of arrays, with the ugliness
that entails (but at least it is highly efficient, and with optional
index range checking on access).

My guess is that the C++ standards committee simply haven't been able to
agree on a single interface for multi-dimensional arrays. There are
various ways to do this, with many subjective opinions - so far, people
have often written their own classes for the multi-dimensional arrays
they need. (Such classes are not hard to write - it's just a wrapper to
hide the pointer forest or array of arrays.)

Ideally, a multi-dimensional array A should be indexed by "A[x, y, z]".
That's the way it works in many languages that support them well.
Unfortunately, C (and therefore C++) have the "comma operator", so that
expression already has a meaning - evaluate "x" for its side-effects
then throw it away, evaluate "y" for its side-effects, then you are left
with "A[z]". This is not helpful. So in C++20, use of the comma
operator in subscripts was deprecated as a first step to changing the
language, and in C++23 you will be able to overload the subscript
operator with multiple arguments - finally it will be possible to make a
class with "A[x, y, z]" style of access. Whether a multi-dimensional
array class will make it into the standard library at that point remains
to be seen.

Backwards compatibility in an evolving language is vital, but it is also
a pain that can slow things down a lot.

On 12/29/21 12:39 AM, David Brown wrote:
> Ideally, a multi-dimensional array A should be indexed by "A[x, y, z]".
> That's the way it works in many languages that support them well.
> Unfortunately, C (and therefore C++) have the "comma operator", so that
> expression already has a meaning - evaluate "x" for its side-effects
> then throw it away, evaluate "y" for its side-effects, then you are left
> with "A[z]".

This could've been trivially fixed by using ';' instead of
','. Since ';' is illegal in the [] context, this would
have not been a breaking change.

Second, you also want to be able to reference subarrays
(rows, columns, smaller subarrays), as well as pass the
same by reference to functions. I don't think C++ generics
can handle this (at least not provide a nice syntax).

Note that many array programming languages also use ';'
between indices for each dimension as they typically
use ',' as a concatenation operator.

On 29/12/2021 10:02, Bakul Shah wrote:
> On 12/29/21 12:39 AM, David Brown wrote:
>> Ideally, a multi-dimensional array A should be indexed by "A[x, y, z]".
>>   That's the way it works in many languages that support them well.
>> Unfortunately, C (and therefore C++) have the "comma operator", so that
>> expression already has a meaning - evaluate "x" for its side-effects
>> then throw it away, evaluate "y" for its side-effects, then you are left
>> with "A[z]".
>
> This could've been trivially fixed by using ';' instead of
> ','. Since ';' is illegal in the [] context, this would
> have not been a breaking change.
>

I think that would have been /far/ from trivial. Suddenly you now have
two different ways of separating parameters in the language, which would
lead to confusion and inconsistencies. The aim is that [] as an
overloaded operator can take more than one parameter - that is the
simplest, cleanest way to get a nice multi-dimensional array syntax into
the language. You are suggesting that for this one type of function,
the operator[](...) method, parameters should be separated by semicolons
instead of commas. Should that apply to the declaration and definition,
or should this be the one type of function where declaration and use
differ? Should semicolons become the standard for parameter separation?
An optional choice? No, it would not be trivial.

The comma operator is not often used in C or C++. It turns up a bit
more in C in specific contexts, such as in "for" statements (less so in
C++, I suspect), though many coding standards ban it outright. My
estimate of the number of programs that use it inside a subscript
operator is very close to zero - deprecating it there is a hypothetical
breaking change rather than a practical breaking change. (Hypothetical
breaking changes are not trivial either.)

> Second, you also want to be able to reference subarrays
> (rows, columns, smaller subarrays), as well as pass the
> same by reference to functions. I don't think C++ generics
> can handle this (at least not provide a nice syntax).
>

Of course you can do this. But do you really /want/ to do that? It all
comes down to what you intend to do with your multi-dimensional array,
and what you are willing to pay for. If you have a two-dimensional
array, then maybe it is cheap to refer to the columns as one-dimensional
arrays - but it would cost to refer to the rows like this. It is the
many options here that makes it difficult to have a single standard
class for multi-dimensional arrays.

> Note that many array programming languages also use ';'
> between indices for each dimension as they typically
> use ',' as a concatenation operator.

C++ is not an array programming language. Different languages have
different symbols for different purposes - in C++, the semicolon is the
statement terminator.

On 12/29/2021 1:36 AM, David Brown wrote:
> On 29/12/2021 10:02, Bakul Shah wrote:
>> On 12/29/21 12:39 AM, David Brown wrote:
>>> Ideally, a multi-dimensional array A should be indexed by "A[x, y, z]".
>>>   That's the way it works in many languages that support them well.
>>> Unfortunately, C (and therefore C++) have the "comma operator", so that
>>> expression already has a meaning - evaluate "x" for its side-effects
>>> then throw it away, evaluate "y" for its side-effects, then you are left
>>> with "A[z]".
>>
>> This could've been trivially fixed by using ';' instead of
>> ','. Since ';' is illegal in the [] context, this would
>> have not been a breaking change.
>>
>
> I think that would have been /far/ from trivial. Suddenly you now have
> two different ways of separating parameters in the language, which would
> lead to confusion and inconsistencies. The aim is that [] as an
> overloaded operator can take more than one parameter - that is the
> simplest, cleanest way to get a nice multi-dimensional array syntax into
> the language. You are suggesting that for this one type of function,
> the operator[](...) method, parameters should be separated by semicolons
> instead of commas. Should that apply to the declaration and definition,
> or should this be the one type of function where declaration and use
> differ? Should semicolons become the standard for parameter separation?
> An optional choice? No, it would not be trivial.
>
> The comma operator is not often used in C or C++. It turns up a bit
> more in C in specific contexts, such as in "for" statements (less so in
> C++, I suspect), though many coding standards ban it outright. My
> estimate of the number of programs that use it inside a subscript
> operator is very close to zero - deprecating it there is a hypothetical
> breaking change rather than a practical breaking change. (Hypothetical
> breaking changes are not trivial either.)

Mill conAsm (which is actually C++) uses the comma operator as an
instruction separator in bundles (semi is the bundle separator). Not an
array notation, of course.

Huh? C does not support multi-dimensional arrays? I did not realize that. Not realizing
that, it is supported in my cc64 language. I do not see why [ ][ ][ ] cannot be used in
place of commas.
In cc64 multi-dimensional arrays are supported with the indexing operator[].
Accessing a multi-dimensional array is just A[x][y][z] which is the same as A[x,y,z].

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
> Thomas Koenig wrote:
>> 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.
>
> This, 100%
>
> We have discussed the issue many times here, and the "proper" answer is
> of course to have array descriptors, with base, dimensions,[dim x
> (count,stride)].

There is a standardized way for C to do this: Use a C compiler which
also includes a Fortran compiler and use ISO_Fortran_binding.h .
Should also work for C++.

It has one drawback, though: Because access to members is defined
in terms of macros, the memory layout differs between different
Fortran compilers. This design fault was realized too late.

> What I don't understand is why this isn't an std default feature in C++.

IIRC, Soustrup once quipped about the limited use case of
multi-dimensional arrays.

The reason behind that is probably that many computer scientists
at the time defined themselves by opposing all things FORTRAN, and
multi-dimensional arrays was one of the things that it excelled at,
therefore no respectable computer scientist would have something to
do with it.

Or something like that.

On Wed, 29 Dec 2021 02:46:51 -0800 (PST), "robf...@gmail.com"
<robfi680@gmail.com> wrote:

>Huh? C does not support multi-dimensional arrays? I did not realize that. Not realizing
>that, it is supported in my cc64 language. I do not see why [ ][ ][ ] cannot be used in
>place of commas.
>In cc64 multi-dimensional arrays are supported with the indexing operator[].
>Accessing a multi-dimensional array is just A[x][y][z] which is the same as A[x,y,z].

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.

And those warnings are possible only in scope of the array definition.
If you pass your '2D' array to a separately compiled function defined
to take an int* or int[] argument, then all bets are off: that
function will see a ONE dimensional array with no size limit.

In a language with true arrays, references that violate the defined
structure of the array would be errors: the dimensions and limits
follow the array as it is passed around.

If you /really/ need to violate structure, typically you would be
permitted to define an aliasing array: one that is overlaid on the
same memory block but having a different internal structure. However,
the structure of the aliasing array still would be constrained to
remaining within the original array's limits.

C does none of this.

George

On 29/12/2021 11:46, robf...@gmail.com wrote:
> Huh? C does not support multi-dimensional arrays? I did not realize that. Not realizing
> that, it is supported in my cc64 language. I do not see why [ ][ ][ ] cannot be used in
> place of commas.
> In cc64 multi-dimensional arrays are supported with the indexing operator[].
> Accessing a multi-dimensional array is just A[x][y][z] which is the same as A[x,y,z].
>

Yes, C (and therefore C++) support A[x][y][z] for arrays of arrays of
arrays. But that is not /quite/ the same as a multi-dimensional array.
And C arrays have slightly unusual semantics - array expressions decay
into pointer expressions in most circumstances. Often, you can write
simple and clear code with multi-dimensional arrays. But for some
use-cases, you need quite complicated expressions and a lot of care to
get the sizes write.

David Brown wrote:
> On 29/12/2021 11:46, robf...@gmail.com wrote:
>> Huh? C does not support multi-dimensional arrays? I did not realize that. Not realizing
>> that, it is supported in my cc64 language. I do not see why [ ][ ][ ] cannot be used in
>> place of commas.
>> In cc64 multi-dimensional arrays are supported with the indexing operator[].
>> Accessing a multi-dimensional array is just A[x][y][z] which is the same as A[x,y,z].
>>
>
> Yes, C (and therefore C++) support A[x][y][z] for arrays of arrays of
> arrays. But that is not /quite/ the same as a multi-dimensional array.
> And C arrays have slightly unusual semantics - array expressions decay
> into pointer expressions in most circumstances. Often, you can write
> simple and clear code with multi-dimensional arrays. But for some
> use-cases, you need quite complicated expressions and a lot of care to
> get the sizes write.
>
Multi-dim arrays using Iliffe vectors used to be a good idea, back when
memory was more or less the same speed as CPU, and multiplications were
much more expensive.

Today, it is normally far better to do w = arr[z*ZSTRIDE+y*YSTRIDE+x]
than to effectively do

t1 = arr[z]
t2 = t1[y]
w = t2[x]

where t1[] is an array of pointers to pointers to arrays, and t2[] is
an array of pointers to arrays.

Lifting stuff out of the inner loops can often alleviate the costs of
both of these, but integer mul is far to be preferred to random memory
access.

Terje

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

On Wednesday, December 29, 2021 at 3:31:16 PM UTC-6, Terje Mathisen wrote:
> David Brown wrote:
> > On 29/12/2021 11:46, robf...@gmail.com wrote:
> >> Huh? C does not support multi-dimensional arrays? I did not realize that. Not realizing
> >> that, it is supported in my cc64 language. I do not see why [ ][ ][ ] cannot be used in
> >> place of commas.
> >> In cc64 multi-dimensional arrays are supported with the indexing operator[].
> >> Accessing a multi-dimensional array is just A[x][y][z] which is the same as A[x,y,z].
> >>
> >
> > Yes, C (and therefore C++) support A[x][y][z] for arrays of arrays of
> > arrays. But that is not /quite/ the same as a multi-dimensional array.
> > And C arrays have slightly unusual semantics - array expressions decay
> > into pointer expressions in most circumstances. Often, you can write
> > simple and clear code with multi-dimensional arrays. But for some
> > use-cases, you need quite complicated expressions and a lot of care to
> > get the sizes write.
> >
> Multi-dim arrays using Iliffe vectors used to be a good idea, back when
> memory was more or less the same speed as CPU, and multiplications were
> much more expensive.
>
> Today, it is normally far better to do w = arr[z*ZSTRIDE+y*YSTRIDE+x]
> than to effectively do
>
> t1 = arr[z]
> t2 = t1[y]
> w = t2[x]
>
> where t1[] is an array of pointers to pointers to arrays, and t2[] is
> an array of pointers to arrays.
>
> Lifting stuff out of the inner loops can often alleviate the costs of
> both of these, but integer mul is far to be preferred to random memory
> access.
<
Then strength-reduction converts MULs within a loop back into ADDs.
<
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Wednesday, December 29, 2021 at 3:31:16 PM UTC-6, Terje Mathisen wrote:
>> David Brown wrote:
>> > On 29/12/2021 11:46, robf...@gmail.com wrote:
>> >> Huh? C does not support multi-dimensional arrays? I did not realize that. Not realizing
>> >> that, it is supported in my cc64 language. I do not see why [ ][ ][ ] cannot be used in
>> >> place of commas.
>> >> In cc64 multi-dimensional arrays are supported with the indexing operator[].
>> >> Accessing a multi-dimensional array is just A[x][y][z] which is the same as A[x,y,z].
>> >>
>> >
>> > Yes, C (and therefore C++) support A[x][y][z] for arrays of arrays of
>> > arrays. But that is not /quite/ the same as a multi-dimensional array.
>> > And C arrays have slightly unusual semantics - array expressions decay
>> > into pointer expressions in most circumstances. Often, you can write
>> > simple and clear code with multi-dimensional arrays. But for some
>> > use-cases, you need quite complicated expressions and a lot of care to
>> > get the sizes write.
>> >
>> Multi-dim arrays using Iliffe vectors used to be a good idea, back when
>> memory was more or less the same speed as CPU, and multiplications were
>> much more expensive.
>>
>> Today, it is normally far better to do w = arr[z*ZSTRIDE+y*YSTRIDE+x]
>> than to effectively do
>>
>> t1 = arr[z]
>> t2 = t1[y]
>> w = t2[x]
>>
>> where t1[] is an array of pointers to pointers to arrays, and t2[] is
>> an array of pointers to arrays.
>>
>> Lifting stuff out of the inner loops can often alleviate the costs of
>> both of these, but integer mul is far to be preferred to random memory
>> access.
><
> Then strength-reduction converts MULs within a loop back into ADDs.

.... which was a feature of the very first FORTRAN compiler, already.

On Wednesday, December 29, 2021 at 4:03:06 PM UTC-6, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > On Wednesday, December 29, 2021 at 3:31:16 PM UTC-6, Terje Mathisen wrote:
> >> David Brown wrote:
> >> > On 29/12/2021 11:46, robf...@gmail.com wrote:
> >> >> Huh? C does not support multi-dimensional arrays? I did not realize that. Not realizing
> >> >> that, it is supported in my cc64 language. I do not see why [ ][ ][ ] cannot be used in
> >> >> place of commas.
> >> >> In cc64 multi-dimensional arrays are supported with the indexing operator[].
> >> >> Accessing a multi-dimensional array is just A[x][y][z] which is the same as A[x,y,z].
> >> >>
> >> >
> >> > Yes, C (and therefore C++) support A[x][y][z] for arrays of arrays of
> >> > arrays. But that is not /quite/ the same as a multi-dimensional array.
> >> > And C arrays have slightly unusual semantics - array expressions decay
> >> > into pointer expressions in most circumstances. Often, you can write
> >> > simple and clear code with multi-dimensional arrays. But for some
> >> > use-cases, you need quite complicated expressions and a lot of care to
> >> > get the sizes write.
> >> >
> >> Multi-dim arrays using Iliffe vectors used to be a good idea, back when
> >> memory was more or less the same speed as CPU, and multiplications were
> >> much more expensive.
> >>
> >> Today, it is normally far better to do w = arr[z*ZSTRIDE+y*YSTRIDE+x]
> >> than to effectively do
> >>
> >> t1 = arr[z]
> >> t2 = t1[y]
> >> w = t2[x]
> >>
> >> where t1[] is an array of pointers to pointers to arrays, and t2[] is
> >> an array of pointers to arrays.
> >>
> >> Lifting stuff out of the inner loops can often alleviate the costs of
> >> both of these, but integer mul is far to be preferred to random memory
> >> access.
> ><
> > Then strength-reduction converts MULs within a loop back into ADDs.
> ... which was a feature of the very first FORTRAN compiler, already.
<
Something like 1955 ?

On Wednesday, December 29, 2021 at 4:03:06 PM UTC-6, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > On Wednesday, December 29, 2021 at 3:31:16 PM UTC-6, Terje Mathisen wrote:
> >> David Brown wrote:
> >> > On 29/12/2021 11:46, robf...@gmail.com wrote:
> >> >> Huh? C does not support multi-dimensional arrays? I did not realize that. Not realizing
> >> >> that, it is supported in my cc64 language. I do not see why [ ][ ][ ] cannot be used in
> >> >> place of commas.
> >> >> In cc64 multi-dimensional arrays are supported with the indexing operator[].
> >> >> Accessing a multi-dimensional array is just A[x][y][z] which is the same as A[x,y,z].
> >> >>
> >> >
> >> > Yes, C (and therefore C++) support A[x][y][z] for arrays of arrays of
> >> > arrays. But that is not /quite/ the same as a multi-dimensional array.
> >> > And C arrays have slightly unusual semantics - array expressions decay
> >> > into pointer expressions in most circumstances. Often, you can write
> >> > simple and clear code with multi-dimensional arrays. But for some
> >> > use-cases, you need quite complicated expressions and a lot of care to
> >> > get the sizes write.
> >> >
> >> Multi-dim arrays using Iliffe vectors used to be a good idea, back when
> >> memory was more or less the same speed as CPU, and multiplications were
> >> much more expensive.
> >>
> >> Today, it is normally far better to do w = arr[z*ZSTRIDE+y*YSTRIDE+x]
> >> than to effectively do
> >>
> >> t1 = arr[z]
> >> t2 = t1[y]
> >> w = t2[x]
> >>
> >> where t1[] is an array of pointers to pointers to arrays, and t2[] is
> >> an array of pointers to arrays.
> >>
> >> Lifting stuff out of the inner loops can often alleviate the costs of
> >> both of these, but integer mul is far to be preferred to random memory
> >> access.
> ><
> > Then strength-reduction converts MULs within a loop back into ADDs.
> ... which was a feature of the very first FORTRAN compiler, already.

Relied on 1970s FORTRAN compiler for subscript optimization.
Much clearer to write a lengthy subscript expressions than optimize it yourself via pointer obfuscation.

On Wednesday, December 29, 2021 at 6:23:33 PM UTC-6, JimBrakefield wrote:
> On Wednesday, December 29, 2021 at 4:03:06 PM UTC-6, Thomas Koenig wrote:
> > MitchAlsup <Mitch...@aol.com> schrieb:
> > > On Wednesday, December 29, 2021 at 3:31:16 PM UTC-6, Terje Mathisen wrote:
> > >> David Brown wrote:
> > >> > On 29/12/2021 11:46, robf...@gmail.com wrote:
> > >> >> Huh? C does not support multi-dimensional arrays? I did not realize that. Not realizing
> > >> >> that, it is supported in my cc64 language. I do not see why [ ][ ][ ] cannot be used in
> > >> >> place of commas.
> > >> >> In cc64 multi-dimensional arrays are supported with the indexing operator[].
> > >> >> Accessing a multi-dimensional array is just A[x][y][z] which is the same as A[x,y,z].
> > >> >>
> > >> >
> > >> > Yes, C (and therefore C++) support A[x][y][z] for arrays of arrays of
> > >> > arrays. But that is not /quite/ the same as a multi-dimensional array.
> > >> > And C arrays have slightly unusual semantics - array expressions decay
> > >> > into pointer expressions in most circumstances. Often, you can write
> > >> > simple and clear code with multi-dimensional arrays. But for some
> > >> > use-cases, you need quite complicated expressions and a lot of care to
> > >> > get the sizes write.
> > >> >
> > >> Multi-dim arrays using Iliffe vectors used to be a good idea, back when
> > >> memory was more or less the same speed as CPU, and multiplications were
> > >> much more expensive.
> > >>
> > >> Today, it is normally far better to do w = arr[z*ZSTRIDE+y*YSTRIDE+x]
> > >> than to effectively do
> > >>
> > >> t1 = arr[z]
> > >> t2 = t1[y]
> > >> w = t2[x]
> > >>
> > >> where t1[] is an array of pointers to pointers to arrays, and t2[] is
> > >> an array of pointers to arrays.
> > >>
> > >> Lifting stuff out of the inner loops can often alleviate the costs of
> > >> both of these, but integer mul is far to be preferred to random memory
> > >> access.
> > ><
> > > Then strength-reduction converts MULs within a loop back into ADDs.
> > ... which was a feature of the very first FORTRAN compiler, already.
<
> Relied on 1970s FORTRAN compiler for subscript optimization.
> Much clearer to write a lengthy subscript expressions than optimize it yourself via pointer obfuscation.
<
I typically write code in C using arrays rather than pointers.
Pointers are good for some things; array notation is better for others.

On 12/29/21 1:36 AM, David Brown wrote:
> On 29/12/2021 10:02, Bakul Shah wrote:
>> On 12/29/21 12:39 AM, David Brown wrote:
>>> Ideally, a multi-dimensional array A should be indexed by "A[x, y, z]".
>>>   That's the way it works in many languages that support them well.
>>> Unfortunately, C (and therefore C++) have the "comma operator", so that
>>> expression already has a meaning - evaluate "x" for its side-effects
>>> then throw it away, evaluate "y" for its side-effects, then you are left
>>> with "A[z]".
>>
>> This could've been trivially fixed by using ';' instead of
>> ','. Since ';' is illegal in the [] context, this would
>> have not been a breaking change.
>>
>
> I think that would have been /far/ from trivial. Suddenly you now have
> two different ways of separating parameters in the language, which would

Array indices are not the same as function parameters.
Given that C screwed up by misusing , as an operator,
and given that C has no generics, there is no other
choice but to use a different symbol *if* one wanted
to add multi dim. arrays to C. The syntax part is indeed
trivially solved but to make multi dim arrays fully
useful you need the ability to create arrays, reference
subarrays and pass them as args. etc and that is not
trivial. I believe it is indeed possible to add
full fledged multi-dim. array support to C in a fully
backward compatible way. Though am not holding my breath.
(and I have close to 0 interest in what C++ does. I used
it for 20+ years. That was a long enough sentence!]