using an FPGA to emulate a vintage computer
in [FPGA]
|
From: Quadibloc on 7 Mar 2010 12:54 On Mar 7, 7:39 am, Ahem A Rivet's Shot <ste...(a)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 } ; out of it. John Savard
From: Ahem A Rivet's Shot on 7 Mar 2010 13:09 On Sun, 7 Mar 2010 09:54:04 -0800 (PST) Quadibloc <jsavard(a)ecn.ab.ca> wrote: > On Mar 7, 7:39 am, Ahem A Rivet's Shot <ste...(a)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. -- 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 7 Mar 2010 13:59 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 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.
From: glen herrmannsfeldt on 7 Mar 2010 15:13 In comp.arch.fpga John Francis <johnf(a)panix.com> wrote: (snip) > 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. VMS compilers are supposed to allow for value, reference, or descriptor argument passing to support interlanguage calls. The %val(), %ref(), and %descr() syntax is supposed to be supported by all compilers. -- glen
From: Quadibloc on 7 Mar 2010 16:16
On Mar 7, 11:09 am, Ahem A Rivet's Shot <ste...(a)eircom.net> wrote: > On Sun, 7 Mar 2010 09:54:04 -0800 (PST) > > > > Quadibloc <jsav...(a)ecn.ab.ca> wrote: > > On Mar 7, 7:39 am, Ahem A Rivet's Shot <ste...(a)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. To avoid confusion, it is probably better if multiplying two two- dimensional arrays produces element-by-element multiplication - and, to get matrix multiplication, you need to declare variables having a MATRIX type, analogous to the COMPLEX type. John Savard |