using an FPGA to emulate a vintage computer
in [FPGA]
|
From: Joe Pfeiffer on 1 Mar 2010 14:19 Charles Richmond <frizzle(a)tx.rr.com> writes: > Joe Pfeiffer wrote: >> >> Since C99, you can allocate an array with a variable number of elements >> like this: >> >> printf(" array size >> "); >> scanf("%d", &size); >> >> int awry[size]; > > But how about the second dimension, Joe??? Can you allocate: > > int awry2[size][size]; Yes (just tried 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: Scott Lurndal on 1 Mar 2010 13:48 Michael Wojcik <mwojcik(a)newsguy.com> writes: >Scott Lurndal wrote: >> >> I've never promoted or suggested that one put an array in a struct >> and pass it by value, I frankly think it would be a stupid thing to >> do in a C program. > >Is it a stupid idea, or a good one, in all the languages that support >it? Is this just a special attribute of C? Perhaps stupid was a bit strong. As an OS designer/implementer, I find the copy to be a problem; perhaps for other applications, it would make some sense (although most the apps I can think of that process arrays are probably better off in FORTRAN or R or Mathematica. > >> I was curious if anyone thought passing an array by value was a >> _good_ idea. > >It might be if you want the callee to be able to modify its copy of >the array without affecting the caller's. Just like any other >pass-by-value object. > >If the callee would have had to make a copy of the array anyway, why >not let the compiler do the work? Yes, a point. However, I'd be concerned about the adverse affect on performance if used for subtantially large arrays. scott
From: Peter Flass on 1 Mar 2010 18:25 Joe Pfeiffer wrote: > Charles Richmond <frizzle(a)tx.rr.com> writes: >> Joe Pfeiffer wrote: >>> Since C99, you can allocate an array with a variable number of elements >>> like this: >>> >>> printf(" array size >> "); >>> scanf("%d", &size); >>> >>> int awry[size]; >> But how about the second dimension, Joe??? Can you allocate: >> >> int awry2[size][size]; > > Yes (just tried it) Hey! C's finally caught up to PL/I. Only took them 50 years, and then of course all the features are just tacked-on in true C fashion, instead of thought-through.
From: Joe Pfeiffer on 2 Mar 2010 11:15 "(see below)" <yaldnif.w(a)blueyonder.co.uk> writes: > On 24/02/2010 23:55, in article > 1bmxyy42ag.fsf(a)snowball.wb.pfeifferfamily.net, "Joe Pfeiffer" > <pfeiffer(a)cs.nmsu.edu> wrote: > >> When I was an undergrad I spent some time programming FORTRAN on a >> Harris /6 (I think it was a /6 -- there's something nagging at the back >> of my mind that says it may have been a /7). Anyway, reading the manual >> I discovered that return addresses were stacked, and immediately jumped to >> the conclusion that it could do recursion. It turned out that local >> variables were static... which meant I spent a *long* time figuring out >> why my program was producing completely nonsensical results. >> >> As Al Stewart once sang, "I was jumping to conclusions, and one of them >> jumped back." > > People who assumed that FORTRAN local variables *must* be static got jumped > on from the opposite direction when they used FORTRAN compilers that > actually did put them on the stack, as the ANS FORTRAN standard was > carefully worded to permit. All these decades I thought that was the case.... of course, I only programmed FORTRAN for a couple of years around 1980. -- 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: Michael Wojcik on 2 Mar 2010 13:21
glen herrmannsfeldt wrote: > In comp.arch.fpga Michael Wojcik <mwojcik(a)newsguy.com> wrote: > (snip on C, arrays, and such) > >> Array types aren't first-class because when used as formal parameters >> they're converted to pointer types, and when used as actual parameters >> they decay to a pointer to their first element. This is similar to C's >> other second-class type, the function type, which decays to a function >> pointer in every context except declaration and definition. > > How do you classify Fortran arrays. (Specifically "assumed size" > arrays in newer Fortran versions, the only ones they had in older > versions.) It's been too long since I used Fortran (or FORTRAN, of whatever vintage) in anger to speculate on the subject. The main thing I remember about Fortran arrays is that they're in column-major order, so when I worked on Fortran bindings for graphics libraries written in C, I had to transpose the arrays. (This was when I worked on the X11 implementations of GKS and PEX at IBM.) -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University |