using an FPGA to emulate a vintage computer
in [FPGA]
|
From: Michael Wojcik on 2 Mar 2010 13:32 Charles Richmond wrote: > Michael Wojcik wrote: >> >> (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. Yes, yes, obviously. I must remember henceforth to add a standard disclaimer to any similar posts. The point still stands: C says nothing about a stack, and that includes nothing about a contiguous stack with no metadata. An implementation is free to provide a stack-equivalent that describes the activation in glorious detail, and so accommodates all sorts of things that are difficult to implement with a dumb stack. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
From: Michael Wojcik on 2 Mar 2010 13:34 Joe Pfeiffer wrote: > 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! It's the moral equivalent of the OO idiom where a temporary object is created from a parameter via copy constructor, then discarded and eventually reclaimed by garbage collection. IME, that's quite common in a lot of OO applications (in OO languages with garbage collection, of course). Whether it's a Good Thing is highly contextual and largely subjective, of course. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
From: Michael Wojcik on 2 Mar 2010 13:41 Peter Flass wrote: > > 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. Well, that's rather insulting to the members of WG14, who spent a decade designing those features. Fortunately, they published the Rationale showing that, in fact, they were thought through.[1] And a great deal of documentation describing the process is available in the archives.[2] If you'd care to show why you think otherwise, perhaps there would be some grounds for debate. [1] http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf [2] http://www.open-std.org/JTC1/SC22/WG14/www/documents.html -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
From: Michael Wojcik on 2 Mar 2010 13:40 Scott Lurndal wrote: > 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'll agree that when I write C code (which until recently was most of the time; these days I happen to be writing mostly OO COBOL, ECMAScript, and occasionally PHP and Ruby), I like to keep a close watch on memory consumption - partly because I'm likely writing system code that needs to be conservative, and partly because C encourages that mindset. This is particularly true with automatic allocation and multithreaded programs. I've had to correct far too many thread-stack-overflow bugs (pretty much always in someone else's code) because of auto-class variable abuse. >>> 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. Yes. You'd want to restrict this to quite small objects, I think. In general, explicit allocation of copies from the heap is the better idea in C programs, because it gives you much better error handling. There's no standard mechanism for dealing with hitting the stack limit, and even the extensions offered by various implementations don't help much. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
From: Michael Wojcik on 2 Mar 2010 13:24
Ahem A Rivet's Shot wrote: > On Fri, 26 Feb 2010 13:48:48 -0500 > Michael Wojcik <mwojcik(a)newsguy.com> wrote: > >> Ahem A Rivet's Shot 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. >> That's not quite correct. C does implement an array type (or, rather, >> an array type qualifier which can be used to implement arrays of any >> object type); it's just not first-class. > > This is saying the same thing as I did in different terms and with > greater detail. I supposed, if you want to gloss "doesn't really implement an array type" as "does implement an array type". That seems rather a stretch to me. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University |