using an FPGA to emulate a vintage computer
in [FPGA]
|
From: glen herrmannsfeldt on 6 Mar 2010 05:25 In comp.arch.fpga Quadibloc <jsavard(a)ecn.ab.ca> wrote: (snip) >> [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. I believe the standard requires it. The subscript operator, [], is defined such that a[b] is equivalent to *(a+b). a[b] is *(a+b) is *(b+a) is b[a] It gets even more interesting with more subscripts, but still works. -- glen
From: Peter Flass on 6 Mar 2010 07:39 Quadibloc wrote: > On Mar 5, 3:54 pm, Peter Flass <Peter_Fl...(a)Yahoo.com> wrote: >> Quadibloc wrote: >>> On Feb 22, 3:53 pm, Peter Flass <Peter_Fl...(a)Yahoo.com> wrote: >>>> PL/I can be, but doesn't have to be. If the arguments of a procedure >>>> match the parameters, only the argument address (and possibly a >>>> descriptor address for strings structures, and arrays) is passed. >>> Doesn't PL/I (or, rather, normal implementations thereof) support >>> separate compilation of subroutines, just like FORTRAN and COBOL? >> Yes, but the calling sequence among PL/I programs passes information on >> string lengths, array bounds, > > which is why the "bloat" is unavoidable in PL/I, not unnecessary, you > had previously claimed and as I was trying to contradict. Yes, I'm > well aware PL/I does not use the standard S-type calling sequence. > Yes, but is it bloat? When I've converted C functions that work with arrays, most of them need to be passed the [address of the] array and the upper bound. The first thing I do is get rid of the latter, since it's handled automatically, but it's necessary one way or the other, so why not have the language do it?
From: Peter Flass on 6 Mar 2010 08:22 Peter Flass wrote: > Quadibloc wrote: >> On Mar 5, 3:54 pm, Peter Flass <Peter_Fl...(a)Yahoo.com> wrote: >>> Quadibloc wrote: >>>> On Feb 22, 3:53 pm, Peter Flass <Peter_Fl...(a)Yahoo.com> wrote: >>>>> PL/I can be, but doesn't have to be. If the arguments of a procedure >>>>> match the parameters, only the argument address (and possibly a >>>>> descriptor address for strings structures, and arrays) is passed. >>>> Doesn't PL/I (or, rather, normal implementations thereof) support >>>> separate compilation of subroutines, just like FORTRAN and COBOL? >>> Yes, but the calling sequence among PL/I programs passes information on >>> string lengths, array bounds, >> >> which is why the "bloat" is unavoidable in PL/I, not unnecessary, you >> had previously claimed and as I was trying to contradict. Yes, I'm >> well aware PL/I does not use the standard S-type calling sequence. >> > > > Yes, but is it bloat? When I've converted C functions that work with > arrays, most of them need to be passed the [address of the] array and > the upper bound. The first thing I do is get rid of the latter, since > it's handled automatically, but it's necessary one way or the other, so > why not have the language do it? Sorry to reply to my own post, but I just thought of something I should have said. If you want to eliminate all the "bloat" and emulate C directly in PL/I, it's possible. DECLARE my_array (0:some_upper_bound-1) ...attributes... ; /* By default, PL/I arrays start with subscript one, * to exactly duplicate C change the lower bound to zero. * Also, C arrays are declared with [number_of_elements] rather * than highest subscript. Since the lower bound is zero * the number of elements is always one greater than the highest * subscript, which is always a source of confusion * for new C programmers. */ DECLARE my_C_func ENTRY(POINTER, FIXED BINARY) OPTIONS(..options...); /* The "OPTIONS" keyword would indicate that this function is * a C or C-like function. For IBM this is "BYVALUE LINKAGE(SYSTEM)". */ CALL my_C_func( addr(my_array), some_upper_bound ); /* This calls the function exactly as in C, passing the address * of the array and the upper bound by value */ Now try to replicate PL/I calls in C.
From: Walter Bushell on 6 Mar 2010 15:03 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. -- A computer without Microsoft is like a chocolate cake without mustard.
From: John Francis on 6 Mar 2010 16:09
In article <proto-18F31F.15035106032010(a)news.panix.com>, Walter Bushell <proto(a)panix.com> 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. No it isn't. '=' is assignment; '==' is comparison. |