using an FPGA to emulate a vintage computer
in [FPGA]
|
From: Joe Pfeiffer on 26 Feb 2010 14:38 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? > >> 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. I think the point is that this is unlikely to be a good thing to do to an array. I'm not terribly sure it's often a good idea for anything else, either! > If the callee would have had to make a copy of the array anyway, why > not let the compiler do the work? -- 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: glen herrmannsfeldt on 26 Feb 2010 15:53 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.) Since Fortran doesn't use call by value, but allows either call by reference or call by value result, there is no need for the "decay to pointer to the first element." The Fortran standard, since the first standard in 1966, and still in Fortran 2008, allows one to do things like: dimension x(100) call y(x(23)) and in the called routine subroutine y(z) dimension z(78) where subroutine y gets the last 78 elements of array x. The effect is exactly the same as a C program passing x+22 as a pointer. It is also legal to pass an array element of a multidimensional array to a called routine with a dummy array with a different number of dimensions (rank on Fortran terms). It was very common for library routines to dimension the dummy array (1) in the Fortran 66 days, or (*) in later versions, and compute the appropriate offset in a two (or more) dimensional actual argument (array in the calling routine). Pointers were added to Fortran in Fortran 90, but don't have any of these properties. You can't do all the pointer addition tricks that you can do in C with them. > [1] Probably the best treatment of this question is in PvdL's _Expert > C Programming_, chapter 4, "The Shocking Truth: C Arrays and Pointers > Are NOT the Same!", and chapter 9, "More About Arrays". -- glen
From: (see below) on 26 Feb 2010 16:02 On 26/02/2010 18:51, in article hm95vg73v1(a)news5.newsguy.com, "Michael Wojcik" <mwojcik(a)newsguy.com> wrote: > (see below) wrote: >> On 24/02/2010 20:37, in article hm6fbd68gp(a)news6.newsguy.com, "Michael >> Wojcik" <mwojcik(a)newsguy.com> wrote: >> >>> (see below) wrote: >>>> But bear in mind that in decent languages arrays are >>>> storable values, so a value array parameter gets copied in toto, unlike C. >>> It will be in C if the array is wrapped in a struct. Letting array >> >> That is passing a struct, not an array. > > Yes, that's what I said. Of course, if the array is the only thing in > the struct, then the distinction is purely syntactic. > >>> struct (and not the misnamed "typedef") is C's mechanism for creating >>> new types and ADTs, so if you want a pass-by-value array in C, the >>> correct thing to do is to put it in a struct. >> >> Yes. Preposterous, isn't it? > > Other than the name of the keyword struct, no, it seems pretty > reasonable to me. Parameters should be primitives or ADTs. Ah. You are a fundamentalist. -- Bill Findlay <surname><forename> chez blueyonder.co.uk
From: Peter Flass on 26 Feb 2010 17:54 Scott Lurndal wrote: > "(see below)" <yaldnif.w(a)blueyonder.co.uk> writes: >> On 24/02/2010 20:37, in article hm6fbd68gp(a)news6.newsguy.com, "Michael >> Wojcik" <mwojcik(a)newsguy.com> wrote: >> >>> (see below) wrote: >>>> Just the usual red tape: return address, frame pointer of caller; and either >>>> a static pointer or some housekeeping for 'display' registers (if used) to >>>> access non-locals. But bear in mind that in decent languages arrays are >>>> storable values, so a value array parameter gets copied in toto, unlike C. >>> It will be in C if the array is wrapped in a struct. Letting array >> That is passing a struct, not an array. >> >>> parameters decay to pointers was a feature of early C that couldn't be >>> changed for historical reasons, but when the standardization committee >>> added support for struct parameters, they made them first-class. >>> struct (and not the misnamed "typedef") is C's mechanism for creating >>> new types and ADTs, so if you want a pass-by-value array in C, the >>> correct thing to do is to put it in a struct. >> Yes. Preposterous, isn't it? > > Q? Why would anyone want to pass an array by value? > Because you can?
From: Charles Richmond on 27 Feb 2010 02:03
Michael Wojcik wrote: > glen herrmannsfeldt wrote: >> In comp.arch.fpga Charles Richmond <frizzle(a)tx.rr.com> wrote: >> (snip) >> >>> The dimensions of arrays *used* to have to be compile time >>> constants. Now they have a type of array declared in a function >>> that can have its size depend on an integer passed into the >>> function. (I forget what they call it... maybe a "dynamic array" >>> or something.) >> Yes, but can you do that for an array in a struct. > > No. The size of a struct type must be known at compile time, even in C99. > >> If you >> pass it in a function call, and it isn't the last argument, how >> will the called routine know where the other arguments are? > > If you *could* do this, that'd be an implementation issue, and outside > the scope of the C language. :-) > > (Technically, C says nothing about a stack. A conforming C > implementation could use activation frames that contain XML documents > describing each parameter in detail. It could use an indexed file to > implement the call stack. It could implement calls by generating > subprograms on the fly that get their parameters via pipes. If they > get there on the backs of unicorns ridden by nasal demons, that's OK > with the standard too.) > Sure the implementation is left up to the compiler writer. But however the arguments are passed and the functions called, the implementation is *equivalent* to using a stack... because it accomplishes the same thing. -- +----------------------------------------+ | Charles and Francis Richmond | | | | plano dot net at aquaporin4 dot com | +----------------------------------------+ |