using an FPGA to emulate a vintage computer

In article <20100307143020.fcc7e3df.steveo_at_eircom.net>,
Ahem A Rivet's Shot <steveo_at_eircom.net> wrote:
On Sun, 07 Mar 2010 07:48:01 -0500
Greg Menke <gusenet_at_comcast.net> wrote:


Ahem A Rivet's Shot <steveo_at_eircom.net> writes:
The C subscript operator does do nothing other than adding
two numbers and dereferencing the result, that last action is rather
important. The validity of constructs like 2[a] and *(2+a) make this
clear - as does the equivalence of a and &(a[0]) or of *a and a[0]
where a is a pointer.

Yet when dereferencing arrays of rank >= 2, dimensions are
automatically incorporated into the effective address, so its not
quite equivalent to a simple addition of pointer and offset.

There is a way to regard it as such - consider a[x][y] as being
equivalent to *(a[x] + y) where we regard a[x] as devolving into a
pointer to a row of the array. But yes multidimensional array support is
a little more involved than single dimensional array support. It's still
not a proper type though.

That's all very well, but in fact no C implementation of which I am
aware uses dope vectors when allocating multidimensional arrays. (I

have come across the practice in other languages). In fact C has to
perform different calculations to evaluate the address of an element
a[i][j], depending on how a was defined (int a[4][5], or int** a).
The sizeof operator also knows something about array types.

On Sun, 7 Mar 2010 09:54:04 -0800 (PST)



Quadibloc <jsav...@ecn.ab.ca> wrote:
On Mar 7, 7:39 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:

        Well I think you'll find a never die mean as what you would
expect it to mean. In many contexts including this one (and a[2] and 2
[a] and a + 2 or even (a+2)[3]) it is a pointer not an array - the only
context in which it is an array is the declaration.

Yes: the array name always refers to the pointer, and the subscript is
required to reference, not just to displace. That was my mistake; a
never did mean the "array" in the abstract sense... so that a "new,
improved" C copying Fortran 90 (or PL/I) could have statements like

int a[5],b[5] ;
...
b = a + 2 ;

and the compiler just makes

int a[5],b[5]
...
for (i00001 = 0; i++; i<5 )
 { b[i00001] = a[i00001] + 2
 } ;

        Yes that would be nice, especially if it extended to full blown matrix
artihmetic.

On Sun, 7 Mar 2010 09:54:04 -0800 (PST)
Quadibloc <jsavard_at_ecn.ab.ca> wrote:

On Mar 7, 7:39 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:

Well I think you'll find a never die mean as what you would
expect it to mean. In many contexts including this one (and a[2] and 2
[a] and a + 2 or even (a+2)[3]) it is a pointer not an array - the only
context in which it is an array is the declaration.
Yes: the array name always refers to the pointer, and the subscript is
required to reference, not just to displace. That was my mistake; a
never did mean the "array" in the abstract sense... so that a "new,
improved" C copying Fortran 90 (or PL/I) could have statements like

int a[5],b[5] ;
...
b = a + 2 ;

and the compiler just makes

int a[5],b[5]
...
for (i00001 = 0; i++; i<5 )
{ b[i00001] = a[i00001] + 2
} ;

Yes that would be nice, especially if it extended to full blown matrix
artihmetic.

In article <20100307143020.fcc7e3df.steveo_at_eircom.net>,
Ahem A Rivet's Shot <steveo_at_eircom.net> wrote:
On Sun, 07 Mar 2010 07:48:01 -0500
Greg Menke <gusenet_at_comcast.net> wrote:


Ahem A Rivet's Shot <steveo_at_eircom.net> writes:
The C subscript operator does do nothing other than adding two
numbers and dereferencing the result, that last action is rather
important. The validity of constructs like 2[a] and *(2+a) make this
clear - as does the equivalence of a and &(a[0]) or of *a and a[0]
where a is a pointer.

Yet when dereferencing arrays of rank >= 2, dimensions are automatically
incorporated into the effective address, so its not quite equivalent to
a simple addition of pointer and offset.

There is a way to regard it as such - consider a[x][y] as being
equivalent to *(a[x] + y) where we regard a[x] as devolving into a pointer
to a row of the array. But yes multidimensional array support is a little
more involved than single dimensional array support. It's still not a
proper type though.

That's all very well, but in fact no C implementation of which I am
aware uses dope vectors when allocating multidimensional arrays. (I
have come across the practice in other languages). In fact C has to
perform different calculations to evaluate the address of an element
a[i][j], depending on how a was defined (int a[4][5], or int** a).
The sizeof operator also knows something about array types.

Quadibloc schrieb:
On Mar 5, 12:44 pm, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:
#include <stdio.h
int main()
{
int a[4];

printf("a[2] at 0x%8x\n", &(a[2]));
printf("2[a] at 0x%8x\n", &(2[a]));
printf("(a+2) is 0x%8x\n", a+2);
printf("(2+a) is 0x%8x\n", 2+a);

}

[pfeiffer_at_snowball ~/temp]# ./awry
a[2] at 0xbfff97b8
2[a] at 0xbfff97b8
(a+2) is 0xbfff97b8
(2+a) is 0xbfff97b8
The 2[a] syntax actually *works* in C the way it was described? I am
astonished. I would expect it to yield the contents of the memory
location a+&2 assuming that &2 can be persuaded to yield up the
location where the value of the constant "2" is stored.

You can think of the "a" in "a[4]" as a named numerical (integer)
constant (alias), giving the address of the memory block that was
allocated by the definition.

So there is no difference, between using that (named) constant or an
explicit numerical constant.

The only differences between:
(1) int a[4];
and:
(2) int * a = malloc( 4 * sizeof(int));
is the place where the memory is allocated and the value in (2) may be
changed later. (And the amount of typing, ofcourse!)

In both cases you can use "a[1]" or "*(a+1)" for access.

On Sat, 6 Mar 2010 01:58:43 -0800 (PST)
Quadibloc <jsavard_at_ecn.ab.ca> wrote:

On Mar 5, 10:16 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:

No but x = *(y + 3) will store in x the contents of the memory
location at 3 + the value of y just as x = y[3] will and x = 3[y] will,
which is what I stated. You missed out the all important * and ()s.
Intentionally. My point was that, while there is _some_ truth to the
claim that C arrays tread rather lightly on the ground of hardware
addressing, the claim that C doesn't have arrays at all, and the C
array subscript operator does nothing at all but add two addresses
together... is not *quite* true.

The C subscript operator does do nothing other than adding two
numbers and dereferencing the result, that last action is rather important.
The validity of constructs like 2[a] and *(2+a) make this clear - as does
the equivalence of a and &(a[0]) or of *a and a[0] where a is a pointer.

C does have good support for pointers and adding integers to
pointers and for declaring blocks of storage with an array like syntax.

... but do *not* forget that when an integer is added to a pointer,
that integer is "scaled" by the length associated with that
pointer. So if "a" is a pointer to a four byte integer, then "a+1"
actually adds *four* to the pointer. The integer "1" is scaled by the
length of the object pointed to by "a".

Ahem A Rivet's Shot wrote:
On Sat, 6 Mar 2010 01:58:43 -0800 (PST)
Quadibloc <jsavard_at_ecn.ab.ca> wrote:

On Mar 5, 10:16 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:

No but x = *(y + 3) will store in x the contents of the memory
location at 3 + the value of y just as x = y[3] will and x = 3[y]
will, which is what I stated. You missed out the all important * and
()s.
Intentionally. My point was that, while there is _some_ truth to the
claim that C arrays tread rather lightly on the ground of hardware
addressing, the claim that C doesn't have arrays at all, and the C
array subscript operator does nothing at all but add two addresses
together... is not *quite* true.

The C subscript operator does do nothing other than adding two
numbers and dereferencing the result, that last action is rather
important. The validity of constructs like 2[a] and *(2+a) make this
clear - as does the equivalence of a and &(a[0]) or of *a and a[0]
where a is a pointer.

C does have good support for pointers and adding integers to
pointers and for declaring blocks of storage with an array like syntax.


... but do *not* forget that when an integer is added to a
pointer, that integer is "scaled" by the length associated with
that pointer.

On Sun, 7 Mar 2010 18:59:43 +0000 (UTC)
johnf_at_panix.com (John Francis) wrote:

have come across the practice in other languages). In fact C has to
perform different calculations to evaluate the address of an element
a[i][j], depending on how a was defined (int a[4][5], or int** a).
The sizeof operator also knows something about array types.

If a is defined as int **a then a[i][j] is not valid at all.

In article <20100307214004.5b5fc8b4.steveo_at_eircom.net>,
Ahem A Rivet's Shot <steveo_at_eircom.net> wrote:
On Sun, 7 Mar 2010 18:59:43 +0000 (UTC)
johnf_at_panix.com (John Francis) wrote:

have come across the practice in other languages). In fact C has to
perform different calculations to evaluate the address of an element
a[i][j], depending on how a was defined (int a[4][5], or int** a).
The sizeof operator also knows something about array types.

If a is defined as int **a then a[i][j] is not valid at all.

Rubbish. a[i][j] is a perfectly legal term in both cases I supplied,
and has a well-defined way of calculating the address.

On Mon, 8 Mar 2010 07:45:53 +0000 (UTC)
johnf_at_panix.com (John Francis) wrote:

In article <20100307214004.5b5fc8b4.steveo_at_eircom.net>,
Ahem A Rivet's Shot <steveo_at_eircom.net> wrote:
On Sun, 7 Mar 2010 18:59:43 +0000 (UTC)
johnf_at_panix.com (John Francis) wrote:

have come across the practice in other languages). In fact C has to
perform different calculations to evaluate the address of an element
a[i][j], depending on how a was defined (int a[4][5], or int** a).
The sizeof operator also knows something about array types.

If a is defined as int **a then a[i][j] is not valid at all.

Rubbish. a[i][j] is a perfectly legal term in both cases I supplied,
and has a well-defined way of calculating the address.

Er OK - you're right int **a is a pointer to a pointer to integers
so the first offset works in terms of sizeof(int *) and the second in terms
of sizeof(int).

Charles Richmond <frizzle_at_tx.rr.com> writes:
... but do *not* forget that when an integer is added to a pointer,
that integer is "scaled" by the length associated with that
pointer. So if "a" is a pointer to a four byte integer, then "a+1"
actually adds *four* to the pointer. The integer "1" is scaled by the
length of the object pointed to by "a".

That fact took me several painful days to learn. I had (in a project I
don't remember, for reasons I don't remember) used the + syntax
dereferencing a buffer of integers, and had scaled it myself. Which
meant, of course, that everything seemed fine for a ways into the
buffer, then mysteriously segfaulted.

Hmmm... I've got quite a few like that, with vividly remembered bugs in
totally forgotten projects.

On Sun, 7 Mar 2010 18:59:43 +0000 (UTC)
johnf_at_panix.com (John Francis) wrote:

In article <20100307143020.fcc7e3df.steveo_at_eircom.net>,
Ahem A Rivet's Shot <steveo_at_eircom.net> wrote:
On Sun, 07 Mar 2010 07:48:01 -0500
Greg Menke <gusenet_at_comcast.net> wrote:

Ahem A Rivet's Shot <steveo_at_eircom.net> writes:
The C subscript operator does do nothing other than adding
two numbers and dereferencing the result, that last action is rather
important. The validity of constructs like 2[a] and *(2+a) make this
clear - as does the equivalence of a and &(a[0]) or of *a and a[0]
where a is a pointer.
Yet when dereferencing arrays of rank >= 2, dimensions are
automatically incorporated into the effective address, so its not
quite equivalent to a simple addition of pointer and offset.
There is a way to regard it as such - consider a[x][y] as being
equivalent to *(a[x] + y) where we regard a[x] as devolving into a
pointer to a row of the array. But yes multidimensional array support is
a little more involved than single dimensional array support. It's still
not a proper type though.
That's all very well, but in fact no C implementation of which I am
aware uses dope vectors when allocating multidimensional arrays. (I

Indeed they don't - it is simply a matter of how you interpret the
partial construct a[x] when a is declared as a two dimensional array - one
way of interpreting it is as a pointer to an array row even though it is
not a valid construct on it's own.

There is a clear extension of the one dimentsional case a declaration
int a[5] leaves future references to a as being equivalent to &(a[0]) so
it is reasonable to regard a declaration int a[4][5] as leaving future
references like a[i] as equivalent to &(a[i][0]).

have come across the practice in other languages). In fact C has to
perform different calculations to evaluate the address of an element
a[i][j], depending on how a was defined (int a[4][5], or int** a).
The sizeof operator also knows something about array types.

If a is defined as int **a then a[i][j] is not valid at all.

Yes, "2[c]" does work in C as well as "c[2]", and yields the same
results. The definition of "c[x]" is "*(c+x)", where the array "c"
becomes a pointer to the first element, and the integer value "x" is
scaled by the length associated with the pointer "c". "*(c+x)" will
give the same result as "*(x+c)", so it's logical.

Charles Richmond <frizzle_at_tx.rr.com> writes:

Yes, "2[c]" does work in C as well as "c[2]", and yields the same
results. The definition of "c[x]" is "*(c+x)", where the array "c"
becomes a pointer to the first element, and the integer value "x" is
scaled by the length associated with the pointer "c". "*(c+x)" will
give the same result as "*(x+c)", so it's logical.

Just curious, but why is it that "2[c]" doesn't seem to work as an
argument to printf? This simple example gives an error at compile, for
example:

#include <stdio.h

int main()
{
char c[] = "12345678";
printf("%c\n", [2]c);
}

gcc says:

array_fun_mini_example.c: In function 'main':
array_fun_mini_example.c:6: error: expected expression before '[' token

I'm using gcc 4.3.2. Assignment like 2[c] = '1' and reading a value
like tmp = 2[c] seem to work fine, though.