using an FPGA to emulate a vintage computer
in [FPGA]
|
From: Peter Flass on 7 Mar 2010 17:30 Ahem A Rivet's Shot wrote: > 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. > Sure, just use PL/I ;-)
From: Joe Pfeiffer on 7 Mar 2010 21:07 johnf(a)panix.com (John Francis) writes: > 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. "Regard" is a key word there -- the syntax shown ought to work whether it's actually a dope vector (I assume you mean the same thing I learned about under the name "Iliffe vectors") or not. Haven't had a chance to try it.... -- As we enjoy great advantages from the inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. (Benjamin Franklin)
From: Charles Richmond on 7 Mar 2010 21:08 Uwe Klo� wrote: > Quadibloc schrieb: >> On Mar 5, 12:44 pm, Joe Pfeiffer <pfeif...(a)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(a)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. > Yes, you *can* use "a[1]" or "*(a+1)" for access. And you can think of "a" as a "named numerical (integer) constant", except that array "a" also has an implied length that is used to scale whatever integer is added to the address in "a". -- +----------------------------------------+ | Charles and Francis Richmond | | | | plano dot net at aquaporin4 dot com | +----------------------------------------+
From: Charles Richmond on 7 Mar 2010 21:11 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. 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". -- +----------------------------------------+ | Charles and Francis Richmond | | | | plano dot net at aquaporin4 dot com | +----------------------------------------+
From: Joe Pfeiffer on 7 Mar 2010 22:17
Charles Richmond <frizzle(a)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. -- As we enjoy great advantages from the inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. (Benjamin Franklin) |