using an FPGA to emulate a vintage computer
in [FPGA]
|
From: Ahem A Rivet's Shot on 7 Mar 2010 16:40 On Sun, 7 Mar 2010 18:59:43 +0000 (UTC) johnf(a)panix.com (John Francis) wrote: > In article <20100307143020.fcc7e3df.steveo(a)eircom.net>, > Ahem A Rivet's Shot <steveo(a)eircom.net> wrote: > >On Sun, 07 Mar 2010 07:48:01 -0500 > >Greg Menke <gusenet(a)comcast.net> wrote: > > > >> > >> Ahem A Rivet's Shot <steveo(a)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. -- Steve O'Hara-Smith | Directable Mirror Arrays C:>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. | http://www.sohara.org/
From: John Francis on 8 Mar 2010 02:45 In article <20100307214004.5b5fc8b4.steveo(a)eircom.net>, Ahem A Rivet's Shot <steveo(a)eircom.net> wrote: >On Sun, 7 Mar 2010 18:59:43 +0000 (UTC) >johnf(a)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.
From: Ahem A Rivet's Shot on 8 Mar 2010 02:39 On Sun, 07 Mar 2010 20:11:53 -0600 Charles Richmond <frizzle(a)tx.rr.com> wrote: > Ahem A Rivet's Shot wrote: > > On Sat, 6 Mar 2010 01:58:43 -0800 (PST) > > Quadibloc <jsavard(a)ecn.ab.ca> wrote: > > > >> On Mar 5, 10:16 am, Ahem A Rivet's Shot <ste...(a)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. Yep *good* support for adding integers to pointers. -- Steve O'Hara-Smith | Directable Mirror Arrays C:>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. | http://www.sohara.org/
From: Ahem A Rivet's Shot on 8 Mar 2010 04:43 On Mon, 8 Mar 2010 07:45:53 +0000 (UTC) johnf(a)panix.com (John Francis) wrote: > In article <20100307214004.5b5fc8b4.steveo(a)eircom.net>, > Ahem A Rivet's Shot <steveo(a)eircom.net> wrote: > >On Sun, 7 Mar 2010 18:59:43 +0000 (UTC) > >johnf(a)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). -- Steve O'Hara-Smith | Directable Mirror Arrays C:>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. | http://www.sohara.org/
From: John Francis on 8 Mar 2010 12:48
In article <20100308094342.f7fa8e54.steveo(a)eircom.net>, Ahem A Rivet's Shot <steveo(a)eircom.net> wrote: >On Mon, 8 Mar 2010 07:45:53 +0000 (UTC) >johnf(a)panix.com (John Francis) wrote: > >> In article <20100307214004.5b5fc8b4.steveo(a)eircom.net>, >> Ahem A Rivet's Shot <steveo(a)eircom.net> wrote: >> >On Sun, 7 Mar 2010 18:59:43 +0000 (UTC) >> >johnf(a)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). True iff a is defined as int**. Note that sizeof(a[n]) returns different values for the two declarations; for the two-dimensional array the elements of a are not of type (int *); they are of an anonymous datatype (a vector of 5 ints). |