using an FPGA to emulate a vintage computer
in [FPGA]
|
From: Charles Richmond on 6 Mar 2010 19:51 Quadibloc wrote: > On Mar 5, 12:44 pm, Joe Pfeiffer <pfeif...(a)cs.nmsu.edu> wrote: >> Quadibloc <jsav...(a)ecn.ab.ca> writes: >>> On Feb 26, 4:56 am, Ahem A Rivet's Shot <ste...(a)eircom.net> wrote: >>>> No, he's saying that C doesn't really implement an array type, the >>>> var[offset] syntax is just syntactic sugar for *(var + offset) which is why >>>> things like 3[x] work the same as x[3] in C. >>> Um, no. >>> x = y + 3 ; >>> in a C program will _not_ store in x the value of y plus the contents >>> of memory location 3. >>> On a big-endian machine, >>> long int x[5] ; >>> x[0] = 3 ; >>> x[1] = 12 ; >>> y = x[0] ; >>> or, on a little-endian machine, >>> long int x[5] ; >>> x[1] = 3 ; >>> x[0] = 12 ; >>> y = x[1] ; >>> will not result in zero being stored in y, since a long int variable >>> occupies more than one byte in storage, and hence the two assignments >>> are being made to overlapping variables. >>> Yes, C doesn't do _bounds checking_, but that is a far cry from >>> "syntactic sugar for variable plus address offset". >> I'm not quite sure what the point of your example is, somebody who is >> better at programming languages than me would have to evaluate the claim >> that C arrays aren't arrays. But: >> >> #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. > > Evidently there is some discrepancy between C and FORTRAN. > > John Savard 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 and Francis Richmond | | | | plano dot net at aquaporin4 dot com | +----------------------------------------+
From: Charles Richmond on 6 Mar 2010 19:54 Walter Bushell wrote: > In article <20100305171635.e538ef18.steveo(a)eircom.net>, > Ahem A Rivet's Shot <steveo(a)eircom.net> wrote: > >> On Fri, 5 Mar 2010 09:07:31 -0800 (PST) >> Quadibloc <jsavard(a)ecn.ab.ca> wrote: >> >>> On Feb 26, 4:56� am, Ahem A Rivet's Shot <ste...(a)eircom.net> wrote: >>> >>>> � � � � No, he's saying that C doesn't really implement an array type, >>>> the var[offset] syntax is just syntactic sugar for *(var + offset) >>>> which is why things like 3[x] work the same as x[3] in C. >>> Um, no. >>> >>> x = y + 3 ; >>> >>> in a C program will _not_ store in x the value of y plus the contents >>> of memory location 3. >> 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. > > No, that will compare x and the right val. > > = is a comparasion operator in c. > "==" is a comparison operator in c. -- +----------------------------------------+ | Charles and Francis Richmond | | | | plano dot net at aquaporin4 dot com | +----------------------------------------+
From: Charles Richmond on 6 Mar 2010 19:55 Peter Flass wrote: > Walter Bushell wrote: >> In article <20100305171635.e538ef18.steveo(a)eircom.net>, >> Ahem A Rivet's Shot <steveo(a)eircom.net> wrote: >> >>> On Fri, 5 Mar 2010 09:07:31 -0800 (PST) >>> Quadibloc <jsavard(a)ecn.ab.ca> wrote: >>> >>>> On Feb 26, 4:56� am, Ahem A Rivet's Shot <ste...(a)eircom.net> wrote: >>>> >>>>> � � � � No, he's saying that C doesn't really implement an >>>>> array type, >>>>> the var[offset] syntax is just syntactic sugar for *(var + offset) >>>>> which is why things like 3[x] work the same as x[3] in C. >>>> Um, no. >>>> >>>> x = y + 3 ; >>>> >>>> in a C program will _not_ store in x the value of y plus the contents >>>> of memory location 3. >>> 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. >> >> No, that will compare x and the right val. >> >> = is a comparasion operator in c. >> > > '=' is assignment, '==' is comparison. I think there is *not* a single C programmer who has *not* had his hand slapped by making the mistake of using "=" when he meant "==". Thus the avalanche of replies... :-) -- +----------------------------------------+ | Charles and Francis Richmond | | | | plano dot net at aquaporin4 dot com | +----------------------------------------+
From: glen herrmannsfeldt on 6 Mar 2010 21:13 In comp.arch.fpga Rick <richardcortese(a)gmail.com> wrote: (snip) > One of the other old processors from my stone knives and bear skin > days was the RCA1802. It had IMHO a great feature for the calling > subroutines. Anyone of the 16 general purpose registers could be made > the program counter with a single instruction. The OS/360 (and successor) calling mechanism isn't so different. The BALR instruction branches to the address in a specified register, while storing the address of the next instruction in a register. It is even allowed for both registers to be the same! I have seen that used for coroutines, where an appropriate BALR switches between routines using only one register to store the address in the other routine. --glen
From: Joe Pfeiffer on 6 Mar 2010 21:57
Quadibloc <jsavard(a)ecn.ab.ca> writes: > > 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. I don't have my copy handy, but I think it was documented that way back in the original C language Bell Labs tech report. -- 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) |