using an FPGA to emulate a vintage computer
in [FPGA]
|
From: Ahem A Rivet's Shot on 7 Mar 2010 03:29 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. > If C doesn't have "real" arrays, it at least makes a rather good Arrays are not a real type in C if they were they would be passed by value in function calls instead of being passed by reference and it would be necessary to use a construct like &(a[0]) to pass the address of the first element of the array instead of just a. > attempt to simulate them. Unless one's standards are such that FORTRAN > doesn't quite have "real" arrays either, and you need to go to Pascal > for real arrays, there isn't that much to complain about in the case > of C. I am not saying that the C arrays are not useful as they are, just that they fall short of being a type in the sense that int, char, long, pointer and struct are. -- 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: Greg Menke on 7 Mar 2010 07:48 Ahem A Rivet's Shot <steveo(a)eircom.net> writes: > 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. 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. Gregm
From: Quadibloc on 7 Mar 2010 08:35 On Mar 7, 1:45 am, Ahem A Rivet's Shot <ste...(a)eircom.net> wrote: > On Sat, 6 Mar 2010 02:01:30 -0800 (PST) > > Quadibloc <jsav...(a)ecn.ab.ca> wrote: > > 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. > > Yes of course it does - why else would I have mentioned it in my > first post in this threadlet ? a is a pointer, 2 is in a integer and 2[a] > is the same as a[2] is the same as *(a+2) and the rules for adding pointers > and integers are well defined in C. This is the heart of my original point, > array notation in C is syntactic sugar for pointer arithmetic (and also > for allocation which I neglected to mention in my original post). If a[2] was the same as *(a+2), then, indeed, since addition is commutative, it would make sense that 2[a], being the same as *(2+a), would be the same. But a[2] is the same as *(&a+2) which is why I expected 2[a] to be the same as *(&2+a). Unless in *(a+2) "a" suddenly stops meaning what I would expect it to mean. In that case, C has considerably more profound problems than not having arrays. John Savard
From: Ahem A Rivet's Shot on 7 Mar 2010 09:39 On Sun, 7 Mar 2010 05:35:51 -0800 (PST) Quadibloc <jsavard(a)ecn.ab.ca> wrote: > On Mar 7, 1:45 am, Ahem A Rivet's Shot <ste...(a)eircom.net> wrote: > > On Sat, 6 Mar 2010 02:01:30 -0800 (PST) > > > > Quadibloc <jsav...(a)ecn.ab.ca> wrote: > > > 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. > > > > Yes of course it does - why else would I have mentioned it in my > > first post in this threadlet ? a is a pointer, 2 is in a integer and 2 > > [a] is the same as a[2] is the same as *(a+2) and the rules for adding > > pointers and integers are well defined in C. This is the heart of my > > original point, array notation in C is syntactic sugar for pointer > > arithmetic (and also for allocation which I neglected to mention in my > > original post). > > If a[2] was the same as *(a+2), then, indeed, since addition is Which it is by definition. > commutative, it would make sense that 2[a], being the same as *(2+a), > would be the same. > > But a[2] is the same as *(&a+2) which is why I expected 2[a] to be the > same as *(&2+a). No it's not - a in this context is treated as a pointer. > Unless in *(a+2) "a" suddenly stops meaning what I would expect it to > mean. 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. > In that case, C has considerably more profound problems than not > having arrays. C is consistent it's just that the array syntax really is a thin mask for pointer arithmetic - even the multidimensional array syntax but that's more fiddly. -- 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 7 Mar 2010 09:30
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: > > > 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. > > 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. -- 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/ |